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

141–150 of 260 posts

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

#141

Post by codethief »

tptacek wrote: post #126
codethief wrote: post #118

Earlier quoted context omitted.

If by "mainstream E2E messenger" you mean WhatsApp and Facebook Messenger, sure. But I didn't realize those were the benchmark these days.

What's the mainstream messenger you're considering that doesn't maintain serverside contact lists?

I never said I was considering any.[0] I'm strictly interested in what Signal is doing to keep (or even improve) its security guarantees.

On that note, Signal wouldn't even depend on Intel SGX for security nearly as much if Signal PINs weren't user-chosen but instead auto-generated with enough entropy. Yes, contact discovery through phone numbers would still be challenging, but secure value recovery[1] just requires a key with enough entropy.

[0]: For the record, Threema doesn't store your contact list server-side, unless you explicitly opt in. Similarly, now that Signal supports usernames, my understanding is that one could use the app without uploading one's contact list in plaintext.

[1]: https://signal.org/blog/secure-value-recovery/

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

#142

Post by tennysont »

ggm wrote: post #114

This is the first well reasoned write up which makes me walk back from my "QC is irrelevant, and RSA is fine" position a bit. Well done! Thank you for putting this into terms a skeptic can relate to and understand. It helped me re-frame my thinking on risks here.

A huge part of that, for me, was this from Scott Aaronson:

> Once you understand quantum fault-tolerance, asking “so when are you going to factor 35 with Shor’s algorithm?” becomes sort of like asking the Manhattan Project physicists in 1943, “so when are you going to produce at least a small nuclear explosion?”

That quote, alone, removed a lot of assumptions I had been carrying around.

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

#143

Post by amluto »

palata wrote: post #89
amluto wrote: post #26

Earlier quoted context omitted.

Your Yubikey itself is doomed. If you are doing a post-quantum key exchange and only authenticating with the Yubikey, then you are safe from after-the-fact attacks. Well, as long as the PQ key exchange holds up, and I am personally not as optimistic about that as I’d like to be.

> If you are doing a post-quantum key exchange and only authenticating with the Yubikey, then you are safe from after-the-fact attacks. Let me rephrase it to see if I understand correctly: so it is fine to keep using my security keys today for authentication (e.g. FIDO2?), but everything else should use PQ algorithm because the actual data transfers can be stored now and decrypted later. Meaning that today (and for a…

Sounds right to me.

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

#144

Post by FiloSottile »

cassonmars wrote: post #139
FiloSottile wrote: post #104

Earlier quoted context omitted.

Thus succeeding at making the telecommunications vendors used for Top Secret US national security data less secure, the obvious goal of the US National Security Agency, and the only reason they wouldn't use the better cryptography designed by Dr. Bernstein. /s Truly, truly can't understand why anyone finds this line of reasoning plausible. (Before anyone yells Dual_EC_DRBG, that was a NOBUS backdoor, which is an argu…

I genuinely do not understand how someone working in the capacity that you do, for things that matter universally for people, can contend that an organization who is intentionally engaging in NOBUS backdoors can be remotely trusted at all. That is insanely irresponsible and genuinely concerning. I don't care if they have a magical ring that defies all laws of physics and assuredly prevents any adversary stealing the…

The world just doesn’t work in such a binary way. Forming a mental model of an entity’s incentives, goals, capabilities, and dysfunctions will serve you much better than making two buckets for trusted parties and adversaries.

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

#145

Post by cassonmars »

FiloSottile wrote: post #144
cassonmars wrote: post #139

Earlier quoted context omitted.

I genuinely do not understand how someone working in the capacity that you do, for things that matter universally for people, can contend that an organization who is intentionally engaging in NOBUS backdoors can be remotely trusted at all. That is insanely irresponsible and genuinely concerning. I don't care if they have a magical ring that defies all laws of physics and assuredly prevents any adversary stealing the…

The world just doesn’t work in such a binary way. Forming a mental model of an entity’s incentives, goals, capabilities, and dysfunctions will serve you much better than making two buckets for trusted parties and adversaries.

As you are someone building cryptographic libraries used by people all over the world, which includes those who might be seen as "enemies" by the organization in question, this is not a gradient — it's quite binary in nature.

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

#146

Post by TacticalCoder »

bhaak wrote: post #130

> They weirdly[1] frame it around cryptocurrencies and mempools and salvaged goods or something [...] > [1] The whole paper is a bit goofy: it has a zero-knowledge proof for a quantum circuit that will certainly be rederived and improved upon before the actual hardware to run it on will exist. They seem to believe this is about responsible disclosure, so I assume this is just physicists not being experts in our field…

> Given the limited transaction throughput, migrating all vulnerable coins would take years ...

How? I just googled: about 55 million addresses with bitcoin in them, about 144 blocks per day, about 3000 to 5000 tx per block.

In something like 100 days all the coins would be moved to other addresses.

I gotta say it'd be hilarious if to speed up that migration-to-quantum-resistant-addresses process, the Bitcoin community were to finally allow bigger blocks.

EDIT: I take it if the network had to have full blocks for 100 days, then "shit would happens". Maybe they should force an orderly move: e.g. only addresses ending with "3a" are eligible to be moved in a block whose hash ends with an "3a", etc. to prevent congestion?

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

#147

Post by ekr____ »

OhMeadhbh wrote: post #95
ekr____ wrote: post #24

Earlier quoted context omitted.

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.

Reason number 10^6 why TLS 1.3 is so directive about the protocol invariants: https://www.rfc-editor.org/rfc/rfc8446#section-9.3

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

#148

Post by defrost »

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…

In truth the Chicago Pile crowd were all about power generation and didn't think it was feasible to make a nuclear bomb ..

( Not impossible, more strictly "beyond reach" economically and processing wise, operating on over estimates of the effort and approach )

They ignored letters from Albet Einstein on the topic, they ignored or otherwise disregarded several letters from the Canadian / British MAUD Committee / Tube Alloys group and it took a personal visit from an Australian for them to sit up and take note that such a thing was actually within reach .. although it'd take some man power and a few challenges along the way.

* https://en.wikipedia.org/wiki/MAUD_Committee is one place to start on all that.

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

#149

Post by krastanov »

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…

> And that state of the art has not moved much in the last decade

This is far from true. On the experimental side, gate fidelities and physical qubit numbers have increased significantly (a couple of orders of magnitude). On the theory side, error correction techniques have improved astronomically -- overhead to of error corrections has dropped by many orders of magnitude. On the error correction side progress has been feverish over the last 4 years in particular.

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

#150

Post by [deleted] »

FiloSottile wrote: post #68
adgjlsfhk1 wrote: post #60

Earlier quoted context omitted.

The absolute low end of cost of a QC is the cost of an MRI machine ~100k-400k (cost of cooling the computer to super low temps). Sure we expect QCs to get faster and cheaper over time, but putting 100% faith in the security of the PQC algorithms seems like a bad idea with no upside.

We can disagree on the tradeoff, but if you see no upside, you are missing the velocity cost of the specification work, the API design, and the implementation complexity. Plus the annoying but real social cost of all the bikeshedding and bickering.

[deleted]
Post reply on HN