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

81–90 of 260 posts

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

#81

Post by lucb1e »

cwmma wrote: post #57
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…

he pretty explicitly states that AES 128 is not in any imminent danger and mandating a switch to 256 would distract from the actual thing he thinks needs to happen.

So why argue about whether AES-256 is worth it if we can just literally replace those 3 characters and be done with the upgrade? This was the smart move already in 2001 when Shor's algorithm was known and computers fast enough that we don't notice the difference. At least to me, it seems like less bikeshedding will be done if we abandon AES-128 and don't have to deal with all the people left wondering if that's truly ok

Then again, something something md5. 'Just replace those bytes with sha256()' is apparently also hard. But it's a lot easier than digging into different scenarios under which md5 might still be fine and accepting that use-case, even if only for new deployments

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

#82

Post by ls612 »

amluto wrote: post #26
palata wrote: post #23

What is the consequence on e.g. Yubikeys (or say the Android Keystore)? Do I understand correctly that those count as "signature algorithms" and are a little less at risk than "full TEEs" because there is no "store now, decrypt later" for authentication? E.g. can I use my Yubikey with FIDO2 for SSH together with a PQ encryption, such that I am safe from "store now, decrypt later", but can still use my Yubikey (or And…

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.

Is this also true for other TPM/snitching/DRM chips out there? IE will every existing device eventually become jailbreakable in the future or will we unfortunately not even get that benefit from all this?

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

#84

Post by hujun »

amluto wrote: post #22

I was in this field a while back, and I always found it baffling that anyone ever believed in the earlier large estimates for the size of a quantum computer needed to run Shor's algorithm. For a working quantum computer, Shor's algorithm is about as difficult as modular exponentiation or elliptic curve scalar multiplication: if it can compute or verify signatures or encrypt or decrypt, then it can compute discrete lo…

> Trusted Execution Environments (TEEs) like Intel SGX and AMD SEV-SNP and in general hardware attestation are just f*d. All their keys and roots are not PQ and I heard of no progress in rolling out PQ ones, which at hardware speeds means we are forced to accept they might not make it, and can’t be relied upon.

compare to SGX, a more critical impacted component is TPM chip, secured/measured boot depends on TPM, and cost of replacing all servers and OS ...

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

#85

Post by nullc »

sunshine-o wrote: post #49
Animats wrote: post #36

We'll know it's been cracked when all the lost Bitcoins start to move.

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 signing time is irrelevant.

To the extent that I've seen any opposition related to this isn't only been in related to schemes that were to inefficient or related to proposals to confiscate the assets of people not adopting the proponent's scheme (which immediately raises concerns about backdoors and consent).

There is active development for PQ signature standards tailored to Bitcoin's needs, e.g. https://delvingbitcoin.org/t/shrimps-2-5-kb-post-quantum-sig... and I think progress looks pretty reasonable.

Claims that there is no development are as far as I can tell are just backscatter from a massive fraud scheme that is ongoing (actually, at least two distinct cons with an almost identical script). There are criminal fraudsters out seeking investments in a scheme to raise money to build a quantum computer and steal Bitcoins. One of them reportedly has raised funds approaching a substantial fraction of a billion dollars from victims. For every one sucker they convince to give them money, they probably create 99 others people panicked about it (since believing it'll work is a pre-req to handing over your money).

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

#86

Post by tptacek »

lucb1e wrote: post #81
cwmma wrote: post #57

Earlier quoted context omitted.

he pretty explicitly states that AES 128 is not in any imminent danger and mandating a switch to 256 would distract from the actual thing he thinks needs to happen.

So why argue about whether AES-256 is worth it if we can just literally replace those 3 characters and be done with the upgrade? This was the smart move already in 2001 when Shor's algorithm was known and computers fast enough that we don't notice the difference. At least to me, it seems like less bikeshedding will be done if we abandon AES-128 and don't have to deal with all the people left wondering if that's truly…

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

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

#87

Post by palata »

FiloSottile wrote: post #27
palata wrote: post #23

What is the consequence on e.g. Yubikeys (or say the Android Keystore)? Do I understand correctly that those count as "signature algorithms" and are a little less at risk than "full TEEs" because there is no "store now, decrypt later" for authentication? E.g. can I use my Yubikey with FIDO2 for SSH together with a PQ encryption, such that I am safe from "store now, decrypt later", but can still use my Yubikey (or And…

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 reality, we just get back to a world where if our OS is compromised, then our keys get compromised, too. Or if there is a middle ground in the threat model, e.g. "it's okay to keep using your Yubikey, because an attacker would need to have physical access to your key, specialised hardware AND access to a quantum computer in order to break it". Versus "you can stop bothering about security keys because with "store now, decrypt later", everything you do today with your security keys will anyway get broken with quantum computers eventually".

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

#88

Post by adgjlsfhk1 »

griffzhowl wrote: post #76

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

They're a pretty bad stopgap: https://bas.westerbaan.name/notes/2026/04/02/factoring.html. Going to RSA-32000 only buys you ~a year once QCs can factor RSA-2048. In order to get a standard that would resist quantum attacks for realistic time, we would need MB to GB keys at least (see https://eprint.iacr.org/2017/351.pdf for a hilarious post-quantum RSA attempt that used terabyte size keys)

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

#89

Post by palata »

amluto wrote: post #26
palata wrote: post #23

What is the consequence on e.g. Yubikeys (or say the Android Keystore)? Do I understand correctly that those count as "signature algorithms" and are a little less at risk than "full TEEs" because there is no "store now, decrypt later" for authentication? E.g. can I use my Yubikey with FIDO2 for SSH together with a PQ encryption, such that I am safe from "store now, decrypt later", but can still use my Yubikey (or And…

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 few years), my Yubikey still protects me from my key being stolen when my OS is compromised.

Correct?

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

#90

Post by sunshine-o »

PretzelPirate wrote: post #75
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…

> pretty much full rewrite This is far from my understanding. Changing out this signature scheme is hard work, but doesn't require a rewrite of the VM.

Ethereum is way more complex than let's say Bitcoin and all parts are affected. This is not just the "signature scheme".

The fact that the signature size is multiplied by ~10 will greatly affect things like blockspace (what I guess is even more a problem with Bitcoin !)

Also they are the only blockchain I believe that put an emphasis on allowing large number of validators to run on very modest hardware (in the ballpark of a RPI, N100 or phone).

My understanding is they will need to pack it with a larger upgrade to solve all those problems, the so called zkVM/leanVM roadmap.

And then there are the L2 that are an integral part of the ecosystem.

So this is the greatest upgrade ever made on Ethereum, pretty much full rewrite, larger than the transition to proof of stake. I remember before the Proof of Stake migration they were planning to redo the EVM too (with something WASM based at the time) but they had to abandon their plan. Now it seems there is no choice but to do it.

Post reply on HN