On Fri, Apr 10, 2026 at 1:57 PM Muhammad Usama Sardar < [email protected]> wrote:
> On 10.04.26 22:48, Eric Rescorla wrote: > > > On Fri, Apr 10, 2026 at 1:42 PM Muhammad Usama Sardar < > [email protected]> wrote: > >> Hi Ekr, >> On 10.04.26 19:04, Eric Rescorla wrote >> >> 2. Contrariwise, even if there is no possibility that there will be an >> algorithmic >> compromise of the traditional algorithm it does not follow that the >> hybrid is >> more secure than pure PQ because there might be a vulnerability in the >> traditional code that leads to compromise of the endpoint. >> >> That's not correct. In hybrid, the attacker has to compromise both >> traditional as well as ML-KEM to be successful. Breaking traditional code >> only absolutely no harm. Actually it makes it equivalent to ML-KEM >> implementation. >> > It depends on what kind of compromise. If it's compromise that leads > *just* to > breaking one of the algorithms (e.g., a timing channel that leaks the key), > then you're correct. > > Thanks for confirmation. > > However, if it's a compromise of the endpoint directly > (e.g., a leak of memory contents or an RCE), then that compromise can > be used to bypass both algorithms, for instance by exfiltrating both keys > or just taking control of the endpoint directly. > > My point here is that if the endpoint is directly compromised, then pure > ML-KEM will not protect you either. So both hybrid and pure ML-KEM will be > affected. I believe the worst case of hybrid is security equivalent to > hybrid (nothing less than that). See my working of formal analysis [0]. > You seem to be assuming that the probability of compromise of the endpoint is independent of which algorithms you support, but that's not necessarily the case: each additional algorithm is new attack surface area. Imagine I invent a new algorithm A with an implementation defect which leaks server memory: an implementation with an A/X hybrid where X is *any* algorithm has a higher chance of compromise than X alone. Now, the situation is more complicated with PQ/T hybrids because existing implementations already have the traditional components, so a hybrid doesn't necessarily expose you to additional implementation risk [0], but if you imagine a future where people disable pure traditional entirely, then you might find yourself in a setting where the only way to access such an implementation is via the hybrid. -Ekr [0] Though there might be a vuln in the composition code.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
