Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A cryptography engineer's perspective on quantum computing timelines

words.filippo.io

Post reply on HN
Print view View original

91–100 of 260 posts

Re: A cryptography engineer's perspective on quantum computing timelines

#91

Post by OhMeadhbh »

tkhattra wrote: post #29
OhMeadhbh wrote: post #13

Earlier quoted context omitted.

Damn. It's like I insulted Vault. Also, I went over Filippo's post again and still can't see where it references the Gutmann / Neuhaus paper. Are we talking about the same post?

From Filippo's post: "Sure, papers about an abacus and a dog are funny and can make you look smart and contrarian on forums."

If only we had a technology where an author could specify a unique identifier and name of another author's paper. Something that could cite a different paper and link to it.

Re: A cryptography engineer's perspective on quantum computing timelines

#92

Post by FiloSottile »

aborsy wrote: post #51

I don’t know why the author likes AES 128 so badly. AES 256 adds little additional cost, and protects against store now decrypt later attacks (and situations like: “my opinion suddenly changed in few months”). The industry standard and general recommendation for quantum resistant symmetric encryption is using 256 bit keys, so just follow that. Every time he comes up with all sorts of arguments that AES 128 is good. A…

> The industry standard and general recommendation for quantum resistant symmetric encryption is using 256 bit keys

It simply is not. NIST and BSI specifically recommend all of AES-128, AES-196, and AES-256 in their post-quantum guidance. All of my industry peers I have discussed this with agree that AES-128 is fine for post-quantum security. It's a LinkedIn meme at best, and a harmful one at that.

My opinion changed on the timeline of CRQC. There is no timeline in which CRQC are theorized to become a threat to symmetric encryption.

Re: A cryptography engineer's perspective on quantum computing timelines

#93

Post by FiloSottile »

palata wrote: post #87
FiloSottile wrote: post #27

Earlier quoted context omitted.

This article is more aimed at those specifying and implementing WebAuthN and SSH, than at those using them. They/we need to migrate those protocols to PQ now, so that you all can start migrating to PQ keys in time, including the long tail of users that will not rotate their keys and hardware the moment the new algorithms are supported. For example, it might be too late to get anything into Debian for it to be in olds…

> This article is more aimed at those specifying and implementing WebAuthN and SSH, than at those using them. Sure, I'm just trying to understand the consequences of that. Felt great to finally have secure elements on smartphones and laptops (or Yubikeys), protecting against the OS being compromised (i.e. "you access my OS, but at least you can't steal my keys"). I was wondering if PQ meant that when it becomes reali…

If you are doing authentication with those hardware keys, you will probably be fine, if we do our job fast enough. Apple's Secure Enclave already supports some PQ signatures (although annoyingly not ML-DSA-44 apparently?) and I trust Yubico is working on it.

If you are doing encryption, then you do have reason to worry, and there aren't great options right now. For example if you are using age you should switch to hybrid software ML-KEM-768 + hardware P-256 keys as soon as they are available (https://github.com/str4d/age-plugin-yubikey/pull/215). This might be a scenario in which hybrids provide some protection, so that an attacker will need to compromise both your OS and have a CRQC. In the meantime, depending on your threat model and the longevity of your secrets (and how easily they can rotated in 1-2 years), it might make sense to switch to software PQ keys.

Re: A cryptography engineer's perspective on quantum computing timelines

#94

Post by octoberfranklin »

FiloSottile wrote: post #41
phicoh wrote: post #39

What surprises me is how non-linear this argument is. For a classical attack on, for example RSA, it is very easy to a factor an 8-bit composite. It is a bit harder to factor a 64-bit composite. For a 256-bit composite you need some tricky math, etc. And people did all of that. People didn't start out speculating that you can factor a 1024-bit composite and then one day out of the blue somebody did it. The weird thin…

See https://bas.westerbaan.name/notes/2026/04/02/factoring.html and https://scottaaronson.blog/?p=9665#comment-2029013 which are linked to in the first section of the article. > Sure, papers about an abacus and a dog are funny and can make you look smart and contrarian on forums. But that’s not the job, and those arguments betray a lack of expertise. As Scott Aaronson said: > Once you understand quantum fault-toleran…

> produce at least a small nuclear explosion

The Manhattan Project scientists actually did this before anybody broke ground at Los Alamos. It was called the Chicago Pile. And if the control rods were removed and the SCRAM disabled, it absolutely would have created a "small nuclear explosion" in the middle of a major university campus.

Given the level of hype and how long it's been going on, I think it's totally reasonable for the wider world to ask the quantum crypto-breaking people to build a Chicago Pile first.

https://en.wikipedia.org/wiki/Chicago_Pile-1

Re: A cryptography engineer's perspective on quantum computing timelines

#95

Post by OhMeadhbh »

ekr____ wrote: post #24
OhMeadhbh wrote: post #19

Earlier quoted context omitted.

So... In 2013 I was working for Mozilla adding TLS 1.1 and 1.2 support into Firefox. It turns out that some of the extensions common in 1.1, in some instances caused PDUs to grow beyond 16k (or maybe it was 32k, can't remember.). This caused middle boxes to barf. Sure, they shouldn't barf, but they did. We discovered the problem (or rather one of our users discovered the problem) by increasing the key size on server…

A few points here: There is already very wide use of PQ algorithms in the Web context [0], which is the most problematic one because clients need to be able to connect to any site and there's no real coordination between sites and clients. So we're exercising the middleboxes already. The incident you're thinking of doesn't sound familiar. None of the extensions in 1.1 really were that big, though of course certs can…

Oh hey Eric. I think I was wrong saying it was 1.1. It was a middlebox that ignored max fragment negotiation, which I think was introduced in 1.2. IIRC, the middlebox claimed to support it for 1.2 connections, but silently failed by blackholing the connection. They eventually crafted a fix, but it was an annoying year waiting for network operators to upgrade the firmware on their routers.

Re: A cryptography engineer's perspective on quantum computing timelines

#96

Post by oncallthrow »

griffzhowl wrote: post #76

noob question: can't we just use longer classical keys, at least as a stop gap?

No, and even if we could, it would require a migration of approaching the same difficulty of a migration to PQ, at which point why not just migrate to PQ

Re: A cryptography engineer's perspective on quantum computing timelines

#97

Post by nodesocket »

The first and most obvious target will be Bitcoin. It’s market cap today is $1.4T. That’s a gigantic reward for any state actor or entity with the resources and budget to break it.

Does this mean Bitcoin is going to $0? Absolutely not, it’s just going to take the community organizing and putting in the gigantic effort to make the changes. Frankly I’m not personally clear if that means all existing cold wallets need to be flashed/replaced? All existing Bitcoin miner software needs to be updated? All existing Bitcoin node software needs to be updated?

Re: A cryptography engineer's perspective on quantum computing timelines

#99

Post by palata »

FiloSottile wrote: post #93
palata wrote: post #87

Earlier quoted context omitted.

> This article is more aimed at those specifying and implementing WebAuthN and SSH, than at those using them. Sure, I'm just trying to understand the consequences of that. Felt great to finally have secure elements on smartphones and laptops (or Yubikeys), protecting against the OS being compromised (i.e. "you access my OS, but at least you can't steal my keys"). I was wondering if PQ meant that when it becomes reali…

If you are doing authentication with those hardware keys, you will probably be fine, if we do our job fast enough. Apple's Secure Enclave already supports some PQ signatures (although annoyingly not ML-DSA-44 apparently?) and I trust Yubico is working on it. If you are doing encryption, then you do have reason to worry, and there aren't great options right now. For example if you are using age you should switch to hy…

Thanks a lot, that helps!

> This might be a scenario in which hybrids provide some protection, so that an attacker will need to compromise both your OS and have a CRQC.

Did you mean "your OS and have a CRQC" here, or "your Yubikey and have a CRQC"?

Re: A cryptography engineer's perspective on quantum computing timelines

#100

Post by FiloSottile »

octoberfranklin wrote: post #94
FiloSottile wrote: post #41

Earlier quoted context omitted.

See https://bas.westerbaan.name/notes/2026/04/02/factoring.html and https://scottaaronson.blog/?p=9665#comment-2029013 which are linked to in the first section of the article. > Sure, papers about an abacus and a dog are funny and can make you look smart and contrarian on forums. But that’s not the job, and those arguments betray a lack of expertise. As Scott Aaronson said: > Once you understand quantum fault-toleran…

> produce at least a small nuclear explosion The Manhattan Project scientists actually did this before anybody broke ground at Los Alamos. It was called the Chicago Pile. And if the control rods were removed and the SCRAM disabled, it absolutely would have created a "small nuclear explosion" in the middle of a major university campus. Given the level of hype and how long it's been going on, I think it's totally reaso…

TIL about the Chicago Pile! (I don't know enough about the physics to tell if it could have indeed exploded.)

> On 2 December 1942

https://en.wikipedia.org/wiki/Chicago_Pile-1

> on July 16, 1945

https://en.wikipedia.org/wiki/Trinity_(nuclear_test)

Two years and a half. This is still a good metaphor for "once you can make a small one, the large one is not far at all."

Post reply on HN