> 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. 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. 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. > [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. Obvious examples include the transmission of credentials like OAuth access tokens for accessing administrative APIs. Less obvious examples include any message whose sensitivity decreases with time. This to some extend includes chat messages, regardless of whether or not they ever become worthless (which they do often not). > **and** PQ algorithms falls to a classic attack (like SIKE). Google KyberSlash, which is a classic attack. That's how realistic this is. > 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 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
