Network Working Group R. Barnes
Internet-Draft Cisco
Intended status: Informational K. Bhargavan
Expires: July 22, 2019 Inria
January 18, 2019

Hybrid Public Key Encryption


This 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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on July 22, 2019.

Copyright Notice

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

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 [RFC6637] and in the developing Messaging Layer Security protocol [I-D.ietf-mls-protocol].

Currently, there are numerous competing and non-interoperable standards and variants for hybrid encryption, including ANSI X9.63 [ANSI], IEEE 1363a [IEEE], ISO/IEC 18033-2 [ISO], and SECG SEC 1 [SECG]. 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.

2. 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 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Security Properties

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 [S01].

4. Notation

The following terms are used throughout this document to describe the operations, roles, and behaviors of HPKE:

5. Hybrid Public Key Encryption

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 set of concrete instantiations of these primitives is provided in Section 6. 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.

5.1. Key Encapsulation and Decapsulation

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 Section 6), 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.

Input: ciphersuite, pkR, info

1. (skE, pkE) = GenerateKeyPair()
2. zz = DH(skE, pkR)
3. secret = Extract(0^Nh, zz)
4. context = ciphersuite || Marshal(pkE) || Marshal(pkR) || info
6. keyIR = Expand(secret, "hpke key" || context, Nk)
8. nonceIR = Expand(secret, "hpke nonce" || context, Nn)

Output: pkE, keyIR, nonceIR

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.

Input: ciphersuite, pkE, skR, info

1. zz = DH(skR, pkE)
2. secret = Extract(0^Nh, zz)
3. context = ciphersuite || Marshal(pkE) || Marshal(pkR) || info
4. keyIR = Expand(secret, "hpke key" || context, Nk)
5. nonceIR = Expand(secret, "hpke nonce" || context, Nn)

Output: keyIR, nonceIR

5.2. Encryption and Decryption

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:

Input: ciphersuite, pkR, info, ad, pt

1. pkE, keyIR, nonceIR = SetupI(ciphersuite, pkR, info)
2. ct = Seal(keyIR, nonceIR, ad, pt)

Output: ct, pkE

Decryption Decrypt() mirrors encryption, as follows:

Input: ciphersuite, skR, pkE, info, ad, ct

1. keyIR, nonceIR = Decap(ciphersuite, pkE, pkR, info)
2. pt = Open(keyIR, nonceIR, ad, ct)

Output: pt

6. Ciphersuites

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 [RFC7748], and the NIST curves (P-256, P-384, P-512).

Configuration DH Group KDF AEAD Value
X25519-HKDF-SHA256-AES-GCM-128 Curve25519 HKDF-SHA256 AES-GCM-128 0x01
X25519-HKDF-SHA256-ChaCha20Poly1305 Curve25519 HKDF-SHA256 ChaCha20Poly1305 0x02
X448-HKDF-SHA512-AES-GCM-256 Curve448 HKDF-SHA512 AES-GCM-256 0x03
X448-HKDF-SHA512-ChaCha20Poly1305 Curve448 HKDF-SHA512 ChaCha20Poly1305 0x04
P256-HKDF-SHA256-AES-GCM-128 P-256 HKDF-SHA256 AES-GCM-128 0x05
P256-HKDF-SHA256-ChaCha20Poly1305 P-256 HKDF-SHA256 ChaCha20Poly1305 0x06
P521-HKDF-SHA512-AES-GCM-256 P-521 HKDF-SHA512 AES-GCM-256 0x07
P521-HKDF-SHA512-ChaCha20Poly1305 P-521 HKDF-SHA512 ChaCha20Poly1305 0x08

For 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 [SECG]. 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 [keyagreement]

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:

AES-GCM-128 16 12
AES-GCM-256 32 12
ChaCha20Poly1305 32 12

7. Security Considerations

[[ TODO ]]

8. IANA Considerations

[[ OPEN ISSUE: Should the above table be in an IANA registry? ]]

9. References

9.1. Normative References

[ANSI] "Public Key Cryptography for the Financial Services Industry -- Key Agreement and Key Transport Using Elliptic Curve Cryptography", n.d..
[IEEE] "IEEE 1363a, Standard Specifications for Public Key Cryptography - Amendment 1 -- Additional Techniques", n.d..
[ISO] "ISO/IEC 18033-2, Information Technology - Security Techniques - Encryption Algorithms - Part 2 -- Asymmetric Ciphers", n.d..
[keyagreement] Barker, E., Chen, L., Roginsky, A. and M. Smid, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography", National Institute of Standards and Technology report, DOI 10.6028/nist.sp.800-56ar2, May 2013.
[MAEA10] "A Comparison of the Standardized Versions of ECIES", n.d..
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008.
[RFC7748] Langley, A., Hamburg, M. and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.
[S01] "A Proposal for an ISO Standard for Public Key Encryption (verison 2.1)", n.d..
[SECG] "Elliptic Curve Cryptography, Standards for Efficient Cryptography Group, ver. 2", n.d..

9.2. Informative References

[I-D.ietf-mls-protocol] Barnes, R., Millican, J., Omara, E., Cohn-Gordon, K. and R. Robert, "The Messaging Layer Security (MLS) Protocol", Internet-Draft draft-ietf-mls-protocol-03, January 2019.
[RFC6637] Jivsov, A., "Elliptic Curve Cryptography (ECC) in OpenPGP", RFC 6637, DOI 10.17487/RFC6637, June 2012.

Appendix A. Possible TODOs

The following extensions to the basic HPKE functions defined above might be worth specifying:

Authors' Addresses

Richard L. Barnes Cisco EMail:
Karthik Bhargavan Inria EMail: