Internet-Draft | hpke-mlkem | October 2024 |
Connolly | Expires 12 April 2025 | [Page] |
This memo defines ML-KEM-based ciphersuites for HPKE ([RFC9180]). ML-KEM is believed to be secure even against adversaries who possess a cryptographically-relevant quantum computer.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://dconnolly.github.io/draft-connolly-cfrg-hpke-mlkem/draft-connolly-cfrg-hpke-mlkem.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-connolly-cfrg-hpke-mlkem/.¶
Discussion of this document takes place on the Crypto Forum Research Group mailing list (mailto:cfrg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=cfrg. Subscribe at https://www.ietf.org/mailman/listinfo/cfrg/.¶
Source for this draft and an issue tracker can be found at https://github.com/dconnolly/draft-connolly-cfrg-hpke-mlkem.¶
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 https://datatracker.ietf.org/drafts/current/.¶
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 12 April 2025.¶
Copyright (c) 2024 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 (https://trustee.ietf.org/license-info) 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.¶
The final draft for ML-KEM is expected in 2024. For parties that must move to exclusively post-quantum algorithms, having a pure PQ choice for public-key hybrid encryption is desireable. HPKE is the leading modern protocol for public-key encryption, and ML-KEM as a post-quantum IND-CCA2-secure KEM fits nicely into HPKE's design. Supporting multiple security levels for ML-KEM allows a spectrum of use cases including settings where NIST PQ security category 5 is required.¶
ML-KEM is a plain KEM that does not support the static-static key exchange that allows HPKE based on Diffie-Hellman based KEMs its (optional) authenticated modes.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
[FIPS203] supports two different key formats, but this document only
supports the 64-byte seed (d, z)
. This format supports stronger binding
properties for ML-KEM than the expanded format that protect against
re-encapsulation attacks and bring the usage of ML-KEM in practice closer to
the generic DHKEM binding properties as defined in [RFC9180].¶
We construct 'wrapper' KEMs based on ML-KEM to bind the KEM shared secret to the KEM ciphertext, such that the final KEM has similar binding security properties as the original DHKEM which HPKE was designed around.¶
The encapsulation and decapsulation keys are computed, serialized, and
deserialized the same as in [FIPS203] where the decapsulation keys MUST be
in the 64-byte (d, z)
format. The 'expanded' format where the decapsulation
key is expanded into a variable size based on the parameter set but includes
the hash of the encapsulation key MUST NOT be used.¶
We use HKDF-SHA256 and HKDF-SHA512 as the HPKE KDFs and AES-128-GCM and AES-256-GCM as the AEADs for ML-KEM-512, ML-KEM-768, and ML-KEM-1024.¶
HPKE-ML-KEM is not an authenticated KEM and does not support AuthEncap() or AuthDecap(), see Section 1.2.¶
HPKE's IND-CCA2 security relies upon the IND-CCA and IND-CCA2 security of the underlying KEM and AEAD schemes, respectively. ML-KEM is believed to be IND-CCA secure via multiple analyses.¶
The HPKE key schedule is independent of the encapsulated KEM shared secret ciphertext of the ciphersuite KEM, and dependent on the shared secret produced by the KEM. If HPKE had committed to the encapsulated shared secret ciphertext, we wouldn't have to worry about the binding properties of the ciphersuite KEM's X-BIND-K-CT properties. These computational binding properties for KEMs were formalized in [CDM23]. [CDM23] describes DHKEM as LEAK-BIND-K-PK and LEAK-BIND-K-CT secure as result of the inclusion of the serialized DH public keys in the DHKEM KDF; however it expects pre-validated keys and never explicitly rejects, making it implicitly-rejecting KEM.¶
ML-KEM, unlike DHKEM, is also an implicitly-rejecting instantiation of the Fujisaki-Okamoto transform, meaning the ML-KEM output shared secret may be computed differently in case of decryption failure, that reults in different binding properties, such as the lack of X-BIND-CT-PK and X-BIND-CT-K completely.¶
The DHKEM construction in HPKE can provide MAL-BIND-K-PK and MAL-BIND-K-CT security (the shared secret 'binds' or uniquely determines the encapsulation key and the encapsualted shared secret ciphertext), where the adversary is able to create the key pairs any way they like in addition to the key generation. ML-KEM as specified with the seed key format provides MAL-BIND-K-CT security and LEAK-BIND-K-PK security [KEMMY24]. LEAK-BIND-K-PK security is resiliant where the involved key pairs are output by the key generation algorithm of the KEM and then leaked to the adversary. MAL-BIND-K-CT security strongly binds the shared secret and the ciphertext even when an adversary can manipulate key material like the decapsulation key.¶
ML-KEM nearly matches the binding properties of HPKE's default KEM generic construction DHKEM in being MAL-BIND-K-CT and LEAK-BIND-K-PK, and in fact exceeds the bar set by DHKEM in being MAL-BIND-K-CT secure when using the seed key format.¶
This document requests/registers two new entries to the "HPKE KEM Identifiers" registry.¶
0x0512 (please)¶
ML-KEM-512¶
32¶
768¶
800¶
1632¶
no¶
This document¶
0x0768 (please)¶
ML-KEM-768¶
32¶
1088¶
1184¶
2400¶
no¶
This document¶
0x1024 (please)¶
ML-KEM-1024¶
32¶
1568¶
1568¶
3168¶
no¶
This document¶
The authors would like to thank Cas Cremers for their input.¶
RFC Editor's Note: Please remove this section prior to publication of a final version of this document.¶
TODO¶
This section contains test vectors formatted similary to that which are found
in [RFC9180], with two changes. First, we only provide vectors for the
non-authenticated modes of operation. Secondly, as ML-KEM encapsulation does
not involve an ephemeral keypair, we omit the ikmE, skEm, pkEm entries and
provide an ier entry instead. The value of ier is the randomness used to
encapsulate, so ier[0:32]
is the seed that is fed to H in the first step of
ML-KEM encapsulation in [FIPS203].¶