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>?

On Wed, Feb 21, 2024 at 2:08 PM Neil Madden <neil.e.madden@gmail.com> wrote:

> On 21 Feb 2024, at 17:16, Orie Steele <orie@transmute.industries> 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
> CFRG@irtf.org
> https://mailman.irtf.org/mailman/listinfo/cfrg
>