While the horticulturalists over at PLANTS has been working on some really cool stuff regarding tree signatures, I wanted to revive an idea that’s been toyed with in the past: what if we move away from signature suites for handshaking, and move to exclusively AuthKEM-based handshakes?
AuthKEM has some advantages over “normal” Signatures. Chiefly, we are using signature algorithms designed to be provable to anyone, anywhere, and using them in cases where only one person will ever need to verify them. This has real impacts on the attack surface; non-constant-time signature generation can lead to key recovery attacks, implementation errors can lead to key recovery attacks, implementations can potentially be tricked into signing maliciously crafted plaintexts, etc. On the contrary, AuthKEM "proofs" are very localized; an AuthKEM "signature" can't easily be passed on and verified by third parties. Overall, 3DH-esque authentication schemes are simpler, faster, and smaller than their comparative signature-based authentication schemes. (Kyber512 is used to illustrate, but I do not recommend it's adoption) - Dilithium2 requires 3,700 bytes to communicate a pk/sig pair, whereas AuthKEM-Kyber512 requires less than half at 1,500 bytes; - Dilithium2 requires about 300kilocycles to generate a proof, whereas decapsulating a AuthKEM-Kyber512 secret can go as low as ~30kilocycles; - Dilithium2 requires both a correct constant-time PQ KEM and a correct constant-time PQ signature algorithm, whereas AuthKEM-Kyber requires only a correct constant-time PQ KEM. For example, consider the issues with Ed25519, generally considered one of the more bulletproof signature schemes available/widely deployed today: - Despite having constant-time point addition, a constant-time scalarmult ladder is required to avoid side-channels; - A single bit-flip during signing exposes the private key immediately, and implementation errors compound this problem; - This also occurs when signing with a mismatched private/public keypair (which some implementations used to allow) These benefits* have, of course, already been enumerated in the AuthKEM I-D, available here: https://datatracker.ietf.org/doc/draft-celi-wiggers-tls-authkem/ * Debatably “benefits” based on your use case, hence why I’m writing this email. That's not to say that lattice-based signature schemes are a bad idea; on the contrary, I think saying "we should only use AuthKEM for authentication" frees us to consider more optimal signature schemes for each step in the chain. For example, FN-DSA is a perfect fit for chain signatures (especially since we don't need to worry about side-channel resistance), and more exotic algorithms like SQIsign might even enter the fray. And of course, we have the eternally-cool merkle trees for root certificates. We won't need to worry about, eg, SQIsign being (mis)used for handshakes, and a side- channel key recovery attack breaking a significant portion of the encrypted internet. So, I want to pose a few questions to the mailing list: 1. Should we only consider the AuthKEM family of handshake algorithms for use within PQ CertificateVerify messages? (In other words, forbid "real" signature algorithms for use within the handshake process) 2. Should we segment handshake schemes into different use cases based on their side channel resistance? (eg, allowing FN-DSA for offline signatures, but forbidding them for online/handshake signatures) 3. Are experimental post-quantum handshakes ready to go into TLS without the seatbelt? Personally, I’d say yes: if an attack is found, loss-of-confidentiality is limited to active attacks, and clients can be updated to reject the insecure algorithm, which allows us to contain the blast radius. (This is in contrast to eg. Standalone ML-KEM, where compromise means years of retroactive confidentiality loss) Best, Joshua Nabors P.S. This has nothing to do with the dilithium2 draft published recently; if it means anything, I support its publication. P.P.S. I would like to add “Futureproofing (the) Internet’s Secure Handshaking” (FISH) to the backronyms bucket. “Marine Biologists” has a nice ring to it :^)
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
