Hybrid Public Key EncryptionCiscorlb@ipv.sxInriakarthikeyan.bhargavan@inria.frInternet-DraftThis document describes a scheme for hybrid public-key encryption (HPKE). This scheme provides authenticated public key
encryption of arbitrary-sized plaintexts for a recipient public key. HPKE works
for any Diffie-Hellman group and has a strong security proof. We provide instantiations
of the scheme using standard and efficient primitives.Hybrid public-key encryption (HPKE) is a substantially more efficient solution
than traditional public key encryption techniques such as those based on RSA or ElGamal.
Encrypted messages convey a single ciphertext and authentication tag alongside a short public
key, which may be further compressed. The key size and computational complexity of elliptic
curve cryptographic primitives for authenticated encryption therefore make it compelling for
a variety of use case. This type of public key encryption has many applications in practice,
for example, in PGP and in the developing Messaging Layer Security protocol
.Currently, there are numerous competing and non-interoperable standards and variants for hybrid encryption, including
ANSI X9.63 , IEEE 1363a , ISO/IEC 18033-2 , and SECG SEC 1 . Lack of a single
standard makes selection and deployment of a compatible, cross-platform and ecosystem
solution difficult to define. This document defines an HPKE scheme that provides a subset of the
functions provided by the collection of schemes above, but specified with sufficient clarity
that they can be interoperably implemented and formally verified.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 BCP14 when, and only when, they appear in all capitals, as shown here.As a hybrid authentication encryption algorithm, we desire security against (adaptive)
chosen ciphertext attacks (IND-CCA2 secure). The HPKE variants described in this document achieve
this property under the Random Oracle model assuming the gap Computational Diffie
Hellman (CDH) problem is hard .The following terms are used throughout this document to describe the
operations, roles, and behaviors of HPKE:Initiator (I): Sender of an encrypted message.Responder (R): Receiver of an encrypted message.Ephemeral (E): A fresh random value meant for one-time use.||: Concatenation of octet strings, i.e., 0x01 || 0x02 = 0x0102.HPKE takes as input a recipient public key pkR and plaintext
pt and produces, as output, an ephemeral public key pkE and ciphertext ct. The
ciphertext is encrypted such that only the owner of the private key associated with pkR
can decrypt the ciphertext ct to recover the plaintext pt. In the
algorithms defined below, we also allow the inclusion of Additional
Authenticated Data (AAD) which is authenticated, but not encrypted
(as with an AEAD encryption algorithm).HPKE variants rely on the following primitives:A Diffie-Hellman scheme:
GenerateKeyPair(): Generate an ephemeral key pair (sk, pk)
for the DH group in useDH(sk, pk): Perform a non-interactive DH exchange using the
private key sk and public key pk to produce a shared secretMarshal(pk): Produce a fixed-length octet string encoding the
public key pkA Key Derivation Function:
Extract(salt, IKM): Extract a pseudorandom key of fixed length
from input keying material IKM and an optional octet string
saltExpand(PRK, info, L): Expand a pseudorandom key PRK using
optional string info into L bytes of output keying materialNh: The output size of the Extract functionAn AEAD encryption algorithm :
Seal(key, nonce, aad, pt): Encrypt and authenticate plaintext
pt with associated data aad using secret key key and nonce
nonce, yielding ciphertext and tag ctOpen(key, nonce, aad, ct): Decrypt ciphertext ct using
associated data aad with secret key key and nonce nonce,
returning plaintext message pt or an errorNk: The length in octets of a key for this algorithmNn: The length in octets of a nonce for this algorithmA set of concrete instantiations of these primitives is provided in
. Ciphersuite values are one octet long.In the algorithms that follow, let Nk be the length in bytes of a
symmetric key suitable for encryption and decryption with the AEAD
scheme in use, and let Nn be the length of a in bytes of a suitable
nonce.HPKE uses DH to generate an ephemeral secret that is shared
between the sender and the receiver, then uses this secret to
generate one or more (key, nonce) pairs for use with an
Authenticated Encryption with Associated Data (AEAD) algorithm.In the below algorithms, the various functions and variables
specific to the underlying primitives (Expand, Nn, etc.) are
understood to be in the context of the specified ciphersuite.The SetupI() procedure takes as input a ciphersuite (see ),
peer public key, and info string and generates a shared secret value and a public
key that the receiver can use to recover shared secret.In step 3, the octet string 0^Nh is the all-zero octet string of
length Nh. Note that step 4 includes the recipient public key in
the key derivation step so that the derived key is bound to the
recipient.The SetupR() procedure takes as input a ciphersuite, encapsulated
secret, secret key, and info string to produce a shared secret.HPKE encryption Encrypt() and decryption Decrypt() are single-shot so
shared secrets are never re-used. Encrypt() takes as input
plaintext pt and associated data ad to encrypt, along with the ciphersuite,
Responder public key, and an info string, and produces a ciphertext ct and
encapsulated ephemeral key secretIR, as follows:Decryption Decrypt() mirrors encryption, as follows:The HPKE variants as presented will function correctly for any
combination of primitives that provides the functions described
above. In this section, we provide specific instantiations of these
primitives for standard groups, including: Curve25519, Curve448 , and
the NIST curves (P-256, P-384, P-512).ConfigurationDH GroupKDFAEADValueX25519-HKDF-SHA256-AES-GCM-128Curve25519HKDF-SHA256AES-GCM-1280x01X25519-HKDF-SHA256-ChaCha20Poly1305Curve25519HKDF-SHA256ChaCha20Poly13050x02X448-HKDF-SHA512-AES-GCM-256Curve448HKDF-SHA512AES-GCM-2560x03X448-HKDF-SHA512-ChaCha20Poly1305Curve448HKDF-SHA512ChaCha20Poly13050x04P256-HKDF-SHA256-AES-GCM-128P-256HKDF-SHA256AES-GCM-1280x05P256-HKDF-SHA256-ChaCha20Poly1305P-256HKDF-SHA256ChaCha20Poly13050x06P521-HKDF-SHA512-AES-GCM-256P-521HKDF-SHA512AES-GCM-2560x07P521-HKDF-SHA512-ChaCha20Poly1305P-521HKDF-SHA512ChaCha20Poly13050x08For the NIST curves P-256 and P-521, the Marshal function of the DH
scheme produces the normal (non-compressed) representation of the
public key, according to . When these curves are used, the
recipient of an HPKE ciphertext MUST validate that the ephemeral public
key pkE is on the curve. The relevant validation procedures are
defined in For the CFRG curves
Curve25519 and Curve448, the Marshal function is the identity
function, since these curves already use fixed-length octet strings
for public keys.The values Nk and Nn for the AEAD algorithms referenced above
are as follows:AEADNkNnAES-GCM-1281612AES-GCM-2563212ChaCha20Poly13053212[[ TODO ]][[ OPEN ISSUE: Should the above table be in an IANA registry? ]]A Proposal for an ISO Standard for Public Key Encryption (verison 2.1)Public Key Cryptography for the Financial Services Industry -- Key Agreement and Key Transport Using Elliptic Curve CryptographyIEEE 1363a, Standard Specifications for Public Key Cryptography - Amendment 1 -- Additional TechniquesISO/IEC 18033-2, Information Technology - Security Techniques - Encryption Algorithms - Part 2 -- Asymmetric CiphersElliptic Curve Cryptography, Standards for Efficient Cryptography Group, ver. 2A Comparison of the Standardized Versions of ECIESRecommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm CryptographyKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.An Interface and Algorithms for Authenticated EncryptionThis document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. [STANDARDS-TRACK]Elliptic Curves for SecurityThis memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.Elliptic Curve Cryptography (ECC) in OpenPGPThis document defines an Elliptic Curve Cryptography extension to the OpenPGP public key format and specifies three Elliptic Curves that enjoy broad support by other standards, including standards published by the US National Institute of Standards and Technology. The document specifies the conventions for interoperability between compliant OpenPGP implementations that make use of this extension and these Elliptic Curves. [STANDARDS-TRACK]The Messaging Layer Security (MLS) ProtocolMessaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two participants need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy and post-compromise security for groups in size ranging from two to thousands.The following extensions to the basic HPKE functions defined above
might be worth specifying:Use of general KEM - It could be useful to define the routines in
this document in terms of a general KEM, as opposed to just DH.
For example, there are currently more post-quantum KEM proposals
than DH proposals.Sender authentication - It is possible to enable a degree of
sender authentication by mixing in a long-term key for the sender
of a ciphertext as well as the recipient. This is done, for
example, in the libnacl “box” function.PSK authentication - A pre-shared key could be folded into the key
schedule as another form of authentication.Streaming (multi-message) encryption - In many use cases, it is
useful to amortize the cost of the DH operation over several AEAD
encryptions.Multiple recipients - It might be possible to add some
simplifications / assurances for the case where the same value is
being encrypted to multiple recipients.Test vectors - Obviously, we can provide decryption test vectors
in this document. In order to provide known-answer tests, we
would have to introduce a non-secure deterministic mode where the
ephemeral key pair is derived from the inputs. And to do that
safely, we would need to augment the decrypt function to detect
the deterministic mode and fail.A reference implementation in hacspec or similar