dhkem: should `X25519DecapsulationKey` impl `TryDecapsulate` instead of `Decapsulate`?

[rot256]

In Sec 7.1.4 of RFC9180 it states that:

For X25519 and X448, public keys and Diffie-Hellman outputs MUST be validated as described in [RFC7748]. In particular, recipients MUST check whether the Diffie-Hellman shared secret is the all-zero value and abort if so.

I don't understand the need for this check (for KEM CCA2 security), but the RFC says it's a MUST.

Adding this check would make it a TryDecapsulate for X25519 which is annoying...

[rot256]

Here is the code in question: https://github.com/RustCrypto/KEMs/blob/master/dhkem/src/x25519_kem.rs#L91

[rot256]

Also, really annoying that the interface is different from the prime-order curves: where validation must be applied to the public keys, presumably at public key de-serialization time, whereas the zero check (only for X25519) can/MUST only be done at decapsulation time...

[tarcieri]

We were just complaining about this here, seems like a badly designed spec: dalek-cryptography/curve25519-dalek#883

I'm not sure I actually want to follow this, and anyone who wants to use the crate to implement HPKE can implement it themselves.

[rot256]

I think I agree. Maybe add a comment so you won't keep getting this comment/question... the only place where I can imagine this possibly mattering is consensus/broadcast encryption type scenarios: because you might need everyone to accept/reject consistently.

[tarcieri]

If someone is using this to implement HPKE, they need to implement that MUST.

Otherwise the KEM should be used as part of an AKE, and the AKE should reject transcript mismatches between peers, which would include things like an attacker swapping out the public key for a low order point.