Subject: Re: [CFRG] More custom kem combiners: ML-KEM and ECDH with P-256

From: "Dang, Quynh H. (Fed)" <[email-masked]>
Date: Mon, 26 Feb 2024 12:40:13 +0000

From: CFRG <[email-masked]> On Behalf Of Deirdre Connolly
Sent: Wednesday, February 21, 2024 4:11 PM
To: Neil Madden <[email-masked]>
Cc: CFRG <[email-masked]>
Subject: Re: [CFRG] More custom kem combiners: ML-KEM and ECDH with P-256

Ah good, someone else noticed!

> They are using HKDF and chaining things via the salt parameter, which AFAICT is what WireGuard, Signal,

Signal PQXDH<https://signal.org/docs/specifications/pqxdh/#sending-the-initial-message> (their hybrid update to X3DH) used HKDF with the salt parameter encoding the hash output length in bytes and the input key material as the common concatenated shared secrets with some other information as input; it doesn't look like they are chaining that invocation of HKDF by including prior secret material in the salt parameter.

Apple<https://security.apple.com/assets/files/Security_analysis_of_the_iMessage_PQ3_protocol_Stebila.pdf> is chaining 2 HKDF-Extracts and then a final HKDF-Expand (binding session information and transcript material via the label), and uses the whole thing as a KDF.

Is this design possibly informed by results on HMAC as a dual-PRF<https://eprint.iacr.org/2023/861.pdf>?
[Dang, Quynh H. (Fed)] I am not sure I understood the question above.  Is this paper https://eprint.iacr.org/2023/861.pdf  a good one to go over ?

Regards,
Quynh.

On Wed, Feb 21, 2024 at 2:08 PM Neil Madden <[email-masked]<mailto:[email-masked]>> wrote:
On 21 Feb 2024, at 17:16, Orie Steele <[email-masked]<mailto:[email-masked]>> wrote:

Looks like Apple just announced they are going to use a custom kem combiner with ML-KEM and ECDH with P-256.

https://security.apple.com/blog/imessage-pq3/

Here is the security analysis paper: https://security.apple.com/assets/files/Security_analysis_of_the_iMessage_PQ3_protocol_Stebila.pdf

(The “KEM combiner” is in section 3.5.2).

They are using HKDF and chaining things via the salt parameter, which AFAICT is what WireGuard, Signal, Noise, TLS, IPSec, and now apparently iMessage all do. I’ve actually been surprised that that hasn’t been proposed here, as it seems like a de facto standard.

You might object that they all do this for *PSKs*, not for KEM combining, but at least the WireGuard author has explicitly stated that they intended the PSK mechanism exactly for mixing in the result of a post-quantum key exchange:

https://www.reddit.com/r/linux/comments/hzyu8j/comment/fzmd983/

(You might even say this *is* a PSK, it just happens to have been “pre-shared” very recently… during the same handshake…)

It's not obvious to me if this is using a DHKem like those registered in HPKE or if it's some custom construction.

It’s using ECDH, not a KEM, for the DH part. (I mean DHKEM basically is ECIES, so it’s not like there’s a massive difference).

— Neil
_______________________________________________
CFRG mailing list
[email-masked]<mailto:[email-masked]>
https://mailman.irtf.org/mailman/listinfo/cfrg