[dangerlibrary]

I'm someone not really aware of the consequences of each quantum of progress in quantum computing. But, I know that I'm exposed to QC risks in that at some point I'll need to change every security key I've ever generated and every crypto algorithm every piece of software uses.

How much closer does this work bring us to the Quantum Crypto Apocalypse? How much time do I have left before I need to start budgeting it into my quarterly engineering plan?

[bawolff]

> But, I know that I'm exposed to QC risks in that at some point I'll need to change every security key I've ever generated and every crypto algorithm every piece of software uses.

Probably not. Unless a real sudden unexpected breakthrough happens, best practise will be to use crypto-resistant algorithms long before this becones a relavent issue.

And practically speaking its only public-key crypto that is an issue, your symmetric keys are fine (oversimplifying slightly, but practically speaking this is true)

[er4hn]

You'll need to focus on asym and DH stuff. If your symmetric keys are 256 bits you should be fine there.

The hope is that most of this should just be: Update to the latest version of openssl / openssh / golang-crypto / what have you and make sure you have the handshake settings use the latest crypto algorithms. This is all kind of far flung because there is very little consensus around how to change protocols for various human reasons.

At some point you'll need to generate new asym keys as well, which is where I think things will get interesting. HW based solutions just don't exist today and will probably take a long time due to the inevitable cycle of: companies want to meet us fed gov standards due to regulations / selling to fedgov, fedgov is taking their sweet time to standardize protocols and seem to be interested in wanting to add more certified algorithms as well, actually getting something approved for FIPS 140 (the relevant standard) takes over a year at this point just to get your paperwork processed, everyone wants to move faster. Software can move quicker in terms of development, but you have the normal tradeoffs there with keys being easier to exfiltrate and the same issue with formal certification.

[dylan604]

Maybe my tinfoil hat is a bit too tight, but every time fedgov wants a new algo certified I question how strong it is and if they've already figured out a weakness. Once bitten twice shy or something????

[griomnib]

The primary threat model is data collected today via mass surveillance that is currently unbreakable will become breakable.

There are already new “quantum-proof” security mechanisms being developed for that reason.

[bawolff]

Perhaps, but you got to ask yourself how valuable will your data be 20-30 years in the future. For some people that is a big deal maybe. For most people that is a very low risk threat. Most private data has a shelf life where it is no longer valuable.

[sroussey]

Yes, and people are recording encrypted conversations communications now for this reason.

[bdamm]

I'm not sure anyone really knows this although there is no shortage of wild speculation.

If you have keys that need to be robust for 20 years you should probably be looking into trying out some of the newly NIST approved standard algorithms.