[Format v2] Consider using HPKE (RFC9180)

[commial]

Context

In order to encrypt for a recipient public key (Public Key Encryption, PKE) using elliptic curve encryption (ECC), MLA uses an ECIES-like scheme.
As stated in ¹:

Elliptic Curve Integrated Encryption Scheme (ECIES) is the best known scheme based on ECC, and as such it has been included in several cryptographic standards.

Some standards based on this scheme are ANSI X9.63 (ECIES), IEEE 1363a, ISO/IEC 18033-2, and SECG SEC 1.

But, to quote ²:

The key points are that all these existing schemes have shortcomings. They either rely on outdated or not-commonly-used primitives such as RIPEMD and CMAC-AES, lack accommodations for moving to modern primitives (e.g., AEAD algorithms), lack proofs of IND-CCA2 security, or, importantly, fail to provide test vectors and interoperable implementations.

To provide a version which is modern, simple and without the aforementioned shortcoming, HPKE (Hybrid PKE) has been proposed as of RFC9180³.
This scheme is used in TLS and implemented in other cryptographic library such as OpenSSL or WolfSSL.

Proposed integration to MLA

Several aspects can be considered:

• Enhancing the current shared secret derivation in ECC
• Standardizing the integration with the AEAD scheme
• Extending to the proposed hybrid PQC (post-quantum cryptography)

Shared secret derivation in ECC

The public key derivation for the ECC could be based on this RFC.
In particular:

• the RFC9180³ introduces a scheme name DHKEM (section 4.1)
• the Auth mode (AuthEncap and AuthDecap) is not relevant for MLA (at least for now), as we don't have private key for the creator, only public keys for recipients. In other words, only the mode_base is targeted
• the targeted KEM suite corresponds to the KEM ID 0x0020:

 +=======+===============+=========+====+===+===+====+===============+
 |Value  | KEM           | Nsecret |Nenc|Npk|Nsk|Auth| Reference     |
 +-------+---------------+---------+----+---+---+----+---------------+
 |0x0020 | DHKEM(X25519, | 32      |32  |32 |32 |yes | [RFC5869],    |
 |       | HKDF-SHA256)  |         |    |   |   |    | [RFC7748]     |

Integration with the AEAD scheme

MLA targets several recipient, so HPKE can't be applied directly.
Instead, a two layer encryption could be use (a bit like ⁴):

1. for each recipient, obtain a shared secret
2. use this shared secret to decrypt the common archive key

HPKE specification introduces reusability: the secret produced can be either used with asecret export (section 5.3) or a Key schedule (5.2).

As a result, we can either:

• use the HPKE scheme to produce the key and nonce used in the current format, which is based on STREAM
• use the proposed HPKE mechanism to encrypt the two layers, which is quite close to the current MLA implementation, mainly xoring instead of suffixing the sequence number

Hybrid PQC encryption

The format v2 targets the use of Hybrid PQC encryption (#195).

Extension to the ML-KEM (such as ⁵, with the difference that we target FIPS-203 1024 instead of 768, or ⁶ defining ML-KEM-1024 as algorithm 0x0080) can be considered. To the author knowledge, there is no standard for now for hybrid PQC in HPKE, but it is likely that one might emerge.

Expected benefits

• Easier reimplementation of the format MLA, thanks to the availability of HPKE in cryptographic libraries
• An existing formal analysis ⁷
• Easier code and security auditing, thanks to the use of known bricks
• Availability of test vectors in the RFC, making the implementation more reliable
• A reviewed implementation, such as https://github.com/rozbb/rust-hpke, could be considered if compatible with inclusion of new dependencies. In addition, the implementation has been reviewed by Cloudflare ⁸ in its version 0.8
• The preshared key mode could be considered in the future of MLA to provide additional properties, such as forward secrecy (section 9.1) in some situation
• If signature is added to MLA in a future version, it could also be integrated using HPKE
• The DeriveKeyPair (section 7.1.3) can be used to provide deterministic key, such as seed derivation in mlar

Footnotes

1. A comparison of the standardized versions of ECIES, 2010 ↩

2. https://blog.cloudflare.com/hybrid-public-key-encryption ↩

3. https://datatracker.ietf.org/doc/rfc9180/ ↩ ↩²

4. https://www.ietf.org/archive/id/draft-ietf-cose-hpke-07.html#name-multiple-recipients-two-lay ↩

5. https://datatracker.ietf.org/doc/draft-reddy-cose-jose-pqc-hybrid-hpke/ ↩

6. https://www.ietf.org/archive/id/draft-connolly-cfrg-hpke-mlkem-00.html ↩

7. https://eprint.iacr.org/2020/1499.pdf ↩

8. https://blog.cloudflare.com/using-hpke-to-encrypt-request-payloads/ ↩