Correct, KEM's should be replaced ASAP since they are currently vulnerable to store-now-decrypt-later attacks. Digital signature algorithms are less urgent but considering how long it takes to roll out new cryptography standards, they should be preferred for any new designs. That said, the new PQC signatures are much larger than the current 32 byte ed25519 signatures that are most common, and that could end up being very difficult to integrate into embedded systems with low bandwidth or limited memory, ie. CAN bus secure diagnostics, meshtastic nodes etc.

Sorry, can you expand on the issues with KEM?

Isn't that trivial in a sense? Encrypt with layer 1, then use that encrypted channel to send layer 2 (and so on). Not sure about the performance.

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.

You generally don't want to layer encryption like that. It apparently really does introduce new kinds of attacks, which has been observed in the real world.

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.

Running TLS over TLS is fine, or ssh over ssh, or ssh over TLS, or so on. Otherwise the bad guy would just put the TLS traffic they intercepted from you, through their own TLS tunnel and somehow acquire more information.

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.

This is a great point. If layering encryption really does introduce new attacks, that suggests encrypting single-layer ciphertext could allow you to perform that layered-ciphertext attack anyways. So I find myself skeptical of chowells' claim here.

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.)

One thing you do have to be careful about is layering hash functions, which generally does not work.

Do not! Use a combiner / KDF.

Curious why this is being downvoted.

Clearly Big Pentest wants to have work in the future.

Almost certainly because of the inappropriately aggressive tone for what would otherwise be a nice clean clarification. I just said "split" and "combine", making it possible to believe I literally meant "put half the bits in each". That's so bad of an idea that I was sure no one would think I meant that. But I can see how I wasn't clear enough. An additional clarification is good info.

But the way it was posted is so inappropriately aggressive that I think people were downvoting based on tone alone.

>That's so bad of an idea that I was sure no one would think I meant that.

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?

The problem is that no commonly-used symmetric cipher has been studied nearly as heavily with larger keys. 128 bits for a symmetric cipher is enough for all practical purposes barring a cryptographic break, and it gives the best performance. Their constructions aren't so trivial that you can just extend the existing study to larger key sizes mechanically. Using larger key sizes basically means using new ciphers. Unstudied ciphers.

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.

Thanks!

Layering independent crypto is safe, otherwise one of the layers has some nasty vulnerability. Security should not depend on the type of traffic. If it does something is wrong.

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.

Sorry if my question appears ignorant, but how quickly is quantum really coming? If your prior belief is "nothing practical is ever likely to come out of quantum computing", then so far there is nothing that would seriously suggest you to reconsider it.

I do not say this lightly, having followed the academic side of QC for more than a decade.

Given how seriously the spookie parts of the US government are taking it, I would treat it with a similar level of urgency. While we obviously aren't privy to everything they know, their public actions indicate that they don't think it's a hypothetical risk, and is something that we will need to be ready for within the next decade or so, given technology refresh cycles: they need to get these crypto algorithms in place now, for devices that will still be in production use well in to the 2030s.

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.

> Given how seriously the spookie parts of the US government are taking it, I would treat it with a similar level of urgency

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.

Well, that depends on whether or not you care about "store now, decrypt later". Will the info you're sending now be totally uninteresting in 5 years? Great, you're probably good. Do you still want it to be secret in 20 years? Implementing post-quantum cryptography might be urgent.

given how sticky crypto algorithms are, transitioning early is a really good idea. git is still stuck with SHA1, and there's plenty of triple DES hiding in the boring types of critical infrastructure that no one can update.

It's a reasonable question. The need for quantum resistant crypto isn't because the practical attack is right around the corner. All though, I do really enjoy the analogy of predicting when we'll get QC based crypto attacks, is similar to predicting when humans will land on the moon by looking at the altitude for the highest manned flight. It has more to do with the level of effort it takes to replace infra as critical as cryptography.

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.

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: unvalidated input, buffer overflow, bad auth, xss, injection etc.

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.

It's a mistake to conflate cryptography, with application logic errors.

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.

> any of my security friends if they wanted to spend time on … quantum

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”

I think one reason people want to take it seriously is that to the non-expert it just looks like a scale engineering problem, and people have proven to be shockingly good at scale engineering over the past century.

I agree with you based on my following QC that we're still pretty far away from QC attacks on current crypto.

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.

You don’t need any QC attacks if you can far easier find exploits in the same top10 vulns that were used 20 years ago… Industry should first address that very real and serious risk that is present _right now_ before thinking about QC.

It's a fallacy that multiple companies and governments need to be working on one thing at a time. We absolutely should be patching current vulnerabilities and implementing quantum-safe cryptography. There's no conflict between these goals.

The reality is that resources are constrained and there is definitely conflict between different goals - if you invest in one thing you can’t invest as much in another. For me it looks like the investment in QC is way bigger than its real life impact - which is 0. Sure it can be a niche field for some more esoteric research - but it shouldn’t be the no1 topic for security researchers. But I get that QC brings in the grant money so naturally research gravitates toward it.

The reality is that resources needed to pursue research are measured in hundreds of thousands and national security budgets are measured in billions in many countries, so your "constrained" claim is pretty much nonsense. That's not even talking about US national security budgets, which are another order of magnitude larger. The US intelligence budget in 2022 was $65.7 billion[1], and there's ample political will to fund whatever intelligence agencies such as the NSA request.

A generous CS PhD salary vs NSA 2013 estimated budget:

           300,000
    10,800,000,000

We can argue over exact allocation amounts but if you're really claiming the NSA can't spare even one researcher salary to research QC security I'm calling bullshit.

[1] https://en.wikipedia.org/wiki/United_States_intelligence_bud...

It's not clear whether NIST's recommendations are influenced by their relationship with the NSA (who would have an incentive to pressure NIST to recommend an algorithm which they--and hopefully they alone--can break). So perhaps the reasonable move is to use only one NIST-recommended algorithm and have the other layer be one that they do not recommend.

Or just ask NIST to STFU about cryptographic systems entirely, because their integrity is completely destroyed by their association with NSA.