> IIRC, rumour has it that those who need a FIPS-validated stack, and have > only an older stack with P-256/P-384 validated, but ML-KEM not yet > validated, can get a validated combination via ML-KEM plus ECDSA, but > not ML-KEM with X25519 or X448.
This does not make sense to me. TLS with ML-KEM, oversimplified, would be ML-KEM with stuff (the entire handshake) hashed into the secret. TLS with ML-KEM and X25519 would be ML-KEM with stuff (the entire handshake) hashed into the secret. How could it ever be allowed to hash in all the TLS-protocol messages, which contain many custom-made countermeasures against all kinds of attacks, but not the output of the algorithm we call X25519? Because X25519 has the reputation of being a key exchange? What if we used a custom algorithm which just happened to be identical/equivalent to X25519, but does not have this reputation? -- TBB
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
