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 [^1]:
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.
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^3.
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^3 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:
MLA targets several recipient, so HPKE can't be applied directly.
Instead, a two layer encryption could be use (a bit like ^multi):
for each recipient, obtain a shared secret
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 ^4, with the difference that we target FIPS-203 1024 instead of 768, or ^5 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
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 ^6 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
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 [^1]:
Some standards based on this scheme are ANSI X9.63 (ECIES), IEEE 1363a, ISO/IEC 18033-2, and SECG SEC 1.
But, to quote ^2:
To provide a version which is modern, simple and without the aforementioned shortcoming, HPKE (Hybrid PKE) has been proposed as of RFC9180^3. 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:
Shared secret derivation in ECC
The public key derivation for the ECC could be based on this RFC. In particular:
Authmode (AuthEncapandAuthDecap) 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 themode_baseis targetedIntegration 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 ^multi):
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:
Hybrid PQC encryption
The format v2 targets the use of Hybrid PQC encryption (#195).
Extension to the ML-KEM (such as ^4, with the difference that we target FIPS-203 1024 instead of 768, or ^5 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
DeriveKeyPair(section 7.1.3) can be used to provide deterministic key, such as seed derivation inmlar[^1]: A comparison of the standardized versions of ECIES, 2010