Agreeing on security gains from hybrid. Should TLS ask CFRG (again?) what to do about PQC?
> From: D. J. Bernstein > > Yoav Nir writes: > > To justify a hybrid key exchange you need people who are both worried > > about quantum computers and worried about cryptanalysis or the new > > algorithms, Reminder: most in TLS WG know that Castryck and Decru broke SIKE on July 30, 2022, https://eprint.iacr.org/2022/975 but I, for one, sometimes forget details of articles, and am helped by reminders. > Google and Cloudflare encrypted quite a bit of actual user data using SIKE: > > The only reason this didn't give the user data away to today's attackers is > that > Google and Cloudflare had the common sense to insist that any post-quantum > algorithm be added as a second layer of encryption on top of the existing > X25519 layer, rather than removing the existing layer. Aka "hybrid key exchange" (= second layer), to use the Y. Nir's words. > That was in 2019. For anyone who thinks a few years of subsequent study were > enough for the public to identify which post-quantum cryptosystems are > breakable, it's useful to look at NIST's official report in July 2022 saying > that - i.e., a short time before the attack - > * SIKE is "being considered for future standardization"; [etc.] > SIKE had been advertised in 2021 as "A decade unscathed". I think I was the > only > person speaking up to object, and as far as I know there was only one other > cryptographer on record recommending against using SIKE. Section 3.8 of https://eprint.iacr.org/2021/608 recommend against using SIKE, albeit in a very artificial set-up, and not in all situations. However, I think NIST was right to promote SIKE to Round 4, as doing so continued crypto diversity. Dropping FrodoKEM, and delaying code-based KEMs to Round 4, which reduced and delayed crypto diversity, is a separate issue (and not on the topic of hybrid). Should TLS support any of these (code-based KEM, or FrodoKEM) as options in hybrid key exchange? TLS has not always limited itself to NIST-only crypto. Maybe this is a sub-question worth asking CFRG? I think fewer options, and standards alignment are important for security, by encouraging interoperability, but crypto diversity may be more important. ---------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
