+1 Happy to help. We would like to migrate from SHA-2 to SHA-3/(Turbo)SHAKE/KMAC wherever possible. Beyond its significant theoretical weaknesses (such as length-extension attacks and not behaving as a random function), SHA-2 also has practical drawbacks. Systems based on SHA-2, HMAC, HKDF, and MGF1 are considerably more complex and significantly more difficult to implement in a side-channel-resistant manner than equivalent constructions based on SHA-3 and its derived functions.
Because Ed25519 depends on SHA-512, we are using Ed448 instead of Ed25519. It is a real shame that SSHM is planning to standardize ML-KEM with SHA-2. Cheers, John Preuß Mattsson From: Kris Kwiatkowski <[email protected]> Date: Thursday, 2 July 2026 at 18:22 To: [email protected] <[email protected]> Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08) ps. On the same vein -- It would be absolutely fantastic if we could get rid of HKDF as it is the one thing in TLS 1.3 forcing masked SHA2 on my chip. As a symmetric cryptography design, HKDF is about as inelegant as possible, and currently one of the hardest things to mask & secure in hardware. Arguably better SHA3-based KDFs have existed for a long time, and I'd like to use my masked Keccak module for KDF. But that's perhaps for later. And then both MLKEM.Decaps and KDF could share same masked Keccak implementation, reducing area needed for it. +1
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
