[TLS] Re: [EXT] Re: [EXTERNAL] Re: Working Group Last Call for Post-quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

> Yes , Hybrid is weaker because it contributes little/nothing[1] to cryptographic security and increases attack surface by adding another code base. 



Not quite. Certainly, the probability of a memory corruption bug increases, and this would be an actual threat. However, we are increasingly deploying memory safe languages. And if not, I seldomly see apps where the crypto is the one and only memory bug, or even a significant part of the attack surface. 

Crypto is not the “one and only memory bug” – true. But we do not hold off from removing bugs on the grounds that there likely remain other bugs still un-remedied. 



When it comes to other kinds of attacks, a properly designed hybrid can actually be *safer* because instead of doubling the amount of wall you have to guard for your castle, you are building a second wall *behind* an existing one. 

You need to maintain not one but two “walls” and worry about “interlacing/interfacing” between them. When you know that one of those walls is dead (well, not quite yet – but “terminally ill with no hope for recovery”), and all your future safety depends on the other wall. 


On a more technical level, the primary use of a KEM in TLS is to derive a secret key, and as long as the PQ-KEM spits out anything at all during normal program flow, whatever output this is could be treated as part of the nonce, as far as security goes. So the additional attack surface is basically nonexistent. 

Additional attack surface is not in the crypto theory, but in the implementation, particularly in the integrating the two “walls”. 



> [1] The only case when Hybrid helps is when both 

> CRQC is not a threat 



This is now for any use case not requiring confidentiality for more than a few years. 

Why would the users of that use case even bother with paying the cost of exchanged messages size increasing the by the orders of magnitude? For apparently zero benefit (as we don’t expect CRQC within the next few years)? 



> **and** PQ algorithms falls to a classic attack (like SIKE). 



Google KyberSlash, which is a classic attack. 

That's how realistic this is. 

That’s not an algorithmic attack – it’s an attack against implementations that have not plugged their timing side-channel. Such attacks exist against many (all?) Classic and PQ algorithms, they can be realistic, depending on your use case, and there are known defenses against them. 



> Thus, deploying hybrid because you want to protect your date against “harvest now, decrypt later” Quantum attack is a non-starter. And that attack is the main reason people are hustling now, rather than wait for several more years. 



"Harvest now, decrypt later" plays no role in deciding between a hybrid and an all-in option. 

It does, because in the end, only the PQ part determines whether your harvested-now data will remain safe or not. 


It plays a role in whether to deploy a PQ-resistant wall. The above attacks play a role in whether or not to deploy a tried-and-tested wall which we assume may fall one day. Hence, we erect both. 

It’s much more than “may fall one day” – any algorithm “falls” into this category. It’s a practical certainty that this (Classic) wall will fall, and probably sooner rather than later.