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

151–160 of 260 posts

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

#151

Post by rogerrogerr »

tennysont wrote: post #142
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.

Can anyone give the next layer of detail here? I understand the implications of this analogy, but looking for the underlying reasons the analogy is apt.

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

#152

Post by tptacek »

lucb1e wrote: post #138
tptacek wrote: post #86

Earlier quoted context omitted.

Because you cannot "just literally replace those 3 characters and be done with the upgrade".

That would depend... There's a whole lot of cases where the tokens are temporary in nature with an easy cut-over, either dropping old entries or re-encrypting while people are not at work. We tend to think of big commerce like amazon or google that need 24/7 uptime, but most individual systems are not of that scale In most other cases you increment the version number for the new data format and copy-paste the (d)e(n)…

The moment you say "lot of cases", multiply the cost by $100,000,000.

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

#154

Post by kevvok »

OhMeadhbh wrote: post #19
OsrsNeedsf2P wrote: post #8

Why do we "need to ship"? 1,000 qubit quantum computers are still decades away at this point

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…

This issue is already being tracked by a shiny website: https://tldr.fail/

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

#155

Post by olalonde »

nullc wrote: post #85
sunshine-o wrote: post #49

Earlier quoted context omitted.

Yep, I was looking into it and from what I understand: - There is a dark outlook on Bitcoin as the community and devs can't seem to coordinate. Especially on what to do with the "Satoshi coins" - Ethereum has a hard but clear path (pretty much full rewrite) with a roadmap [0] - The highly optimized "fast chains" (Solana & co) are in a lot of trouble too. It would be funny if Bitcoin the asset end up migrating to Ethe…

Adding new signature schemes to bitcoin is relatively trivial and has been done previously (today Bitcoin supports both schnorr and ecdsa signatures). Existing PQ standards have signatures with the wrong efficiency tradeoffs for usage in Bitcoin-- large signatures that are durable against a lot of use and supports fast signing, while for Bitcoin signature+key size is critical, keys should be close to single use, and…

> proposals to confiscate the assets of people not adopting the proponent's scheme (which immediately raises concerns about backdoors and consent)

They're going to lose those assets regardless, either to the first hacker with a QC or via a protocol-level burn. The latter is arguably better for the network's long-term health, as it reduces circulating supply rather than subsidizing an attacker.

I can understand disagreeing about timelines but is there a flaw in the logic that once the underlying crypto is broken, "consent" is a moot point?

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

#156

Post by ArguMisrepre »

nullc wrote: post #85
sunshine-o wrote: post #49

Earlier quoted context omitted.

Yep, I was looking into it and from what I understand: - There is a dark outlook on Bitcoin as the community and devs can't seem to coordinate. Especially on what to do with the "Satoshi coins" - Ethereum has a hard but clear path (pretty much full rewrite) with a roadmap [0] - The highly optimized "fast chains" (Solana & co) are in a lot of trouble too. It would be funny if Bitcoin the asset end up migrating to Ethe…

Adding new signature schemes to bitcoin is relatively trivial and has been done previously (today Bitcoin supports both schnorr and ecdsa signatures). Existing PQ standards have signatures with the wrong efficiency tradeoffs for usage in Bitcoin-- large signatures that are durable against a lot of use and supports fast signing, while for Bitcoin signature+key size is critical, keys should be close to single use, and…

[dead]

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

#157

Post by tptacek »

cyberax wrote: post #137
FiloSottile wrote: post #73

Earlier quoted context omitted.

> from a classical security point of view PQC cannot be trusted [citation needed] https://words.filippo.io/crqc-timeline/#fn:lattices

It's purely a matter of _potential_ issues. The research on lattice-based crypto is still young compared to EC/RSA. Side channels, hardware bugs, unexpected research breakthroughs all can happen. And there are no downsides to adding regular classical encryption. The resulting secret will be at least as secure as the _most_ secure algorithm. The overhead of additional signatures and keys is also not that large compare…

No it's not. This is the wrong argument. It's telling how many people trying to make a big stink out of non-hybrid PQC don't even get what the real argument is.

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

#158

Post by Tyyps »

I think people have to be extremely careful with this kind of opinion. In particular seeing such a push for post-quantum crypto while the current state of the art for quantum factorisation is 15 and 21 and the fact that current assumptions (for KEM in particular) are clearly not as studied as dlog.

It's maybe good to remember that SIDH was broken in polynomial time by a classical computer 3 years ago... I'm really concerned by the current rush for PQ solutions and what are the real intentions behind it. On a side note there might even be a world where a powerfully enough quantum computer that break 2048 bigs RSA will never exists (Hooft, Palmer... Recent quantum gravity theory).

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

#159

Post by Tyyps »

adgjlsfhk1 wrote: post #44
tux3 wrote: post #5

This is a good take, there's really not much to argue about. >[...] the availability of HPKE hybrid recipients, which blocked on the CFRG, which took almost two years to select a stable label string for X-Wing (January 2024) with ML-KEM (August 2024), despite making precisely no changes to the designs. The IETF should have an internal post-mortem on this, but I doubt we’ll see one My kingdom for a standards body that…

I think the anti-hybrid argument the article makes is clearly wrong. Even if CRQCs existed today, we still should be using hybrid algorithms because even once CRQCs exist, they will be slow, expensive, and power hungry for at least a decade. The hybrid algorithms at a minimum make the cost of any attack ~$1M, which is way better than half of the PQC algorithms that made it to the 3rd stage of the PQC competition (2 o…

Indeed anti-hybrids arguments are very dangerous takes at best. People are putting a tremendous amount of faith in very understudied assumptions, in particular given the complexity of geometric relations and the structure of current lattice based scheme.

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

#160

Post by adgjlsfhk1 »

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.

All of those are costs are at least as high for non-hybrid. The spec and API are just as easy to design (because we have really good and simple ECC libraries), and the bikeshedding and bickering will be a lot less if people stop trying to force pure PQC algorithms that lots of people see as incredibly risky for incredibly little benefit.
Post reply on HN