[TLS] Boring cryptography, and the opposite extreme
"D. J. Bernstein" <djb@cr.yp.to> Fri, 04 April 2025 18:15 UTC
Return-Path: <djb-dsn2-1406711340.7506@cr.yp.to>
X-Original-To: tls@mail2.ietf.org
Delivered-To: tls@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 64EBE17ACB50 for <tls@mail2.ietf.org>; Fri, 4 Apr 2025 11:15:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.697
X-Spam-Level:
X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_SBL_A=0.1] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eijMGFlWVHrt for <tls@mail2.ietf.org>; Fri, 4 Apr 2025 11:15:38 -0700 (PDT)
Received: from salsa.cs.uic.edu (salsa.cs.uic.edu [131.193.32.108]) by mail2.ietf.org (Postfix) with SMTP id 361E817ACB48 for <tls@ietf.org>; Fri, 4 Apr 2025 11:15:38 -0700 (PDT)
Received: (qmail 24084 invoked by uid 1010); 4 Apr 2025 18:15:37 -0000
Received: from unknown (unknown) by unknown with QMTP; 4 Apr 2025 18:15:37 -0000
Received: (qmail 159294 invoked by uid 1000); 4 Apr 2025 18:15:27 -0000
Date: Fri, 04 Apr 2025 18:15:27 -0000
Message-ID: <20250404181527.159292.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: tls@ietf.org
Mail-Followup-To: tls@ietf.org
In-Reply-To: <CACf5n7-7v3BgVYJ708uChktN4k-Se9d_v7daD0fQyQHobR=Jfw@mail.gmail.com>
Message-ID-Hash: 7J57BPEPXMNCEIYM2IWVHTAFCXJT6RZS
X-Message-ID-Hash: 7J57BPEPXMNCEIYM2IWVHTAFCXJT6RZS
X-MailFrom: djb-dsn2-1406711340.7506@cr.yp.to
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Boring cryptography, and the opposite extreme
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ub3ytZRDsFRuKv4LqN7IfiYTxuA>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>
David Adrian writes: > Lattice cryptography is "boring" crypto at this point I think it's useful to explain that this concept of boring crypto is meant as a positive statement. The name comes from the "boring-crypto" mailing list that I started in 2013, inspired by earlier boring-is-good examples under other names, such as Ian Grigg's One True Cipher Suite. Adam Langley introduced BoringSSL in 2014, with a disclaimer that "the name is aspirational and not yet a promise". Here are more detailed explanations of the concept: https://cr.yp.to/talks.html#2015.10.05 https://speakerdeck.com/vixentael/dont-waste-time-on-learning-cryptography-better-use-it-properly With this background in mind, I'm astonished by the claim that lattice crypto qualifies as boring. Here's one of my slides from 2015: TLS is not boring crypto. New attacks! Disputes about security! Improved attacks! Proposed fixes! Even better attacks! Emergency upgrades! Different attacks! New protocol versions! Continual excitement; tons of research papers; more jobs for cryptographers. A decade later, one can replace "TLS" with "lattice-based cryptography" on the top line, and the rest of the slide fits perfectly. Consider, e.g., FrodoKEM, which is supposed to be the safest lattice KEM, an instantiation of https://eprint.iacr.org/2010/613. This 2010 paper estimated "about 2^150 operations" to break lattice dimension 256, something that today sounds absurd because attacks have improved so much. Everything else I'll say about FrodoKEM is more recent than that. There was an official FrodoKEM software patch in 2020 to address the security problem that https://ia.cr/2020/743 pointed out. This patch introduced a new security problem, as https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/kSUKzDNc5ME/m/EMFYz9RNCAAJ. pointed out, and then there was another official FrodoKEM software patch to address that. There was then an official patch to the FrodoKEM cryptosystem and software in 2023 to address the security problem that https://cr.yp.to/papers.html#footloose pointed out. This was accompanied by a documentation patch renaming the previous version of FrodoKEM as "ephemeral FrodoKEM" to indicate that you're not supposed to keep using it for many ciphertexts, never mind the fact that it was previously portrayed as being safe for any number of ciphertexts. If you ask what exactly FrodoKEM's IND-CCA2 security level is claimed to be, you'll find Table 2 of the official 2021 FrodoKEM documentation https://web.archive.org/web/20230224071445/https://frodokem.org/files/FrodoKEM-specification-20210604.pdf claiming 2^141 pre-quantum IND-CCA2 security for Frodo-640. But, wait, what about _post-quantum_ IND-CCA2 security, given that the actual problem at hand is to protect against quantum attacks? You have to read until page 32 to find out why the post-quantum IND-CCA2 numbers were suppressed: namely, they're terrifyingly small. Here's how the official documentation puts it: the underlying calculation "does not concretely support the bit-security of the six FrodoKEM instantiations in this document, which is why we omit the corresponding column from Table 2". As one of the arguments that FrodoKEM is conservative, page 42 claims that sieving algorithms with time exponents below 0.415b have "memory complexities as large as time complexities". You can see from, e.g., https://eprint.iacr.org/2015/522 and https://eprint.iacr.org/2015/1128 that this claim was already wrong when FrodoKEM was first submitted to the NIST competition. How is it possible that, in 2025, I'm pointing out that an official, non-retracted, FrodoKEM claim of being "conservative" is pointing to a barrier that was already broken in 2015? Could this maybe have something to do with lattice security being an extremely complicated topic, and with security reviewers being overloaded? Page 42 also claims that sieving algorithms below 0.415b have "much less predictable memory access patterns" than sequential memory access. This was true for a while---and is also the foundation of https://web.archive.org/web/20231219201240/https://csrc.nist.gov/csrc/media/Projects/post-quantum-cryptography/documents/faq/Kyber-512-FAQ.pdf from 2023---but has been solidly debunked by two undisputed papers https://cic.iacr.org/p/1/3/6 (asymptotics) and https://eprint.iacr.org/2024/739 (concrete costs and demos) showing that the memory-access exponents in these attacks can be optimized to add very little on top of the costs of computation. Let's review what we've seen. New attacks? Yes. Disputes about security? Yes. Improved attacks? Yes. Proposed fixes? Yes. Even better attacks? Yes. Emergency upgrades? Yes. Different attacks? Yes. New protocol versions? Yes: the FrodoKEM security patch in 2023 wasn't interoperable. Continual excitement? Yes. Tons of research papers? Yes. More jobs for cryptographers? Regarding FrodoKEM in particular, maybe not, but for lattice-based cryptography overall, certainly, as https://martinralbrecht.wordpress.com/2024/11/29/phd-position-in-lattice-based-cryptography/ illustrates. This is the opposite of boring cryptography. ---D. J. Bernstein
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… John Mattsson
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Thom Wiggers
- [TLS] WG Adoption Call for ML-KEM Post-Quantum Ke… Sean Turner
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Russ Housley
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Rebecca Guthrie
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Salz, Rich
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Yaroslav Rosomakho
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… D. J. Bernstein
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Sun Shuzhou
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Martin Thomson
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Viktor Dukhovni
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Yaakov Stein
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… David Adrian
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Loganaden Velvindron
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Kris Kwiatkowski
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Deirdre Connolly
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Filippo Valsorda
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Jan Schaumann
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Salz, Rich
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Filippo Valsorda
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Bellebaum, Thomas
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Deirdre Connolly
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Alicja Kario
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… D. J. Bernstein
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Loganaden Velvindron
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… tirumal reddy
- [TLS] Re: [EXTERNAL] Re: WG Adoption Call for ML-… Yaakov Stein
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Joseph Birr-Pixton
- [TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM P… Rob Sayre
- [TLS] Boring cryptography, and the opposite extre… D. J. Bernstein
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Blumenthal, Uri - 0553 - MITLL
- [TLS] Re: [EXTERNAL] Re: WG Adoption Call for ML-… Andrei Popov
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Sean Turner
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Scott Fluhrer (sfluhrer)
- [TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM P… Blumenthal, Uri - 0553 - MITLL
- [TLS] Re: Boring cryptography, and the opposite e… D. J. Bernstein
- [TLS] Re: Boring cryptography, and the opposite e… Bas Westerbaan
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Loganaden Velvindron
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Flo D
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Salz, Rich
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Quynh Dang
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Sean Turner
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Andrey Jivsov
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Benjamin Kaduk
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Rob Sayre
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… D. J. Bernstein
- [TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM P… Blumenthal, Uri - 0553 - MITLL
- [TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM P… Nico Williams
- [TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM P… D. J. Bernstein
- [TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM P… Nico Williams
- [TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM P… Stephen Farrell
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Flo D
- [TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM P… D. J. Bernstein
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… David Adrian
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Salz, Rich
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Stephen Farrell
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Flo D
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Bellebaum, Thomas
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Bas Westerbaan
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Bas Westerbaan
- [TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM P… Bellebaum, Thomas
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Paul Wouters
- [TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM P… Blumenthal, Uri - 0553 - MITLL
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Paul Wouters
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Viktor Dukhovni
- [TLS] Re: [EXT] Re: Boring cryptography, and the … Blumenthal, Uri - 0553 - MITLL
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Stephen Farrell
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Rob Sayre
- [TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM P… Blumenthal, Uri - 0553 - MITLL
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Salz, Rich
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Nico Williams
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Bellebaum, Thomas
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Bellebaum, Thomas
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Salz, Rich
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… D. J. Bernstein
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Bellebaum, Thomas
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Paul Wouters
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Bellebaum, Thomas
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Loganaden Velvindron
- [TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM P… Blumenthal, Uri - 0553 - MITLL
- [TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM P… Stephen Farrell
- [TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM P… Blumenthal, Uri - 0553 - MITLL
- [TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM P… Blumenthal, Uri - 0553 - MITLL
- [TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM P… Stephen Farrell
- [TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM P… Nico Williams
- [TLS] Re: [EXTERNAL] Re: [EXT] Re: WG Adoption Ca… Andrei Popov
- [TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM P… Salz, Rich
- [TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM P… Rob Sayre
- [TLS] Re: [EXTERNAL] Re: [EXT] Re: WG Adoption Ca… Deirdre Connolly
- [TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM P… Blumenthal, Uri - 0553 - MITLL
- [TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM P… Benjamin Kaduk
- [TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM P… Nico Williams
- [TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM P… Salz, Rich
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… D. J. Bernstein
- [TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM P… Blumenthal, Uri - 0553 - MITLL
- [TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM P… Loganaden Velvindron
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… D. J. Bernstein
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Sean Turner
- [TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM P… Watson Ladd
- [TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM P… Blumenthal, Uri - 0553 - MITLL
- [TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM P… Andrey Jivsov
- [TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM P… S Moonesamy
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… S Moonesamy
- [TLS] Re: WG Adoption Call for ML-KEM Post-Quantu… Sean Turner