@Daniel J. Bernstein
Designing cryptography (deployed now: X25519, Ed25519, ChaCha20, sntrup, Classic McEliece) to proactively reduce risks. Coined phrase "post-quantum" in 2003.
Relays (1)
- wss://relay.ditto.pub – read & write
Recent Notes
Posted new paper "Exploiting ML-DSA bugs" and demo scripts: https://cr.yp.to/papers.html#mldsa The current panic to roll out new ML-DSA code in place of ECC signatures will give away tons of keys to attackers through the predictable flood of efficiently exploitable software vulnerabilities.
nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyd968gmewwp6kyqpq97qqqj2gfydepp0prr33atwsvr06u2gvymd6ek5vrcypwwh92f7q8dy6rq I read your old post on key sizes, unfortunately still relevant: https://blog.cr.yp.to...
@nprofile1q... Yeah, it's very low cost to just use 256-bit secrets everywhere. I commented on this in more detail in https://cr.yp.to/papers.html#bruteforce.
"Safety blanket" in https://web.archive.org/web/20260414114106/https://soatok.blog/2026/04/13/hybrid-constructions-the-post-quantum-safety-blanket/ and https://web.archive.org/web/20260418021002/https://symbolic.software/blog/2026-04-13-hybrid-constructions/ tells typical readers: using ECC+PQ, not just PQ, is for familiarity, not security. Huh? Millions of sessions used CECPQ2b=ECC+SIKE. ECC is the _only_ reason those weren't instantly exposed to the SIKE break.
https://web.archive.org/web/20260418042422/https://security.googleblog.com/2016/07/experimenting-with-post-quantum.html points to quantum threats _and_ the risk of PQ deployments being "breakable even with today's computers". See the difference from @kaepora claiming (https://web.archive.org/web/20260418021002/https://symbolic.software/blog/2026-04-13-hybrid-constructions/) that what "motivates hybrid KEMs" is "the harvest-now-decrypt-later (HNDL) threat"?
Cross-posting the Mastodon+Twitter results for comparison. Mastodon (215 replies): 9% "clearly trustworthy", 58% "Hmmm, I'm skeptical", 33% "I hate cryptographers". Twitter (69 replies): 11.6%, 65.2%, 23.2%. https://mastodon.cr.yp.to/@djb/116382470987007356 https://x.com/hashbreaker/status/2042712462487585022
Why add a PQ layer? To try to reduce the damage caused by quantum computers. Why also keep the existing (low-cost) ECC layer? To try to reduce the damage from further PQ security failures. For some reason this suddenly seems difficult for U.S. military contractors to understand.
nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyd968gmewwp6kyqpq7qejctd76jm8syfmpkde4nlur4avy2fhthwk75yce2ykes08zqjsmpph0g I am inclined to agree with nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyd968gmewwp6kyqpq97q...
@nprofile1q... @nprofile1q... Here's the obvious, straightforward hybrid ECC+PQ signature system (from, e.g., https://cr.yp.to/talks.html#2016.02.24): to sign, sign with ECC and with PQ; to verify, verify both signatures. This combiner is even fewer lines of code than typical KEM combiners.
Screwups for encryption and for signatures in some non-TLS protocols motivate _slightly_ more complicated approaches that I recommend for key exchange (Chempat) and for signatures (Mothma). TLS could use these but doesn't need to.
Screwups for encryption and for signatures in some non-TLS protocols motivate _slightly_ more complicated approaches that I recommend for key exchange (Chempat) and for signatures (Mothma). TLS could use these but doesn't need to.
nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyd968gmewwp6kyqpq97qqqj2gfydepp0prr33atwsvr06u2gvymd6ek5vrcypwwh92f7q8dy6rq OpenSSH started warning about the lack of PQ, which should help adoption (when will br...
@nprofile1q... There's certainly a risk-reduction argument for combining more systems, but most combinations will have people complaining: "wait, here's an application that can't afford this". What's nice about the ECC+PQ combination in particular is that its total cost (communication plus computation for both parts) is coming almost entirely from the PQ part. Opponents have been trying to find _any_ examples where PQ is affordable while ECC+PQ isn't, and have been reaching comic levels of failure.
nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyd968gmewwp6kyqpq97qqqj2gfydepp0prr33atwsvr06u2gvymd6ek5vrcypwwh92f7q8dy6rq These proposals are broken so quickly that it would be a good idea IMO to put the brak...
@nprofile1q... Well, the problem with _not_ rolling anything out is that then we're not even _trying_ to deal with the quantum risk.
Hybrids (double encryption, double signatures) nicely resolve this tension: we roll out a post-quantum layer to _try_ to protect against quantum computers, while (at very low cost) keeping the existing ECC layer to reduce the damage if the post-quantum layer is broken.
Hybrids (double encryption, double signatures) nicely resolve this tension: we roll out a post-quantum layer to _try_ to protect against quantum computers, while (at very low cost) keeping the existing ECC layer to reduce the damage if the post-quantum layer is broken.
Some energy numbers for breaking a post-quantum proposal, SIKEp751: https://eprint.iacr.org/2023/376 reports 11 seconds to break one key on a mass-market Intel Xeon Gold 6248R. That's a 200-watt CPU; maybe 100 watts more for MB, RAM, PS inefficiency; so about $0.0001 electricity per key.
1
Corrected numbers (tnx PLDD): https://arxiv.org/abs/2603.28846 estimates 2^19 qubits, 1/3 hour, to break an ECC key. https://arxiv.org/abs/2304.14344 estimates 6 watts/qubit. 2^20 watt-hours costs $100 in electricity + hardware-building cost. More analysis can change numbers in either direction.
https://arxiv.org/abs/2603.28846 estimates 2^29 qubits running 1/3 hour to break an ECC key. https://arxiv.org/abs/2304.14344 estimates 6 watts per qubit. 2^30 watt-hours costs about 0.1 million USD i...
Sigh, have to fix these numbers: the 29 is a stupid typo, should have been 19, and this cascaded into the watt-hour calculation. Thanks to Pierre-Luc Dallaire-Demers for the correction. Will issue revised calculation momentarily.