some_furry

It's not that silly of a blogpost. See: "permanent underclass", a term popular among people that believe that an Artificial General Intelligence (AGI) is imminent and desirable.

You're all over the place except where the discussion was actually taking place.

What does a work of fiction have to do with whether two distinct government entities are the same thing or not?

That's beyond moving goalposts. Just take the L, dude.

NIST does a lot of things that have nothing to do with computer security!

Would you indict NIST MEP https://www.nist.gov/mep/about-nist-mep as being an NSA project without evidence?

Didn't the FDA used to recommend pasteurizing milk?

You're argument is that I shouldn't think of NIST as a patsy for the NSA,

Incorrect. My argument is that they aren't the same entity.

The thing you said is a whole different argument. "I like waffles" "So you hate pancakes" is happening.

Incentives are basically all I consider when trying to establish true motive. But you're not required to consider motive when there's a history or pattern.

Yes you are. You need to consider both factors. Why render yourself willfully ignorant? That's not how you arrive at truth.

In the past NSA has weakened encryption standards, for example NSA madified DES standard.

They made DES more secure against differential cryptanalysis (a method that was classified at the time DES was being designed). Sure, the whole "make the keys 56-bit instead of 64-bit" is a weakening, but differential cryptanalysis would have broken the entire fucking cipher if they didn't prevent it by selecting a secure S-box.

The NSA pushed backdoored design of Dual_EC_DRBG was standardized in NIST SP 800-90A.

Correct, which another threat actor used in a backdoor by replacing the public key.

I'm not arguing that NIST isn't vulnerable to NSA influence. I'm arguing that they are not the same entity and do not have the same goals or incentives.

I'm not an NSA defender. https://furry.engineer/@soatok/116854899284071513

But if I am honest, NIST recommending it at all is enough to suspect it of being compromised.

NIST isn't the NSA and doesn't have the NSA's goals in mind. They are briefed by NSA on some matters, sure, but they're not the same organization.

NSA has a dual mission: Both SIGINT and COMINT. While the SIGINT folks might rub their hands and laugh evilly at the prospect of backdooring the PQ KEM that the Internet wants to move towards, this plot makes no sense at several levels.

The NSA has, through CNSA 2.0, committed to moving the entire federal government onto ML-KEM for top secret communications. The COMINT guys would shit themselves in rage if it turned out to be backdoored, even if there was enough hubris that the backdoor was NOBUS.

If you can't trust the people, you should always seek to understand their incentives if you want to predict their behavior.

My interpretation of the CNSA 2.0 move was that the NSA believes 1) that ML-KEM is actually the good stuff, and 2) the Suite B transition failed so spectacularly that they want to signal confidence in ML-KEM by recommending it without hybridization. Since pretty much everything they do is top secret, they probably can't comment further.

Telecoms.

I wrote at length about this debate in my blog post about threat modeling: https://soatok.blog/2026/06/30/soatoks-informal-guide-to-thr...

Let me distill this down to its most basic structure to make sure I'm understanding you.

Supoose we're trying to decide between two services for a long term group chat.

Service A, on the server-side, sees all messages, in plaintext, sent to/from all participants--including other servers. It can log it indefinitely. It sees the whole social graph. Some servers have no k-anonymity (self-hosted, single user), some have thousands of users. They're all over the world, including in jurisdictions the NSA's TAO can operate.

Service B can only see IP addresses and ciphertext. There's only one real 'server", but it has millions of users and the encryption is widely reputed by experts. Its servers happen to be hosted on American cloud providers.

By firmly disagreeing with the linked post, you are saying you prefer Service A on the matter of privacy, only because of the jurisdiction.

Is that really the hill you choose?

You mostly got it, yeah. Point 1, ECC is only also broken after Q-Day.

Hybrids obviously help if you believe Q-Day is far into the future, or never coming.

But if you take Q-Day happening as possible in our lifetime, the HNDL threat means data being encrypted today depends entirely on PQ security in the long run (since breaking EC with a Quantum Computer has an attack cost of like 2^30 or so instead of 2^120 or so).

It depends what I'm doing.

My dayjob involves a lot of code review and protocol cryptanalysis, so I agonize quite a bit there.

My blog would be less fun if I maintained the same level of rigor. If that makes any sense. ^^;

Err, where did you wrote that? I can’t find it in your last two articles.

Just now. In an HN comment.

I write in conversational English. I'm not always going to meticulously write everything like a formal argument might.

If you didn't understand that what I wrote later in a blog post was predicated on an assumption established in the intro, but would have if I wrote an explicit transitional sentence, that's useful feedback. But if you're treating an informal blog post like a court filing, you might be setting yourself up for disappointment.

Read https://soatok.blog/2026/04/13/hybrid-constructions-the-post... for a longer explanation.

The main thing I want to stress here is: I'm not anti-hybrid. Some people are. They tend to argue that less code / complexity is better, but you'll want to find one of them to ask directly.

Soatok seems unable to acknowledge that centralisation is a real (privacy, security, reliability, political, …) concern here, nor to see value in the decentralised (federated/P2P) alternative protocols implementing the same double-ratched/PFS crypto primitives.

I genuinely do not understand where this impression is coming fron. The only thing I've ever written about this topic acknowledges that centralization has risks, but a perfectly decentralized system that doesn't properly encrypt data end-to-end is bad for user privacy.

The cryptography needs to be excellent. "But decentralization" doesn't cut it.

https://soatok.blog/2025/07/09/jurisdiction-is-nearly-irrele...

Disagreeing with me is one thing, but claiming I seem "unable to acknowledge" anytbing is dishonest.

I've posted on the Signal Discourse and even had a colleague ask the Signal devs at Real World Crypto this year about this missing feature.

No dice on either approach.

Maybe it's because I'm a bad writer, but I've heard from at least a half dozen people in recent years that they think I'm too pro-Signal when my actual stance wasn't "Signal is good" but rather "all these so-called alternatives suck ass when it comes to cryptography implementations".

Signal pisses me off in a lot of ways.

If someone joins a group chat and posts horrific content, the admins cannot clean it up. This extremely basic functionality doesn't meet the most basic bar for group moderation and safety tools. This means a troll posting a high-frequency flashing GIF to a group chat full of epileptic people is going to cause real harm. This means someone joining a chat and posting unsolicited CSAM will legally imperil everyone present and the admins are powerless to intervene at all. They seem really indifferent on fixing this.

I would love for an alternative app to materialize that provided the same level of cryptographic excellence as Signal but without the enormous ego of their marketing teams or evangelists, which actually put a microgram of care into user experience and community safety. None of the alternatives people raise meet the bar, and I find it extremely disingenuous when people insist their privacy (which is a second-order property from their cryptographic implementations) is somehow "better than Signal". So when people do this, I tend to 0day their favored apps.

https://soatok.blog/encrypted-messaging-apps/

We, collectively, as an industry, should be able to do better. That we haven't is depressing.

In your PQ safety blanket article https://soatok.blog/2026/04/13/hybrid-constructions-the-post... you make it pretty clear the reason you support hybrid is tactical, not cryptographic.

What does it matter that my public arguments are tactical? Hybrid gets us to PQ faster, which makes progress on plugging up the HNDL risk.

Your wording ("Once Q-Day happens") strongly suggests Q-Day will happen, like, it’s so certain you don’t even need to state it explicitly, you can just assume it will.

The literal opening section is talking about recent changes in direction from large Internet providers about quantum computing risks.

The rest of the article is predicated on "these companies' risk assessment turns out to be correct".

Separately, in https://soatok.blog/2024/09/13/e2ee-for-the-fediverse-update... I wrote more about my actual beliefs about the likelihood of Q-Day.

It’s pretty clear from there that you think ECDH is now technically useless, and the only real justification for hybrid schemes (as opposed to pure PQ), is to reassure the people still unsure about the likes of ML-KEM. Sure you still do recommend going hybrid, but from what I can tell, you would have preferred a world where we go pure PQ right away.

You are extrapolating from the subsidiary clause of an if statement whose truth value I do not claim to know.

And so would I to be honest (if ECC is a bust): one algorithm is simpler and faster than two.

Sure.

ML-KEM is faster than X25519. The only performance downside is public key/ciphertext size. https://quantumsecuritydefence.com/quantum-news/ml-kem-vs-x2...

you made the argument that we should abandon ECC by not doing hybrid,

Where did I ever make that argument? In both TFA and my previous blog post, I've made it abundantly clear that I'm pro-hybrid.

My argument is simply:

1. The claimed benefits of ECDH hybridization evaporate immediately the moment Q-Day happens. No one disputes this.

2. Harvest Now, Decrypt Later (HNDL) is the primary threat we face today during the uncertain times where we don't know if Q-Day will ever happen.

Advocating for PQ+ECC hybrids over PQ is fine. But fear-mongering about PQ in this threat model is self-defeating: Once Q-Day happens, your only source of security is PQ anyway, so if we're going to do hybrids with today's threat model in mind, PQ+PQ is the way you really want to go (and PQ+PQ+EC if you really want EC). The blog post you're commenting on says this explicitly.

I'm not anti-hybrid. I'm anti "this is an NSA ploy" bullshit. And the IETF mailing list thread I'm mentioning is stuffed with this kind of irritating conspiracy theory rhetoric. I even link to, and quote, two examples of this.

Hi, I'm the author of this blog post!

there is also the likelihood that Q-Day never arrives, either because something we don't know prevents the construction of sufficiently large quantum computers (eg. quantum gravity)

That is possible, but given the recent 2029 timelines from large Internet providers, I think it's prudent to prepare for Q-Day even if it never arrives.

or because the entire field was a scam.

The field is like... a magnet for scams, sure. But it, itself, isn't one.

And, like, the Quantum Village at DEFCON has really failed to establish credibility in my eyes.

https://soatok.blog/2022/08/18/burning-trust-at-the-quantum-...

https://soatok.blog/2023/08/20/defcon-quantum-village-2-elec...

in that scenario abandoning ECC would have been pretty stupid.

Not really, no. See https://blog.trailofbits.com/2024/07/01/quantum-is-unimporta... for a counter-point.

Why would they use a backdoor that isn't NOBUS?

And why would they still be migrating top secret communications towards the algorithm they (NOBUS or not) have a backdoor in?

That doesn't sound very COMINT to me.

Why is it so important for this to be a standard if it is explicitly not recommended to implement at the time of standardization?

This isn't a standard.

It's not on the standards track! Words mean things!

But to answer your question: some industries need an RFC. FIPS 203 also doesn't specify how to use ML-KEM in TLS.

Think phone companies.

A NOBUS backdoor in an asymmetric primitive that looks like "X% of all keys is weak" would not explain "let's move the entire fucking federal governnent to this algorithm including implementations sourced by the private sector that don't do our secret sauxe".

Dual_EC_DRBG is the shape of backdoor that would need to apply here: even if you knew the structure of it, you would need an additional private number to attack it. Recall the Juniper vulnerability where another threat actor simply replaced the EC public key used by Juniper's Dual_EC implementation.

NOBUS without some mathematical assurance that, even should an adversary discover the same break through, they cannot decrypt the same traffic would be too risky when you consider the NSA's self interest and dual mission.

None of the NSA (or even ex-NSA) people I know have participated in this discussion at all. I imagine they're preoccupied with the current administratiom's stupid decisioms disrupting their work.

The NSA isn't DJB's oppositiom here. It's the majority of the international community of cryptography experts.

If you're reading this thread wondering why the IETF wants an informational (non-standards track), Recommended=N RFC that specifies how to use ML-KEM without ECDH, there's some important background reading.

https://mailarchive.ietf.org/arch/msg/tls/SXo4iVmp0ng_vi57ce...

https://keymaterial.net/2025/11/27/ml-kem-mythbusting/

Additionally, I wrote my own blog posts recently that toucbed on the subject.

Signatures: https://soatok.blog/2026/04/13/hybrid-constructions-the-post...

Threat modeling but also KEMs: https://soatok.blog/2026/06/30/soatoks-informal-guide-to-thr...

The main industry that's hamstrung by an RFC being blocked are telecom companies (e.g., Verizon) who by policy need an RFC and also have other regulations.

I prefer hybrid KEMs, but support publication because getting those companies onto PQ is harm reduction against Harvest Now, Decrypt Later (HNDL) attacks, and ECDH doesn't help if our confidence in the security of ML-KEM turned out to be wrong.

I recommend reading this perspective

https://mailarchive.ietf.org/arch/msg/tls/SXo4iVmp0ng_vi57ce...

Also, https://keymaterial.net/2025/11/27/ml-kem-mythbusting/

ML-KEM is not "very new" compared to the age of other algorithms historically deployed.

Correct, I didn't mean to make it sound like they were foreign to iO overall. Just that the formalisms were in the blog post.

(The iO research field, overall, is still pretty weird to me.)

A friend once explained to me that the general goal of iO is basically DRM but with an inverted power dynamic: Imagine being able to deploy containers to cloud providers (AWS, GCP, etc.), whereby the Cloud provider cannot see what software you are running. Even if the government commanded them to do so. That's how I understand it, informally.

The formalisms of "indistinguishability" in the blog posts are indeed weird.

Some security proofs argue that an attacker cannot distinguish between some plaintext and a string of NUL bytes of the same length being encrypted just by observing ciphertexts. That seems to be what Vitalik is, vaguely, gesturing towards?

(I'm not affiliated with the author or any of their numerous projects, so take my remarks with an appropriate dose of salt.)