Also - should we not be switching over to these algorithms starting like... now? Am I wrong that anyone collecting https traffic now will be able to break it in the future?
I do not say this lightly, having followed the academic side of QC for more than a decade.
Imagine if next year, via magic wand, all the current TLS systems were completely and totally broken such that the whole of the internet using TLS became effectively unencrypted in any way? How much damage would that do to the ecosystem? But we also just invented a new protocol that works, so how long would it take to deploy it to just 50%? or to 80%? And how long would it take to replace the long tail?
I'll also leave record now decrypt later for another commenter.
All the big important systems are again and again vulnerable to these attacks (Cisco, M$, fortinet, etc.) - but of course those aren’t “sexy” problems to research and resolve, so we get the same stuff over and over again while everyone is gushing to protect against some science fiction crypto attacks that are and have been for the last 30 years complete fantasy. It’s all a bit tiring to be honest.
Your argument is akin to,
> The problem is that a lot of physicians concentrate on diabetes, or hypertension, when there's people who have been stabed, or shot. Constantly hearing about how heart disease is a big problem is tiring to be honest.
Also, I'm not sure what circles you run in, but if you had to ask any of my security friends if they wanted to spend time on a buffer overflow, or xss injection, or upgrading crypto primitives for quantum resistance... not a single one would pick quantum resistance.
> The problem is more that people concentrate a lot of energy on hypothetical future quantum attacks when the actual threats have been the same since the 00s
Just so I can be sure... you meant having the qbits to deploy such an attack, right? Because really the only thing stopping some of the quantum computing based attacks is number of stable qbits. They're not hypothetical attacks, they've been shown to work.
I commend your friends but many people in these HN threads seem to be ready to implement post-quantum encryption right now to protect against some future threats.
> you meant having the qbits to deploy such an attack, right
Yes - last time I checked it was like 3 stable qbits. It’s just so far off from being a reality i really can’t take that research seriously. I feel like a lot of resources are wasted in this kind of research when we are still dealing with very basic problems that aren’t just as sexy to tackle.
Edit: heart disease is a real thing so your analogy is lacking - there have been 0 security risks because of quantum in the real world. It’s more like “physicians concentrating on possible alien diseases from when we colonise the universe in the future while ignoring heart disease”
There's also a good chance that the initial compromises of the classical algorithms won't be made public, at least initially. There are multiple nation-state actors working on the problem in secret, in addition to the academic and commercial entities working on it more publicly.
Various US standards require encryption algorithms to be considered safe for the next 30 years.
Sufficiently big quantum computers are likely in the next 30 years, but it's not urgent in any other meaning of the word.
The problem is, this sort of question suffers from a lot of unknown unknowns. How confident are you that we don't see crypto broken by QC in the next 10 years? The next 20? Whatever your confidence, the answer is probably "not confident enough" because the costs of that prediction being wrong are incalculable for a lot of applications.
I'd say I'm 99% confident we will not see QC break any crypto considered secure now in the next 20 years. But I'll also say that the remaining 1% is more than enough risk that I think governments and industry should be taking major steps to address that risk.
A generous CS PhD salary vs NSA 2013 estimated budget:
300,000
10,800,000,000
[1] https://en.wikipedia.org/wiki/United_States_intelligence_bud...
Signal has a post about using pre and post-quantum together: https://signal.org/blog/pqxdh/
> The essence of our protocol upgrade from X3DH to PQXDH is to compute a shared secret, data known only to the parties involved in a private communication session, using both the elliptic curve key agreement protocol X25519 and the post-quantum key encapsulation mechanism CRYSTALS-Kyber. We then combine these two shared secrets together so that any attacker must break both X25519 and CRYSTALS-Kyber to compute the same shared secret.
The pattern typically used for this is that the key for the high-speed symmetric encryption is split into multiple parts, each of which is encrypted with a separate public key system. One classical, one (or two, now?) with a post-quantum algorithm. As long as each part of the key is big enough, this still means you'd need to crack all the separate public key algorithms, but doesn't introduce any of the layering weaknesses.
But the way it was posted is so inappropriately aggressive that I think people were downvoting based on tone alone.
Not everyone who reads these HN threads is a cryptographer. It didn't raise serious red flags for me when you mentioned that. I figured it should be OK as long as you make the size of the key twice as large. Is that wrong?
It's much more conservative on your novelty budget to use a well-studied 128-bit cipher along with a well-studied key derivation function. In cryptography, you really should be as conservative as possible with your novelty budget.
In the early days of SSL there were cross-protocol information leaks if you used the same key or related keys for different protocols or protocol versions. In the DROWN attack, I can get some ciphertext from you in TLS, then feed related ciphertexts back to you in SSLv2 (an ancient version) if you're using the same key for both and have both enabled. With enough tries - a practical number of tries, not 2^64 - I can find the decryption of that ciphertext, and then I can calculate the key for the TLS session I intercepted.
Well, I can't because I'm not a leading cryptographer, but some people can.
Here's Wikipedia: https://en.wikipedia.org/wiki/Multiple_encryption
I'm no expert here, but if I understand Wikipedia correctly:
* Be sure to use distinct keys and IVs for each individual layer.
* Be aware that encrypting ciphertext could lead to a known-plaintext attack on the outer cipher, if the inner ciphertext starts in a standard way (file header etc.)
In fact it’s common practice in high security government use cases to mandate two layers built by two different vendors for defense in depth. That way a nasty bug in one doesn’t compromise anything, and the odds of a nasty exploit in both at once are quite low.
You might be thinking of bespoke combinations of algorithms at the cryptographic construction level where the programmer is trying to be clever. Being clever with crypto is dangerous unless you really know what you are doing.