New Cryptographic Algorithms for HIPHTT 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 provides new cryptographic algorithms to be used with
HIP. The Edwards Elliptic Curve and the Keccak sponge functions
are the main focus. The HIP parameters and processing instructions
impacted by these algorithms are defined.
Introduction
This document adds new cryptographic algorithms for HIPv2 and . This includes:
New elliptic curves for ECDH.
The Edwards Elliptic Curve Digital Signature Algorithm (EdDSA)
used in Host Identities (HI) and for Base Exchange (BEX)
signatures.
Hashes used in Host Identity Tag (HIT) generation, and
wherever else hashes are needed.
Keyed hashes used for KEYMAT generation and packet MACing
operations.
AEAD and stream ciphers to use in HIP and HIP enabled secure
communication protocols.
The hashes and encryption are all built on the Keccak sponge function and
the Xoodyak
lightweight scheme.
These additions reflect selection of advances in the field of
cryptography that would best benefit HIP, particularly in
constrained devices and communications.
Ed Note: The Xoodyak function calls should be considered the 1st
best effort. There are a few areas open for discussion, like which
of the 3 choices for adding in the nonce to the AEAD mode and when
to use counter and Id. Also there may be copy errors from the
source specification, nicer function calls, better acronyms.
Terms and DefinitionsRequirements Terminology
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.
Definitions
cSHAKE (The customizable SHAKE function):
Extends the SHAKE scheme to allow users to customize their
use of the function.
DEC function (Doubly-Extendable Cryptographic function):
An extendable output function (XOF) that accepts sequences
of strings as input and that supports incremental queries
efficiently.
DECK function (Doubly-Extendable Cryptographic Keyed function):
A keyed function that takes a sequence of input strings and
returns a pseudorandom string of arbitrary length and that
can be computed incrementally.
Keccak:
The family of all sponge functions with a KECCAK-f
permutation as the underlying function and multi-rate
padding as the padding rule.
KMAC (KECCAK Message Authentication Code):
A pseduo random function (PRF) and keyed hash function
based on KECCAK.
SHAKE (Secure Hash Algorithm KECCAK):
A secure hash that allows for an arbitrary output length.
SHAKE128 and SHAKE256 are instances of XOFs. SHAKE is
shorthand for SHAKE128.
PRF (Pseudorandom Function):
A function that takes as input a key and that it is hard to
distinguish from a random oracle by an adversary that does
not know the key.
XHASH (Xoodyak Hash Algorithm):
A secure hash, based on Xoodyak, that allows for an
arbitrary output length. XHASH is an instance of XOF.
XMAC (Xoodyak Message Authentication Code):
A keyed hash function, based on Xoodyak, that allows for an
arbitrary output length.
XOF (eXtendable-Output Function):
A function on bit strings (also called messages) in which
the output can be extended to any desired length.
HIP Parameter values for new Cryptographic Functions
HIP parameters carry information that is necessary for establishing
and maintaining a HIP association. For example, the device's
public keys as well as the signaling for negotiating ciphers and
payload handling are encapsulated in HIP parameters. Additional
information, meaningful for end hosts or middleboxes, may also be
included in HIP parameters. The specification of the HIP
parameters and their mapping to HIP packets and packet types is
flexible to allow HIP extensions to define new parameters and new
protocol behavior.
Elliptic Curves for Diffie-Hellman
Elliptic curves Curve25519 and Curve448 are specified here for use in the
HIP Diffie-Hellman exchange.
Curve25519 and Curve448 are already defined in Section 5.2.1 of
, using
the HIP-DEX CKDF. Here they are defined for using the new KMAC
or XMAC
derived KDF in .
DIFFIE_HELLMAN
The DIFFIE_HELLMAN parameter may be included in selected HIP
packets based on the DH Group ID selected. The DIFFIE_HELLMAN
parameter is defined in Section 5.2.7 of .
The following Elliptic Curves are defined here:
A new KDF for KEYMAT, Section 6.5 of using Keccak or Xoodyak is defined in .
Edward Digital Signature Algorithm for HITs
This section is extracted from Appendix D of . It may later be
pulled and only maintained there.
Edwards-Curve Digital Signature Algorithm (EdDSA) are specified here for
use as Host Identities (HIs) per HIPv2. Further the HIT_SUITE_LIST is
specified as used in .
HOST_ID
The HOST_ID parameter specifies the public key algorithm, and for
elliptic curves, a name. The HOST_ID parameter is defined in
Section 5.2.19 of .
For hosts that implement EdDSA as the algorithm, the following ECC
curves are available:
HIT_SUITE_LIST
The HIT_SUITE_LIST parameter contains a list of the supported HIT
suite IDs of the Responder. Based on the HIT_SUITE_LIST, the
Initiator can determine which source HIT Suite IDs are supported by
the Responder. The HIT_SUITE_LIST parameter is defined in Section
5.2.10 of .
The following HIT Suite ID is defined, and the relationship between
the four-bit ID value used in the OGA ID field and the eight-bit
encoding within the HIT_SUITE_LIST ID field is clarified:
The following table provides more detail on the above HIT Suite
combinations. The input for each generation algorithm is the
encoding of the HI as defined herein.
The output of cSHAKE128 and XHASH are variable per the needs of a
specific ORCHID construction. It is at most 96 bits long and is
directly used in the ORCHID (without truncation).
HIT Suites
Index
Hash function
HMAC
Signature algorithm family
Description
5
cSHAKE128
KMAC128
EdDSA
EdDSA HI hashed with cSHAKE128, output is variable
6
XHASH
XMAC
EdDSA
EdDSA HI hashed with XMAC, output is variable
Hashing in HIP
Hashing is used in HIP for HIT generation and keyed hashes of HIP
payloads. The hash algorithm used is designated as part of the
HIT_SUITE_ID. The keyed hash function is the "common" such
function used in conjunction with the HIT hash.
Hashing with the Sponge Functions
The XOF function in SHA-3, Secure Hash Algorithm Keccak (SHAKE)
and the
more recent Xoodyak
algorithm are called sponge functions. Sponge functions have a
special feature in which an arbitrary number of output bits are
"squeezed" out of the hashing state. This is a significant use
change in that hash truncation or multiple "runs" for enough bits
are not used with sponge functions.
cSHAKE, the customizable SHAKE function
The customizable SHAKE function (cSHAKE) in will
be used as a HIP hash. As a Keccak XOF, it does not use the
truncation operation that other hashes need. The invocation of
cSHAKE specifies the desired number of bits in the hash output.
Further, cSHAKE has a parameter 'S' as a customization bit string.
This parameter will be used for including hash specific
customization like the ORCHID Context Identifier in a standard
fashion.
Hardware implementation of Keccak in VHDL is available from Keccak team website.
The Xoodyak Hash
The Xoodyak sponge
function is a candidate in the NIST Lightweight Cryptography (LWC)
Standardization process. Xoodyak has been selected here for use in
HIP from the LWC 2nd round candidates as it was developed by the
Keccak team, making it more directly in line with Keccak.
Xoodyak has a hash function mode. More specifically, this hash
mode is an extendable output function (XOF).
As the Xoodyak specification does not provide high-level function calls,
rather a set of primitives to use to construct the various modes,
the appropriate primitive calls will be detailed below. Xoodyak as
a hash will be called here "XHASH".
To get a n-byte digest of some input x: XHASH(n, x),
use the following set of Xoodyak primitives:
Xoodyak can also naturally implement a DEC function and process a
sequence of strings. Here the output depends on the sequence as
such and not just on the concatenation of the different strings. To
compute a n-byte digest, XHASH(n, {x1, x2, x3}) the Xoodyak
primitives are:
The equivalent of the parameter 'S' in cSHAKE above can be
implemented as the last Absorb primitive call in the DEC function.
That is: XHASH(L, {S, N, X}) is equivalent to cSHAKE(X, L, N, S).
RHASH
RHASH is the general term used throughout to refer to the hash used for a specific HIT
suite. For this addendum cSHAKE128 for Keccak or XHASH for Xoodyak
is used, even for HITs of EdDSA448.
Unless otherwise specified, L of cSHAKE128 or n of XHASH is 256,
resulting in a similar output to SHA256. Any truncation used for,
older, fixed output hashes is still used. This is to simplify code
integration. One exception to this is in .
HIP_MAC and HIP_MAC2
The HIP_MAC and HIP_MAC2 parameters in use HMAC . This performs two hashes on a string with a
key for a keyed hash the length of the underlying hash.
For both HIP_MAC and HIP_MAC2 use, the parameter S below is NULL.
It is included for complete function definition.
The Keccak Keyed MAC
Here, KMAC from NIST SP 800-185 is used. This is a single
pass using the underlying cSHAKE function. The function call is:
The Xoodyak Keyed MAC
Here, XMAC is defined as the keyed hash function based on Xoodyak.
It is built with primitives from as a DEC function.
To get a n-byte keyed MAC of some input x: XMAC(Key, n, {x, S}).
Where n=256, use the following set of Xoodyak primitives:
Id is "HIP_MAC" and "HIP_MAC2" respectively. Note since S is null
in this XMAC usage, the first Absorb call is not performed.
HIP Cipher
HIP encrypted parameters use the HIP_CIPHER, Section 5.2.8 of . The Xoodyak cipher, , is recommended. Here
Xoodyak is used in encrypt only mode.
HIP_CIPHER
The HIP_CIPHER parameter value for Xoodyak is:
The Xoodyak primitive calls for encrypt only are:
ESP Transform
The ESP_TRANSFORM parameter is used during ESP SA establishment,
Section 5.1.2 of . The
Xoodyak cipher, ,
is recommended. Here Xoodyak is used in AEAD mode.
Further, it is recommended to use Implicit IV ESP to match its lightweight
over-the-air format with the lightweight Xoodyak AEAD cipher.
ESP_TRANSFORM
The ESP_TRANSFORM Suite IDs for Xoodyak are:
The Implicit IV Suite ID is unique in that it is an AND condition
with ciphers that can use it. That is AES-GCM and Xoodyak can both
use 'regular' ESP or
.
The Xoodyak primitive calls for AEAD encrypt are:
Where Id is "ESP_TRANSFORM". The IV is either a 32 bit ESP IV per
or the ESP Seq Number
per. P is the plain-text
and A is the associated data. t is either 12 or 16. T is the ESP
ICV of length t.
Generating a HIT from an HI
The EdDSA/cSHAKE based HITs require a new ORCHID generation method
than that described in section 3.2 of . The XOF functionality of cSHAKE produces an
output of L bits. This replaces the Encode_96 function in the
ORCHID generation.
For identities that are EdDSA public keys, ORCHIDs will be
generated per the process defined in Appendix C.2.1 of .
HIP KEYMAT Generation
For either the Keccak or Xoodyak KEYMAT generation, the inputs are
consistent. The only practical difference is that cSHAKE allows for
128 or 256 bits of strength, whereas Xoodyak only provides 128
bits.
L is the derived key bit length. Since 4 HIP keys are "drawn" from
this output, the length is 4 * HIP_key_size. Per ASIACRYPT 2017, pp.
606-637 each of these derived keys will have the same
strength as the Diffie-Hellman shared secret.
S is the byte string 01001011 || 01000100 || 01000110, which
represents the sequence of characters "K", "D", and "F" in 8-bit
ASCII.
Salt and info are derived as defined in sec 6.5 of . There are
special security considerations for IKM per .
The Keccak KEYMAT
The KMAC function provides a new, more efficient, key derivation
function over HKDF . KMAC
as a KDF is defined below.
The two HIs MUST be used in constructing IKM as follows:
The two HIs are separately DER encoded per
The choice of KMAC128 or KMAC256 is based on the strength of the
output key material. For 256 bits of strength equivalent to
HMAC-SHA256, use KMAC256. Per ,
Section 4.1, Option 3:
The Xoodyak KEYMAT
Here, XMAC from is
used. The DEC function XMAC("", L, {DH, sort(HI-I, HI-R), info,
Salt, S}) primitives are:
Ed Note: Need to check that all above are well defined bytestrings
per 7401. I think they are.
Pseudorandom Function (PRF)
Appendix B of NIST
SP 800-185 defines how to use SHAKE, cSHAKE, or KMAC as a
PRF.
For Xoodyak, XMAC from
is used in the same manner as KMAC above.
IANA Considerations
IANA will need to make the following changes to the "Host
Identity Protocol (HIP) Parameters" registries:
Diffie Hellman:
This document defines the new Curve25519 and Curve448 for
the Diffie-Hellman exchange (see ).
Host ID:
This document defines the new EdDSA Host ID (see ).
HIT Suite ID:
This document defines the new HIT Suite of EdDSA/cSHAKE and
EdDSA/XHASH (see ).
HIP Cipher:
This document defines the new Xoodyak cipher for HIP
encrypted parameters (see ).
ESP Transform:
This document defines the new Xoodyak cipher and use of
for the ESP
Transform parameter (see ).
Security ConsiderationsKeymat vulnerabilities warns about using
Curve25519 and Curve448 in Diffie-Hellman for key derivation:
Designers using these curves should be aware that for each public
key, there are several publicly computable public keys that are
equivalent to it, i.e., they produce the same shared secrets. Thus
using a public key as an identifier and knowledge of a shared
secret as proof of ownership (without including the public keys in
the key derivation) might lead to subtle vulnerabilities.
Thus the two Host IDs are included with the Diffie-Hellman secret
in the KEYMAT generation.
KMAC Security as a KDF
Section 4.1 of NIST
SP 800-185 states:
"The KECCAK Message Authentication Code (KMAC) algorithm is a PRF
and keyed hash function based on KECCAK . It provides
variable-length output"
That is, the output of KMAC is indistinguishable from a random
string, regardless of the length of the output. As such, the
output of KMAC can be divided into multiple substrings, each with
the strength of the function (KMAC128 or KMAC256) and provided that
a long enough key is used, as discussed in Sec. 8.4.1 of SP 800-185.
For example KMAC128(K, X, 512, S), where K is at least 128 bits,
can produce 4 128 bit keys each with a strength of 128 bits. That
is a single sponge operation is replacing perhaps 5 HMAC-SHA256
operations (each 2 SHA256 operations) in HKDF.
Acknowledgments
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 and Xoodyak,
particularly with the KEYMAT section and the strength of the
derived keys.
NIST is entering round 3 (final) of its Lightweight Crypto
Competition with anticipated selection the end of 2021 or early in
2022. Events in this process will impact selections in this
document.
ReferencesNormative ReferencesThe Xoodyak Cipher and HashRadboud UniversitySTMicroelectronicsSTMicroelectronicsSTMicroelectronicsXoodoo cookbookRadboud UniversitySTMicroelectronicsSTMicroelectronicsSTMicroelectronicsInformative ReferencesFull-State Keyed Duplex with Built-In Multi-user SupportThe Keccak FunctionRadboud UniversitySTMicroelectronicsSTMicroelectronicsSTMicroelectronics