← Feed

Posts

• Post #4416874

  If https://archive.cr.yp.to/2026-08-06/07:22:47/YsHY7T0pBzBPgb0dukGNgEWT5F24hHibVcr38xs7rhg/https/eprint.iacr.org/2026/1591.pdf collapses upon examination, lattice-based cryptographers will say "See, we dodged another bullet"; but aren't all the bullets more than a bit terrifying? Use the largest parameters you can afford; keep the ECC seatbelt; keep investing in alternatives.

• Post #4242218

  SHA-512 hash: 6674cf422ca5356e3a189eca7fb01cc511ee34194ae8f654e58491f4e01a480d095c2057a2316f479976155c752cc03029b9fab3d6ca18cc677403946c04f4e8

• Post #3701433

  IETF TLS WG chairs have closed the vote, and say they'll go through https://mailarchive.ietf.org/arch/browse/tls/ "to see what the consensus is". Consensus? Each side received more than 80 votes on list: e.g., 7 positive votes from DoD, 4 from Cisco, etc. (5 on each side didn't give full real names.)

• Post #3596806

  New blog post: "Bugs happen: The easy way to compare solo PQ to ECC+PQ." https://blog.cr.yp.to/20260704-bugs.html #pqcrypto #bugs #vulnerabilities #hybrids

• Post #3595268

  GCHQ's "Peter C" pushing RFC for draft-ietf-tls-mlkem: "An Internet Draft ... is not sufficient as most SDOs (including the IETF) won't allow their standards to cite I-Ds normatively." Same Peter C yelling at opponent: "While ... is standards track, draft-ietf-tls-mlkem is not."

• Post #3545811

  Wasn't someone saying a moment ago that ML-KEM is super-easy to implement correctly? How do we explain https://www.cve.org/CVERecord?id=CVE-2026-6330, then? Offhand I'd think this one isn't exploitable, but we'll see more and more ML-KEM bugs, and some of them will be severe vulnerabilities.

• Post #3536976

  @letoams@defcon.social Let me get this straight. Your argument for ignoring IETF rules and disenfranchising a bunch of people is that you claim that you heard that some person you're unable to name was misled and regrets an earlier vote? Is this like your imaginary friend telling you that solo PQ is important for "high-frequency trading"? https://archive.cr.yp.to/2026-02-21/18:04:50/g3QdEISLDFLsAFawzKSvmOCazLoSXkdd8Dy6urqOqvY/https/mailarchive.ietf.org/arch/msg/tls/YZT5IzoumhTt3C53...

• Post #3517837

  NSA pressuring U.S. defense contractors to support solo PQ: "If there is one vendor that produces one product that complies, then that is the product ... approved for use. Our interactions with vendors suggests that this won't be a problem in most cases." https://web.archive.org/web/20250613195524/https://mailarchive.ietf.org/arch/msg/spasm/xUKIoHQwm1BjNZWS2x3xb-BhsLI/

• Post #3492259

  Unhappy with NSA's SIGINT Enabling Project sabotaging cryptographic standards? This week you can take action to register an objection with IETF regarding an NSA-funded project to standardize ietf-tls-mlkem, a weakened version of ietf-tls-ecdhe-mlkem: https://nsa.2026.action.cr.yp.to/

• Post #3474807

  NSA lost IETF's February 2026 vote on this NSA-driven document. See https://blog.cr.yp.to/20260405-votes.html for tallies. Do they admit what happened? No. They call another vote and try hard to pack the room with new pro-NSA voters. But if we show up and object, all they can do is whimper.

• Post #1387837

  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

• Post #1387836

  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 deployment 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 (HN...

• Post #1387835

  "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.

• Post #1249846

  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.

• Post #1120213

  The IETF TLS chairs have now issued a "last call" for objections to non-hybrid signatures in TLS. Do they admit that their previous "last call" re non-hybrid KEMs ended up with a _majority_ in opposition, and that many opposition statements obviously also apply to signatures? No.

• Post #970821

  New blog post "NSA and IETF, part 7: Counting votes." https://blog.cr.yp.to/20260405-votes.html Turns out to be 22 votes against, 21 votes for: not even a majority in favor, never mind consensus. IETF management is throwing the votes away, insisting on a replay, and trying to silence opponents.

• Post #446800

  New blog post "NSA and IETF, part 5: One battle after another": https://blog.cr.yp.to/20260219-obaa.html Security objections successfully blocked the 2025 push for non-hybrids, but the chairs have now issued another "last call" and will treat anyone who doesn't object by 27 Feb as approving.

• Post #446799

  Another new blog post in my NSA-and-IETF series: "The structure of the debate." https://blog.cr.yp.to/20260221-structure.html This is intended to be an accessible starting point for catching up on what's going on: it's a chart tracking the claimed pros and cons of the NSA-driven proposal on the table.

• Post #363083

  https://eprint.iacr.org/2026/279 claims to chop another few bits out of the Kyber/ML-KEM security level. If the idea works then (given the attack structure) I think that it should straightforwardly combine with the larger security loss from the October paper https://eprint.iacr.org/2025/1910.