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 combination of an asymmetric key encapsulation mechanism
(KEM), key derivation function (KDF), and authenticated encryption
with additional data (AEAD) encryption function. We provide
instantiations of the scheme using widely-used and efficient
primitives.“Hybrid” public-key encryption schemes (HPKE) that combine
asymmetric and symmetric algorithms are 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 cases. This type of public key encryption has many
applications in practice, for example:PGP Messaging Layer Security Encrypted Server Name Indication Protection of 5G subscriber identities 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 . All of these existing schemes have problems, e.g.,
because they rely on outdated primitives, lack proofs of IND-CCA2
security, or fail to provide test vectors.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 .[[ TODO - Provide citations to these proofs once they exist ]]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.(skX, pkX): A KEM key pair used in role X; skX is the private
key and pkX is the public keypk(skX): The public key corresponding to private key skXlen(x): The length of the octet string x, expressed as a
two-octet unsigned integer in network (big-endian) byte orderencode_big_endian(x, n): An octet string encoding the integer
value x as an n-byte big-endian valueconcat(x0, ..., xN): Concatenation of octet strings.
concat(0x01, 0x0203, 0x040506) = 0x010203040506zero(n): An all-zero octet string of length n. zero(4) =
0x00000000xor(a,b): XOR of octet strings; xor(0xF0F0, 0x1234) = 0xE2C4.
It is an error to call this function with two arguments of unequal
length.HPKE variants rely on the following primitives:A Key Encapsulation Mechanism (KEM):
GenerateKeyPair(): Generate a key pair (sk, pk)Marshal(pk): Produce a fixed-length octet string encoding the
public key pkUnmarshal(enc): Parse a fixed-length octet string to recover a
public keyEncap(pk): Generate an ephemeral symmetric key and a
fixed-length encapsulation of that key that can be decapsulated
by the holder of the private key corresponding to pkDecap(enc, sk): Use the private key sk to recover the ephemeral
symmetric key from its encapsulated representation encAuthEncap(pkR, skI) (optional): Same as Encap(), but the outputs
encode an assurance that the ephemeral shared key is known only
to the holder of the private key skIAuthDecap(skR, pkI) (optional): Same as Decap(), but the holder
of the private key skR is assured that the ephemeral shared
key is known only to the holder of the private key corresponding
to pkINenc: The length in octets of an encapsulated key from this KEMNpk: The length in octets of a public key for this KEMA 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 the error value OpenErrorNk: The length in octets of a key for this algorithmNn: The length in octets of a nonce for this algorithmA set of algorithm identifiers for concrete instantiations of these
primitives is provided in . Algorithm identifier
values are two octets long.Suppose we are given a Diffie-Hellman group that provides the
following operations: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 fixed-length shared
secretMarshal(pk): Produce a fixed-length octet string encoding the
public key pkUnmarshal(enc): Parse a fixed-length octet string to recover a
public keyThen we can construct a KEM (which we’ll call “DHKEM”) in the
following way:The GenerateKeyPair, Marshal, and Unmarshal functions are the same
as for the underlying DH group. The Marshal functions for the
curves referenced in {#ciphersuites} are as follows:P-256: The X-coordinate of the point, encoded as a 32-octet
big-endian integerP-521: The X-coordinate of the point, encoded as a 66-octet
big-endian integerCurve25519: The standard 32-octet representation of the public keyCurve448: The standard 56-octet representation of the public keyIn this section, we define a few HPKE variants. All variants take a
recipient public key and a sequence of plaintexts pt, and produce an
encapsulated key enc and a sequence of ciphertexts ct. These outputs are
constructed so that only the holder of the private key corresponding
to pkR can decapsulate the key from enc and decrypt the
ciphertexts. All of the algorithms also take an info parameter
that can be used to influence the generation of keys (e.g., to fold
in identity information) and an aad parameter that provides
Additional Authenticated Data to the AEAD algorithm in use.In addition to the base case of encrypting to a public key, we
include two authenticated variants, one of which authenticates
possession of a pre-shared key, and one of which authenticates
possession of a KEM private key. The following one-octet values
will be used to distinguish between modes:ModeValuemode_base0x00mode_psk0x01mode_auth0x02mode_psk_auth0x03All of these cases follow the same basic two-step pattern:Set up an encryption context that is shared between the sender
and the recipientUse that context to encrypt or decrypt contentA “context” encodes the AEAD algorithm and key in use, and manages
the nonces used so that the same nonce is not used with multiple
plaintexts.The procedures described in this session are laid out in a
Python-like pseudocode. The algorithms in use are left implicit.The variants of HPKE defined in this document share a common
mechanism for translating the protocol inputs into an encryption
context. The key schedule inputs are as follows:pkR - The receiver’s public keyzz - A shared secret generated via the KEM for this transactionenc - An encapsulated key produced by the KEM for the receiverinfo - Application-supplied information (optional; default value
“”)psk - A pre-shared secret held by both the initiator
and the receiver (optional; default value zero(Nh)).pskID - An identifier for the PSK (optional; default
value "" = zero(0)pkI - The initiator’s public key (optional; default
value zero(Npk))The psk and pskID fields MUST appear together or not at all.
That is, if a non-default value is provided for one of them, then
the other MUST be set to a non-default value.The key and nonce computed by this algorithm have the property that
they are only known to the holder of the receipient private key, and
the party that ran the KEM to generate zz and enc. If the psk
and pskID arguments are provided, then the recipient is assured
that the initiator held the PSK. If the pkIm argument is
provided, then the recipient is assued that the initator held the
corresponding private key (assuming that zz and enc were
generated using the AuthEncap / AuthDecap methods; see below).Note that the context construction in the KeySchedule procedure is
equivalent to serializing a structure of the following form in the
TLS presentation syntax:The most basic function of an HPKE scheme is to enable encryption
for the holder of a given KEM private key. The SetupBaseI() and
SetupBaseR() procedures establish contexts that can be used to
encrypt and decrypt, respectively, for a given private key.The the shared secret produced by the KEM is combined via the KDF
with information describing the key exchange, as well as the
explicit info parameter provided by the caller.This variant extends the base mechansism by allowing the recipient
to authenticate that the sender possessed a given pre-shared key
(PSK). We assume that both parties have been provisioned with both
the PSK value psk and another octet string pskID that is used to
identify which PSK should be used.The primary differences from the base case are:The PSK is used as the salt input to the KDF (instead of 0)The PSK ID is added to the context string used as the info input
to the KDFThis mechanism is not suitable for use with a low-entropy password
as the PSK. A malicious recipient that does not possess the PSK can
use decryption of a plaintext as an oracle for performing offline
dictionary attacks.This variant extends the base mechansism by allowing the recipient
to authenticate that the sender possessed a given KEM private key.
This assurance is based on the assumption that
AuthDecap(enc, skR, pkI) produces the correct shared secret
only if the encapsulated value enc was produced by
AuthEncap(pkR, skI), where skI is the private key corresponding
to pkI. In other words, only two people could have produced this
secret, so if the recipient is one, then the sender must be the
other.The primary differences from the base case are:The calls to Encap and Decap are replaced with calls to
AuthEncap and AuthDecap.The initiator public key is added to the context stringObviously, this variant can only be used with a KEM that provides
AuthEncap() and AuthDecap() procuedures.This mechanism authenticates only the key pair of the initiator, not
any other identity. If an application wishes to authenticate some
other identity for the sender (e.g., an email address or domain
name), then this identity should be included in the info parameter
to avoid unknown key share attacks.This mode is a straightforward combination of the PSK and
authenticated modes. The PSK is passed through to the key schedule
as in the former, and as in the latter, we use the authenticated KEM
variants.HPKE allows multiple encryption operations to be done based on a
given setup transaction. Since the public-key operations involved
in setup are typically more expensive than symmetric encryption or
decryption, this allows applications to “amortize” the cost of the
public-key operations, reducing the overall overhead.In order to avoid nonce reuse, however, this decryption must be
stateful. Each of the setup procedures above produces a context
object that stores the required state:The AEAD algorithm in useThe key to be used with the AEAD algorithmA base nonce valueA sequence number (initially 0)All of these fields except the sequence number are constant. The
sequence number is used to provide nonce uniqueness: The nonce used
for each encryption or decryption operation is the result of XORing
the base nonce with the current sequence number, encoded as a
big-endian integer of the same length as the nonce. Implementations
MAY use a sequence number that is shorter than the nonce (padding on
the left with zero), but MUST return an error if the sequence number
overflows.Each encryption or decryption operation increments the sequence
number for the context in use. A given context SHOULD be used either
only for encryption or only for decryption.It is up to the application to ensure that encryptions and
decryptions are done in the proper sequence, so that the nonce
values used for encryption and decryption line up.ValueKEMNencNpkReference0x0000(reserved)N/AN/AN/A0x0001DHKEM(P-256)32320x0002DHKEM(Curve25519)32320x0003DHKEM(P-521)65650x0004DHKEM(Curve448)5656For 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.ValueKDFNhReference0x0000(reserved)N/AN/A0x0001HKDF-SHA256320x0002HKDF-SHA51264ValueAEADNkNnReference0x0000(reserved)N/AN/AN/A0x0001AES-GCM-12816120x0002AES-GCM-25632120x0003ChaCha20Poly13053212[[ TODO ]][[ TODO: Make IANA registries for the above ]]Key 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]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 CryptographyDigital Signature Standard (DSS)Recommendation for block cipher modes of operation :Security architecture and procedures for 5G SystemElliptic 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 clients 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.Encrypted Server Name Indication for TLS 1.3This document defines a simple mechanism for encrypting the Server Name Indication for TLS 1.3.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.HMAC-based Extract-and-Expand Key Derivation Function (HKDF)This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes.ChaCha20 and Poly1305 for IETF ProtocolsThis document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data (AEAD) algorithm.RFC 7539, the predecessor of this document, was meant to serve as a stable reference and an implementation guide. It was a product of the Crypto Forum Research Group (CFRG). This document merges the errata filed against RFC 7539 and adds a little text to the Security Considerations section.The following extensions might be worth specifying: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