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. 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.
These additions reflect selection of advances in the field of
cryptography that would best benefit HIP, particularly in
constrained devices and communications.
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
Keccak (KECCAK Message Authentication Code):
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 PRF and keyed hash function based on KECCAK.
cSHAKE (The customizable SHAKE function):
Extends the SHAKE scheme to allow users to customize their
use of the function.
SHAKE (Secure Hash Algorithm KECCAK):
A secure hash that allows for an arbitrary output length.
PRF (Pseudorandom Function):
A function that can be used to generate output from a
random seed such that the output is computationally
indistinguishable from truly random output.
capacity:
In the sponge construction, the width of the underlying
function minus the rate.
rate:
In the sponge construction, the number of input bits
processed per invocation of the underlying function.
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 Crytpo
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
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 and Section 6.3 of using Keccak is
defined in .
Edward Digital Signature Algorithm
Edwards-Curve Digital Signature Algorithm (EdDSA) are specified here for
use as Host Identities (HIs).
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 in . The output is 96 bits long and is directly used
in the ORCHID.
HIT Suites
Index
Hash function
HMAC
Signature algorithm family
Description
5
cSHAKE128
KMAC128
EdDSA
EdDSA HI hashed with cSHAKE128, output is 96 bits
Hashing with the Keccak Function
The Keccak sponge
function is the basis for the new SHA-3, standard , and the
customized XOF functions in . These are used here as an alternative
to all the hashing functions in HIP.
Hardware implementation of Keccak in VHDL is available from Keccak.
The Keccak Permutation
Keccak is described as a sponge function. The analogy to a
sponge is that an arbitrary number of input bits are "absorbed"
into the state of the function, after which an arbitrary number of
output bits are "squeezed" out of its state.
The Keccak function is defined to have a width of b bits.
Where b is the capacity (c) + rate (r).
The rate is the number of bits "fed" into the sponge at a time.
The capacity is twice the desired hash "strength" and part of the
sponge width.
b is one of the set {25, 50, 100, 200, 400, 800, 1600}. In FIPS
202, b=1600. Thus a hash strength of 128 bits can be delivered
with c=256 and r=1344, or 168 byte segment input to the sponge.
Keccak can also provide a hash strength of 128 bit with b=800
(r=544 or 68 bytes) and b=400 (r=144 or 18 bytes). 256 bit
strength can only be provided with b=1600 or 800.
FIPS 202 does not specify use of these smaller values for b which
may be preferred in memory constrained devices, processing
relatively short input strings. Future work will determine if the
smaller values for b result in a significant performance/memory
improvement to warrant their use.
RHASH
The RHASH is the general term used throughout to refer to the hash used for a
specific HIT suite. For this addendum SHAKE128 is used, even for
HIs of EdDSA448.
Unless otherwise specified, L of SHAKE128 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.
Here, KMAC from NIST SP 800-185 is used. This is a single
pass using the underlying cSHAKE function. The function call is:
HIP Cipher
HIP encrypted parameters use the HIP_CIPHER, Section 5.2.8 of . The Keccak Keyak cipher,
, is
recommended. Keyak is a candidate in the NIST Lightweight
Cryptography competition and is consistent with the overall
approach in this addendum to use Keccak functions for simplicity in
design and implementation.
HIP_CIPHER
The HIP_CIPHER parameter values for Keyak are:
For use as the HIP Cipher, the TAG generated in Keyak is length 0.
The Keyak SUV is the key plus IV specified for the encrypted
parameter. River Keyak MAY be used for , in place of AES-CTR.
Lake Keyak can provide 256 bits of security by following the
recommendations for the Keyak cipher.
Generating a HIT from an HI
The EdDSA/cSHAKE based HITs vary slightly the ORCHID generation
method 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 Using cSHAKE
in ORCHIDsHIP KEYMAT Generation
The KMAC function provides a new, more efficient, key derivation
function over HKDF . This
will be referred to as KKDF.
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:
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 or . There are special security
considerations for IKM per . The two HIs MUST be used in constructing IKM
as follows:
These are separately DER encoded.
Using Keccak for a Pseudorandom Function
Appendix B of NIST
SP 800-185 defines how to use SHAKE, cSHAKE, or KMAC as a
PRF.
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
(see ).
HIP Cipher:
This document defines the new Keyak ciphers for HIP
encrypted parameters (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.
This applies to , but may have broader consequences. Thus the two Host IDs
are included with the Diffie-Hellman secret.
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, particularly
with the KEYMAT section and the strength of the derived keys.
ReferencesNormative ReferencesInformative ReferencesFull-State Keyed Duplex with Built-In Multi-user SupportThe Keccak FunctionRadboud UniversitySTMicroelectronicsSTMicroelectronicsSTMicroelectronicsThe Keyak CipherRadboud UniversitySTMicroelectronicsSTMicroelectronicsSTMicroelectronics