Live data from Hacker News

Cloudflare targets 2029 for full post-quantum security

blog.cloudflare.com

61–70 of 120 posts

Re: Cloudflare targets 2029 for full post-quantum security

#61
The CDN part is the easy half. In my work the harder problem has most often been internal service mesh, mTLS between services, any infra that doesn’t terminate at a CDN. Has a bad habit of longer certificate lifetimes and older TLS stacks, and nobody is upgrading it for you.

Re: Cloudflare targets 2029 for full post-quantum security

#62
post #44
post #36

Earlier quoted context omitted.

People were willing to explicitly explain why it was inadequate rather than keep it secret. That is the difference.

What was to explain? It had a 56-bit key.

Was that the only thing wrong with it? The 90s was definitely before my time but I was under the impression reading about it that there were also fundamental flaws with DES which lead to the competition which ultimately produced AES.

Re: Cloudflare targets 2029 for full post-quantum security

#63
post #59
post #50

Outside of the PQ algorithms not being as thoroughly vetted as others, is there any negatives to shifting algorithms? Like even if someone were to prove that quantum computing is a dud, is there any reason why we shouldn't be using this stuff anyway?

Post-quantum algorithms tend to be slower than existing elliptic curve algorithms and require more data to be exchanged to provide equivalent security against attacks run on non-quantum computers.

Any idea how much slower? Like are we talking half the speed? A quarter? 1%?

Sorry, I'm just very out of the loop on some of this stuff and I'm trying to play a game of catchup.

Re: Cloudflare targets 2029 for full post-quantum security

#64
post #62
post #44

Earlier quoted context omitted.

What was to explain? It had a 56-bit key.

Was that the only thing wrong with it? The 90s was definitely before my time but I was under the impression reading about it that there were also fundamental flaws with DES which lead to the competition which ultimately produced AES.

Yes, that was what was wrong with DES. I mean, it also had an 8-byte block size, which turns out to be inadequate as well, but that's true of IDEA and Blowfish as well.

Re: Cloudflare targets 2029 for full post-quantum security

#65
post #60
post #35

Earlier quoted context omitted.

Which PQ algorithms would you be referring to here?

https://en.wikipedia.org/wiki/NIST_Post-Quantum_Cryptography... and search for "published attacks".

Why don't you go ahead and pick out the attacks in here that you think are relevant to this conversation? It can't be on me to do that, because obviously my subtext is that none of them are.

Re: Cloudflare targets 2029 for full post-quantum security

#66
post #51
post #33

Earlier quoted context omitted.

Among cryptography engineers there was a sharp vibe shift over the last 2 months; there are papers supporting that vibe shift, but there's also a rumor mill behind it too. The field has basically aligned fully in a way it hadn't before that this is an urgent concern. The simplest way to put it is that everyone's timeline for a real-world CRQC has shortened. Not everyone has the same timeline, but all those timelines…

> The field has basically aligned fully in a way it hadn't before that this is an urgent concern. AKA “we want more funding.”

There's a simultaneous push coming from the government to support PQC, ASAP, so it's not just researchers pushing this.

Re: Cloudflare targets 2029 for full post-quantum security

#68
post #63
post #59

Earlier quoted context omitted.

Post-quantum algorithms tend to be slower than existing elliptic curve algorithms and require more data to be exchanged to provide equivalent security against attacks run on non-quantum computers.

Any idea how much slower? Like are we talking half the speed? A quarter? 1%? Sorry, I'm just very out of the loop on some of this stuff and I'm trying to play a game of catchup.

This page lists some figures for ML-KEM-768 (which is the PQ key exchange algorithm that's most widely deployed today): https://blog.cloudflare.com/pq-2025/#ml-kem-versus-x25519 This one is actually faster than X25519 (a highly optimized ECC algorithm) by about double but requires 1,184 bytes of data to be exchanged per keyshare vs 32 for X25519. In practice everyone today is using a hybrid algorithm (where you do both ECC and PQ in case the PQ algorithm has an undiscovered weakness) so an ECC+PQ key exchange will be strictly slower than an ECC-only key exchange.

This page lists some numbers for different PQ signature algorithms: https://blog.cloudflare.com/another-look-at-pq-signatures/#t... Right now the NIST has selected three different ones (ML-DSA, SLH-DSA, and Falcon a.k.a. FN-DSA) which each have different trade-offs.

SLH-DSA is slow and requires a large amount of data for signatures, however it's considered the most secure of the algorithms (since it's based on the well-understood security properties of symmetric hash algorithms) so it was selected primarily as a "backup" in case the other two algorithms are both broken (which may be possible as they're both based on the same mathematical structure).

ML-DSA and Falcon are both fairly fast (within an order of magnitude of Ed25519, the X25519 curve signature algorithm), but both require significantly larger keys (41x/28x) and signatures (38x/10x) compared to Ed25519. Falcon has the additional constraint that achieving the listed performance in that table requires a hardware FPU that implements IEEE-754 with constant-time double-precision math. CPUs that do not have such an FPU will need to fall back to software emulation of the required floating point math (most phone, desktop, and server CPUs have such an FPU but many embedded CPUs and microcontrollers do not).

The net result is that TLS handshakes with PQ signatures and key exchange may balloon to high single- or double-digit kilobytes in size, which will be especially impactful for users on marginal connections (and may break some "middle boxes" https://blog.cloudflare.com/nist-post-quantum-surprise/#dili...).

Re: Cloudflare targets 2029 for full post-quantum security

#69
post #29

Earlier quoted context omitted.

Fair, but recently several PQ algorithms have been shown to in fact not be secure, with known attacks, so I wouldn’t equate them

Interesting. I'd like to learn more about this - where can I find info about it?

they're almost assuredly talking about two things (maybe 3 if they really know what they're talking about, but the third is something that people making this argument like to pretend doesn't exist).

1. the main "eye catching" attack was the [attack on SIDH](https://eprint.iacr.org/2022/975.pdf). it was very much a "thought to be entirely secure" to "broken in 5 minutes with a Sage (python variant) implementation" within ~1 week. Degradation from "thought to be (sub-)exp time" to "poly time". very bad.

2. the other main other "big break" was the [RAINBOW attack](https://eprint.iacr.org/2022/214.pdf). this was a big attack, but it did not break all parameter sets, e.g. it didn't suddenly reduce a problem from exp-time to poly-time. instead, it was a (large) speedup for existing attacks.

anyway, someone popular among some people in tech (the cryptographer Dan Bernstein) has been trying (successfully) to slow the PQC transition for ~10 years. His strategy throughout has been complaining that a very particular class of scheme ("structured LWE-based schemes") are suspect. He has had several complaints that have shifted throughout the years (galois automorphism structure for a while, then whatever his "spherical models" stuff was lmao). There have been no appreciable better attacks (nothing like the above) on them since then. But he still complains, saying that instead people should use

1. NTRU, a separate structured lattice scheme (that he coincidentally submitted a scheme for standardization with). Incidentally, it had [a very bad attack](https://eprint.iacr.org/2016/127) ~ 2016. Didn't kill PQC, but killed a broad class of other schemes (NTRU-based fully homomorphic encryption, at least using tensor-based multiplication)

2. McCliece, a scheme from the late 70s (that has horrendously large public keys --- people avoid it for a reason). He also submitted a version of this for standardization. It also had a [greatly improved attack recently](https://eprint.iacr.org/2024/1193).

Of course, none of those are relevant to improved attacks on the math behind ML-KEM (algebraically structured variants on ring LWE). there have been some progress on these, but not really. It's really just "shaving bits", e.g. going from 2^140 to 2^135 type things. The rainbow attack (of the first two, the "mild" one) reduced things by a factor ~2^50, which is clearly unacceptable.

Unfortunately, because adherents of Dan Bernstein will pop up, and start saying a bunch of stuff confidently that is much too annoying to refute, as they have no clue what the actual conversation is. So the conversation becomes

1. people who know things, who tend to not bother saying anything (with rare exceptions), and 2. people who parrot Dan's (very wrong at this point honestly, but they've shifted over time, so it's more of 'wrong' and 'unwilling to admit it was wrong') opinions.

the dynamic is similar to how when discussions of vaccines on the internet occur, many medical professionals may not bother engaging, so you'll get a bunch of insane anti-vax conspiracies spread.

Post reply on HN