Using cSHAKE in ORCHIDsHTT ConsultingOak ParkMI48237USArgm@labs.htt-consult.comAX Enterprize4947 Commercial DriveYorkvilleNY13495USAstu.card@axenterprize.comAX Enterprize4947 Commercial DriveYorkvilleNY13495USAadam.wiethuechter@axenterprize.com
Internet
HIPRFCRequest for CommentsI-DInternet-DraftHIP
This document specifies how to use the cSHAKE hash for ORCHID
generation and allows for varying sized hashes in the ORCHID along
with additional information within the ORCHID. It is an addendum to
ORCHIDv2.
This document adds the Keccak based
cSHAKE XOF hash function from NIST
SP 800-185 to ORCHIDv2.
cSHAKE is a variable output length hash function. As such it does
not need the truncation operation that other hashes need. The
invocation of cSHAKE specifies the desired number of bits in the
hash output.
cSHAKE is used, rather than SHAKE from NIST FIPS 202, as cSHAKE has a
parameter 'S' as a customization bit string. This parameter will be
used for including the ORCHID Context Identifier in a standard
fashion.
An additional change to ORCHID construction will allow for shorter
hash output lengths to permit inclusion of additional information
like Hierarchical
HITs into the ORCHID.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 when, and only when, they appear in all
capitals, as shown here.
`
Signifies concatenation of information - e.g., X | Y is the
concatenation of X and Y.
The family of all sponge functions with a KECCAK-f
permutation as the underlying function and multi-rate
padding as the padding rule.
Extends the SHAKE scheme to allow users to customize their
use of the function.
A secure hash that allows for an arbitrary output length.
A function on bit strings (also called messages) in which
the output can be extended to any desired length.
ORCHIDv2 is currently defined as
consisting of three components:
This addendum will be constructed as follows:
The 96 bits currently allocated to the Encode_96 function can be
divided in any manner between the additional information and the
hash output. Care must be taken in determining the size of the
hash portion, taking into account risks like pre-image attacks.
Thus 64 bits as used in Hierarchical HITs may be as small as is
acceptable.
With this addendum, the decoding of an ORCHID is determined by
the Prefix and OGA ID. ORCHIDv2
decoding is selected when the Prefix is: 2001:20::/28.
For Heirarchical HITs, the decoding is determined by the presence
of the HHIT Prefix as specified in the HHIT document.
ORCHIDv2 has a number of inputs including a Context ID, some header
bits, the hash algorithm, and the input bitstream, normally just
the public key. The output is a 96 bit value.
This addendum adds a different encoding process to that currently
used. The input to the hash function explicitly includes all the
fixed header content plus the Context ID. The fixed header content
consists of the Prefix, OGA ID, and the Additional Information.
Secondly, the length of the resulting hash is set by the rules set
by the Prefix/OGA ID. In the case of Hierarchical HITs, this is 64
bits.
To achieve the variable length output in a consistent manner, the
cSHAKE hash is used. For this purpose, cSHAKE128 is appropriate.
The the cSHAKE function call for this addendum is:
Hierarchical HIT uses the same context as all other HIPv2 HIT
Suites as they are clearly separated by the distinct HIT Suite ID.
The EdDSA/cSHAKE based HITs in New Cryptographic Algorithms
for HIP is the first HIP Suite to use cSHAKE, thus using
this addendum.
Hierarchical
HITs (HHITs) is the first HIT construct that specifies the need of
dividing the 96 bits available to ORCHID into its Hierarchy ID
(HID) and HI Hash, thus using this addendum.
HHITs use a unique Context ID as well as a Prefix different from
HIPv2. The different Prefix enables
receivers to properly decode the HID out of the HIT and validate
the HIT, given the HI.
The 64 bit hash size does have an increased risk of collisions over
the 96 bit hash size used for the other HIT Suites. There is a
0.01% probability of a collision in a population of 66 million.
The probability goes up to 1% for a population of 663 million. See
for the collision probability formula.
However, this risk of collision is within a single "Additional
Information" value. Some registration process should be used to
reject a collision, forcing the client to generate a new HI and
thus HIT and reapplying to the registration process.
TBD.
A 64 bit hash space presents a real risk of second pre-image
attacks. A Registry service effectively block attempts to "take
over" such a HIT. It does not stop a rogue attempting to
impersonate a known HIT. This attack can be mitigated by the
Responder using DNS to find the HI for the HIT or the RVS for the
HIT that then provides the registered HI.
Quynh Dang of NIST gave considerable guidance on using Keccak and
the NIST supporting documents. Joan Deamen of the Keccak team was
especially helpful in many aspects of using Keccak.
The Keccak FunctionRadboud UniversitySTMicroelectronicsSTMicroelectronicsSTMicroelectronics
The accepted formula for calculating the probability of a collision
is: