Deterministic Nonce-less Hybrid Public Key Encryption

Introduction , hereinafter simply HPKE, is a robust, provably-secure construct. It defines APIs to ensure proper use to retain its security guarantees. These APIs are therefore rigid and purposeful. Unfortunately, there are applications for which this rigidity is an impediment to use: networks with bandwidth constrained mediums, networks which cannot guarantee in-order delivery of every packet sent, and for key-wrapping applications. This memo proposes three modifications to HPKE to make it more suitable for different use cases.

Compact Representation HPKE generates an ephemeral keypair and uses it to perform a Diffie-Hellman with the static keypair of the proposed recipient of a secure message. The ephemeral public key is required to accompany the message, or at least the first of a stateful sequence of messages. HPKE therefore defines a serialization and deserialization for public keys used with defined KEMs. HPKE defines KEMs that use three Weierstrass curves defined in . The serialization and deserialization for public keys in these KEMs use the uncompressed form of an elliptic curve from . Unfortunately, this results in the string that accompanies the message to be over twice as long as it needs to be. This can be an issue for applications that have constrained bandwidth or that use the HPKE APIs in a stateless, "single shot" mode where the message being sent is dwarfed by the size of the serialized public key. defines a notion of "compact output" and "compact representation" for elliptic curves. Compact output means that the output of the ECDH operation is the x-coordinate of the resulting point, the y-coordinate is discarded. Compact representation is a way of communicating an elliptic curve Diffie-Hellman public key using the x-coordinate only. Compact representation will work if compact output is employed-- the sign of the ECDH secret is irrelevant so it doesn't matter what the sign of the peer's public key is. HPKE uses compact output, it passes the x-coordinate of the ECDH secret key to HKDF to derive a key to pass to the AEAD cipher. Since HPKE uses compact output, it can define serialization and deserialization that uses compact representation and thereby address use cases in which message size is important. Redefining the serialization and deserialization, though, requires definition of new KEMs that will use the new technique.

Addressing Lossy Networks To prevent the possibility of misuse, management of AEAD counters are entirely constrained to the HPKE context. The sender and receiver have no ability to know what particular counter was used with a particular invocation or to manage how counters are used. This restriction is not an issue for an applications that use HPKE which have a guarantee of in-order packet delivery, where sender and receiver HPKE contexts are kept in sync. But not everyone has a guarantee of in-order delivery of packets and this restriction makes use of HPKE impracticle by a great many use cases. Any undetected packet loss or reordering would result in the sender and receiver HPKE contexts getting out of sync. Since HPKE provides no way to resynchronize such a situation, the result would be tragic. Therefore, two techiques are added to allow HPKE to be used in lossy networks or networks that reorder packets: a rolling window of received sequence numbers, and a determinstic mode of AEAD.

Rolling Sequence Window The technique from can be adopted which implements a rolling window that represents received messages (inside the window). As the sequence number advances, and a message is successfully opened thus validating the sequence number, the window advances to include it. The result is that reorder and loss is acceptable for a number of messages defined by the size of the window and messages deemed "too old" are dropped. Messages replayed with a used sequence number are also dropped. To implement such a scheme, the receiver needs to know the counter used with the AEAD algorithm. Therefore, the sequence number used to construct the counter in HPKE (it is XOR'd with a secret base nonce) is pre-peneded to the ciphertext.

Deterministic Authenticated Encryption defines a provably secure mode of deterministic authenticated encryption (DAE). In this mode, a counter is optional. If one is used and it is guaranteed to be unique, SIV achieves the same level of IND-CCA2 security offered by other HPKE ciphers. But if the nonce is reused or, in the case proposed here, the nonce is not used, SIV will provide a different security guarantee, that of deterministic security. Determinsitic authenticity in a DAE scheme provides the traditional inability of an adversary to come up with a non-trivial query that will return a non-FAIL response-- i.e. a valid forgery-- with non-negligible probability. Deterministic privacy in a DAE scheme provides for the typical indistinguishability from random guarantee of a traditional AEAD scheme, with a caveat: it cannot achieve the indistinguishability goal that requires concealment of whether or not a given plaintext was encrypted twice in a sequence of ciphertexts. What this means is that the security of a DAE scheme is the same as a traditional AE scheme with the exception that encrypting the same AAD and the same plaintext twice will result in the same ciphertext, an outcome an adversary would notice. Unlike other AEAD schemes, after this misuse the privacy and authenticity guarantees remain, albeit with this consideration to traffic analysis. This is a reasonable price to pay for the ability to use the HPKE APIs as more than a "single shot". DAE can achieve the equivalent of semantic security if the message space is random enough. This is the justification for the security of key wrap schemes (see ) in which (a portion of) the plaintext is a random key. SIV takes a vector of AAD. When a unique sequence number can be managed it can be part of that vector. It should be noted, therefore, that it is trivial for an application that has control of the AAD to add a nonce as a component of the AAD vector to ensure unique AAD per invocation of the HPKE API and achieve the IND-CCA2 notion of security. Alternately, for some situations-- e.g. when the message protected by HPKE is idempotent-- DAE security can be acceptable. See .

Key Wrapping Key wrapping schemes utilize a symmetric encryption algorithm to provide privacy and integrity to cryptographic keying material. Additionally, such schemes should provide integrity protection of cleartext associated data which contains control information about the wrapped key. Due to the symmetric nature of the algorithm, it is assumed both sides possess a shared secret whose establishment is problematic. Therefore HPKE is naturally an attractive option to use to wrap a cryptographic key to a receipent's public key. Since the data being wrapped is, in effect, random, a probabalistic input like a nonce is not needed, hence the deterministic nature of proposed key-wrapping schemes (see and ). is superior to those schemes in a number of ways:

it accepts associated data;
it is more efficient;
it accepts natural data lengths without requiring padding; and,
it has a security proof.

Thus, making it well-suited for key wrapping use cases with HPKE.

Requirements Notation 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

Notation This document re-uses the notation from HPKE and adds the following:

or(a,b): logical OR of byte strings; or(0x9876, 0x1234) = 0x9cf6. It is an error to call this function with two arguments of unequal length.
and(a,b): logical AND of byte strings; and(0x1234, 0x5678) = 0x1230. It is an error to call this function with two arguments of unequal length.
a | b: concatenation of byte strings "a" and "b". The length of the resulting string is the sum of the lengths of "a" and "b". If this symbol is on the left side of an equation it represents distinct data, represented by "a" and "b", as the result of the equation.

Modifying HPKE

Adding Compact Representation New DHKEMs are defined for the three NIST curves, P-256, P-384, and P-521. Being "compact", they are denoted here CP-256, CP-384, and CP-521 but are, for the purposes of cryptography, otherwise identical. All KEM modes defined in HPKE are supported for these KEMs, including Auth and AuthPSK. KEM IDs

Value	KEM	Nsecret	Nenc	Npk	Nsk	Auth	Reference
TBD1	DHKEM(CP-256, HKDF-SHA256)	32	32	32	32	yes	,
TBD2	DHKEM(CP-384, HKDF-SHA384)	48	48	48	48	yes	,
TBD3	DHKEM(CP-521, HKDF-SHA512)	64	66	66	66	yes	,

These KEMs use the KDFs defined in HPKE and therefore are bound by the input length restrictions of the KDF used (see 7.2.1 of HPKE). The security properties of these KEMs satisfy the security requirements of a KEM used in HPKE (see section 9.2 of HPKE).

SerializePublicKey and DeserializePublicKey For CP-256, CP-384 and CP-521, the SerializePublicKey() function of the KEM performs the Integer-to-Octet-String conversion of the x-coordinate of the public key only, according to . DeserializePublicKey() performs the Octet-String-to-Integer conversion of to produce the x-coordinate of a the resulting point. Since all of these curves have a prime p = 3 mod 4, the y-coordindate can be computed using the equation of the curve and Shanks' method of computing the square root modulo p: for a, b, and p defined for the curve in . There will be two distinct solutions for y that will differ only in sign but either one is acceptable to produce a Diffie-Hellman shared secret that is used in compact output. These deserialized public keys MUST be validated before they can be used. See HPKE for specifics.

SerializePrivateKey and DeserializePrivateKey As with HPKE, CP-256, CP-384, and CP-521 private keys are field elements in the scalar field of the curve being used. Serialization of the private key uses the Integer-to-OctetString function from and deserialization uses the OctetString-to-Integer function from . If the private key is an integer outside the range [0, order-1], where order for each curve is defined in , the private key MUST be reduced, modulo the order, to [0, order-1] before being serialized. To catch invalid keys early on, implementers of DHKEMs SHOULD check that deserialized private keys are not equivalent to 0 (mod order), where order is the order of the curve.

Adding A Rolling Window A rolling receiver replay window is added by overloading the way a context encrypts and decrypts messages-- ContextS.Seal() and ContextR.Open(). The calling parameters remain the same but the internals change and, for ContextS.Seal(), the output differs. The replay window is implemented as a bitmask check for a window whose size is implementation-specific. For illustration purposes only it is described here as being of size 32, meaning it can tolerate loss and reorder of the previous 31 messages. The following pseudo-code has separate routines for a quick check of a received sequence number and an update to the window for sequence numbers that have been validated. The context encryption API template is the same as that in HPKE except it prepends the sequence number, used to construct the counter for the AEAD operation, to the data returned from Seal(). Therefore the single "ct" output is, in fact, a concatenation of the four octet sequence number and the returned ciphertext. The context decryption API template is changed to extract the sequence number from the input ciphertext, and check whether the received sequence number is conditionally good. If it is and the message is successfully opened, the window is updated with the received sequence number. Details are as follows: self.seq return Good diff = self.seq - num if diff > windowSize return Bad if and(self.window, (1 << diff)) == 0 return Good else return Bad def UpdateWindow(num) if num > self.seq diff = num - self.seq if diff < windowSize self.window <<= diff self.window = or(self.window, 1) else self.window = 1 self.seq = num else diff = self.seq - num self.window = or(self.window, (1 << diff)) return def ContextS.DSeal(aad, pt): num = self.ComputeNonce(self.seq) ct = num | Seal(self.key, num, aad, pt) return ct def ContextR.DOpen(aad, m): num | ct = m if CheckSeq(num) == Bad raise OpenReplay pt = Open(self.key, num, aad, ct) if pt == OpenError raise OpenError else UpdateWindow(num) return pt ]]> The window is added to the Encryption Context as well as a single datum to indicate whether the rolling receiver replay window is used (1) or not (0). When the replay window is used, Context<ROLE>.DOpen() and Context<ROLE>.DSeal() are used, when it is not the encryption and decryption operations from HPKE are used.

Adding DAE AES-SIV, defined in uses a "double-wide" key. A single large key is passed to AES-SIV which divides the key into two, one for encipherment and the other for authenticity. Since these cipher modes are being added in their determinsitic, nonce-less varient the nonce derived for these ciphers is zero (0). Unlike other AEAD schemes, AES-SIV takes a vector of AAD. The number of components of that vector is up to the application using AES-SIV in HPKE. AEAD IDs

Value	AEAD	Nk	Nn	Reference
TBD4	AES-256-SIV	32	0
TBD5	AES-512-SIV	64	0

IANA Considerations IANA is instructed to please update the "Hybrid Public Key Encryption" repositories: Please replace the TBD placeholders above with the assigned values.

Security Considerations Since HPKE uses Diffie-Hellman in "compact output", the sign of the public keys is irrelevant. Discarding that which has no impact on the result, i.e. doing "compact representation", does not present a security issue. See for a formal security proof. Uses of the DAE ciphers in HPKE can achieve the same level of security as the non-DAE ciphers if the calling application guarantees unique AAD per invocation or if the calling application can guarantee a random message space. This opens up the possibility of misuse where an application inadvertently makes a non-unique invocation (which is a good reason to hide nonce management inside the HPKE context, as the existing AEAD ciphers do). For some use cases-- e.g. messages are idempotent, or a probabalistic operation can be achieved (e.g. key wrapping), the DAE ciphers provide an acceptable option. It deserves to be mentioned again that even if a nonce is reused (i.e. misused) by an application wishing to manage the AAD of AES-SIV, the security of the cipher is not completely voided as it is with a non-DAE mode. The notion of deterministic privacy and determinstic authenticity are retained (see ).

Acknowledgements The algorithm for the sliding window to address dropped and reordered messages was proposed by James Hughes and Harry Varnis in .

Test Vectors The following test vectors have been generated assuming the following registry value assignments would be made by IANA:

DHKEM(CP-256, HKDF-SHA256): 19
DHKEM(CP-384, HKDF-SHA384): 20
DHKEM(CP-521, HKDR-SHA512): 21
AES-256-SIV: 4
AES-512-SIV: 5

DHKEM(CP-256, HKDF-SHA256), HKDF-SHA256, AES-256-SIV

Base Setup Information

Encryption

DHKEM(CP-256, HKDF-SHA256), HKDF-SHA256, AES-256-SIV

Auth Setup Information

Encryption

DHKEM(CP-256, HKDF-SHA256), HKDF-SHA256, AES-512-SIV

Base Setup Information

Encryption

DHKEM(CP-256, HKDF-SHA256), HKDF-SHA256, AES-512-SIV

Auth Setup Information

Encryption

DHKEM(CP-256, HKDF-SHA256), HKDF-SHA512, AES-512-SIV

Auth PSK Setup Information

Encryption

DHKEM(CP-521, HKDF-SHA521), HKDF-SHA256, AES-256-SIV

Base Setup Information

Encryption

DHKEM(CP-521, HKDF-SHA521), HKDF-SHA256, AES-256-SIV

PSK Setup Information

Encryption

DHKEM(CP-521, HKDF-SHA521), HKDF-SHA256, AES-256-SIV

Auth Setup Information

Encryption

DHKEM(CP-521, HKDF-SHA521), HKDF-SHA256, AES-512-SIV

Base Setup Information

Encryption

DHKEM(CP-521, HKDF-SHA521), HKDF-SHA512, AES-512-SIV

Auth PSK Setup Information

Encryption ~~~ pt: 42656175 74792069 73207472 7574682c 20747275 74682062 65617574 79 aad: 436f756e 742d30 ct: 1bb2088e 0e946ce2 6925273d 498a474c 49c7e735 eb8d3cca ba242e98 c560d5a1 786c7982 234017bd 0f8a5985 0f pt: 42656175 74792069 73207472 7574682c 20747275 74682062 65617574 79 aad: 436f756e 742d31 ct: d5052151 1c06077c 00d7eaed 143ee355 2d1d0c44 c96227c0 c89a20e6 121f9721 e288410c 4f94955c 32097c21 51 pt: 42656175 74792069 73207472 7574682c 20747275 74682062 65617574 79 aad: 436f756e 742d32 ct: 718eaaa6 97bae275 efbc2064 cd09cd81 48e45691 7de46704 d0ff2367 46d47fb9 3936dafc 5baf0485 b61c2e43 f0 pt: 42656175 74792069 73207472 7574682c 20747275 74682062 65617574 79 aad: 436f756e 742d33 ct: 141754a9 97b92442 bff79fcb 92d51261 f45c2922 1c58f577 95863b53 c87f1fda e5c25c77 bc277abc 0508deac 55 pt: 42656175 74792069 73207472 7574682c 20747275 74682062 65617574 79 aad: 436f756e 742d34 ct: 4e2f2352 29e2281b 92d40c86 2e84f9a5 19ac0766 49b42ef6 031c5967 3fbccb97 312962f0 c51ccf0e 2395f8f0 75