← Feed

Posts

• View post

  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.

• View post

  SHA-512 hash: 6674cf422ca5356e3a189eca7fb01cc511ee34194ae8f654e58491f4e01a480d095c2057a2316f479976155c752cc03029b9fab3d6ca18cc677403946c04f4e8

• View post

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

• View post

  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

• View post

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

• View post

  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.

• View post

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

• View post

  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/

• View post

  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/

• View post

  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.

• View post

  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

• View post

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

• View post

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

• View post

  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.

• View post

  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.

• View post

  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.

• View post

  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.

• View post

  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.