Not the absence of a society, where utter lawlessness reigns. Most people's colloquial idea of anarchy is a Mad Max film.

I'm not being dismissive at all of anything except the public's misconceptions.

I think most superficial interpretations of anarchists are based on edgy LARPers rather than real political ideology.

Fun fact: Anarchy means "without rulers", not "without laws" or "without social order". There's a wide diversity of political thought under this umbrella, but the key underlying common denominator is (on some level, at least) a rejection of hierarchy (and often a rejection of capital).

Though it's fun to imagine what the philosophical and political beliefs that underpin a colloquial understanding of the word might look like, the answer is usually simply: Teenagers.

There is a meme that inspires some of this genre of title, fwiw

My blog posts are supposed to be informal and conversational, not pure logic. If you want "ratioanl arguments", look elsewhere than personal blogs.

If this fear of yours is particularly poignant, I invite you to share it with the forum so they have it in writing. It makes it easier for them to consider it as they work on a solution.

Who do you trust, then?

> i have no knowledge, nor time to eval. (and probably few people do)

If you do not have the expertise nor time to evaluate technical claims, how do you hope to arrive at correct technical conclusions?

Surely, you'd trust experts in that case? Like the experts that were involved in a multi-year international standardization effort? Like the one that produced ML-KEM and ML-DSA?

Or do you just balk at experts and "trust no one" even to your own detriment?

I wrote this in April. Many folks' misconceptions about post-quantum cryptography and "hybrid" constructions are answerable with this blog post.

Citation needed

Here's mine: https://keymaterial.net/2025/11/27/ml-kem-mythbusting/

I'm not aware if it has any real traction, but that's what I found with a quick search.

That's fair. I hold Hacker News to a higher bar of technical proficiency than a general audience. My hope with insisting on correct framing is to nudge other experts in adjacent fields to teach your more general audiences how to think about these topics more correctly so it's more approachable to the general public.

I know you mean well, but this proposal maximizes the downsides of PQ signatures.

Both ML-DSA and SLH-DSA have enormous keys. SLH-DSA is also very slow, while ML-DSA is relatively fast: https://blog.cloudflare.com/another-look-at-pq-signatures/

One of the biggest challenges with the signatures currently standardized is the signature + public key sizes. Demanding we hybridize both just maximizes the pain, and there's no real incentive for this.

As I wrote in https://soatok.blog/2026/04/13/hybrid-constructions-the-post..., the justification for composite/hybrid signatures just isn't there.

Use ML-DSA-44. Don't combine it with other crap. It's good enough.

For KEMs, X-Wing (mlkem768x25519) is great, but ML-KEM-768 and ML-KEM-1024 are also fine on their own. Hybrids are the path of least resistance here, so I prefer them, but have no concerns over ML-KEM's security.

  # You kind of have to define this since most libraries don't have it
  def classic_kem(pk):
    [eph_sk, eph_pk] = classic_keygen()
    d = classic_shared_secret(eph_sk, pk)
    return hash(d + eph_pk + pk), eph_pk
  
  # Two pieces ...
  [ss1, ct1] = classic_kem(pk1)
  [ss2, ct2] = postquantum_kem(pk2)
  
  # ... combine into one:
  # note: for some KEMs, ct1 and/or ct2 can safely be omitted
  shared_secret = hash(ss1 + ss2 + ct1 + ct2)
  
  ciphertext = symmetric_encrypt(plaintext, shared_secret, context)
  send_to_other_party(
    ct1,
    ct2,
    ciphertext
  )

On the opposite side, their code looks like this:

  # I'm ignoring implicit vs explicit rejection for simplicity
  def classic_kem_decaps(ct, sk, pk):
    d = classic_shared_secret(ct, sk)
    return hash(d + ct + pk)

  ss1 = classic_kem_decaps(ct1, sk1, pk1)
  ss2 = postquantum_kem_decaps(ct2, sk2, pk2)
  shared_secret = hash(ss1, ss2, ct1, ct2)

  # raises an exception on decrypt failure (e.g., invalid auth tag)  
  plaintext = symmetric_decrypt(ciphertext, shared_secret, context)

"Encrypt" means something specific, not just the vague use of cryptography.

No, I'm saying that "hybrid KEM" or "chaining two KEMs" is very distinct from "encrypt twice". Confuse the two at your own peril.

> To the extent we know what KEM is, we think it is just encrypting the key used for the rest of the bulk encryption.

Encryption is reversible. If you have the key, you can decrypt. It's not encryption if you can't decrypt.

KEMs are their own class of algorithms. They combine an asymmetric encryption scheme with an all-or-nothing one-way transform (usually a key derivation function built on hash functions). It's the safest way to hold asymmetric encryption in practice (even not considering PQ; RSA-KEM beats RSA-OAEP in implementation safety).

Calling KEMs "encryption" is misleading to the point of malpractice. I will push back on conflating the two.

> Whether or not people understand the nuance of encrypting the block cipher keys or encrypting the blocks themselves, I think we all mean to stack the two encryption methods for defense-in-depth protection.

Your only defense-in-depth should be in delivering a strong pseudorandom ephemeral key over an untrusted network, and then using the tried-and-true AEAD constructions that we're already using today. Encrypt once. Do whatever you need to do to get the key exchanged securely.

I write a blog that very regularly covers applied cryptography. I deal with newbie confusion all the time. It's very important that we talk about these things correctly on forums like Hacker News comment threads so that the people learning from us won't get more confused.

Please don't call KEMs "encryption".

> This is a problem that I have met so many times talking with people: they parrot the "Harvest-Now-Decrypt-Later is the only urgent problem, signatures can wait" mantra, and this piece of misinformation has spread so much that even AI repeats it (because it has been trained on open data, where the overwhelming sentiment has been following this trend), thereby reinforcing the problem. Ask Claude/ChatGPT/Gemini about the problem, and they will invariably tell you that signatures are less urgent because theyr are not subjective to retroactive compromise.

I can't speak to public sentiment, but the stance I've held for years was roughly:

HNDL is more urgent because people are already encrypting messages today that could be decrypted in the future if a quantum computer is ever built in the foreseeable future, and that harms their privacy for the entirety of human history until PQC is rolled out.

That's not the same as "authentication doesn't matter at all". It was, if you must pick a problem to solve today, this one will stop the bleeding sooner.

But they were always both important to solve. The question was whether we could delay PQ auth until better signature algorithms were deployed. The Google/Cloudflare 2029 decision signaled to the rest of us: "No, we need to start the migration now."

The thing a cryptography-relevant quantum computer does is break RSA and elliptic curve cryptography, so that the underlying key (k1 or k2) is recoverable from its corresponding public component.

Hybrid KEMs, such as mlkem768x25519 (a.k.a. X-Wing) is a simple abstraction with security proofs that does both classical (X25519 is elliptic curve) and post-quantum (ML-KEM-768 is lattice-based) cryptography and combines them securely into a single key agreement.

"Encrypt twice" is bad advice. Even if you get the same approximate security, you're giving up a lot of performance.

Encrypt once, but encrypt with a key you can be confident in the secrecy of.

  c1 = E1(p, k1)
  c2 = E2(p, k2)

What you do instead is to use multiple KEMs and combine them securely (see the blog post I linked) in such a way that the confidentiality of your shared secret (i.e., the key you actually use for encryption) is preserved if any of the underlying KEMs is unbroken.

  ss1, ct1 = KEM1(pk1)
  ss2, ct2 = KEM2(pk2)
  secret = Combiner(ss1, ss2, [ct1, [ct2]])

This is very different than merely "encrypt your data twice". You only encrypt your data once. The KEY YOU ENCRYPT WITH is, instead, the result of multiple asymmetric operations.

I cannot stress enough how different these proposition are. It's like suggesting someone swim downstream in electric current. The words might make logical sense to a non-expert, but it's utterly unsafe taken literally.

There were 5 levels being considered for each submission.

Level 1 - at least as difficult to attack as AES-128 (block cipher)

Level 2 - at least as difficult to attack as SHA-256 (hash function)

Level 3 - at least as difficult to attack as AES-192 (block cipher)

Level 4 - at least as difficult to attack as SHA-384 (hash function)

Level 5 - at least as difficult to attack as AES-256 (block cipher)

The security of attacking an N-bit block cipher is morally congruent to a birthday collision against a {2N}-bit hash function. With some caveats: https://soatok.blog/2024/07/01/blowing-out-the-candles-on-th...

ML-DSA-44 (smallest parameter set) targets Level 2 for signatures.

ML-KEM-768 targets Level 3 for KEMs.