SIKE was applied to large volumes of user data as part of the CECPQ2 experiment in 2019. SIKE was publicly broken in 2022.
The _only_ reason that this didn't immediately give away the user data to attackers is that CECPQ2 was ECC+SIKE, rather than just SIKE. Should we keep rolling out post-quantum cryptosystems to _try_ to stop future quantum attacks? Yes, of course. But, just in case this goes horribly wrong _again_, let's make sure to keep ECC in place. Any draft violating this should be rejected as a security risk not just by WGs but also by the ISE. SIKE is not an isolated example: https://cr.yp.to/papers.html#qrcsp shows that 48% of the 69 round-1 submissions to the NIST competition have been broken by now. David Adrian writes: > I find it to be cognitive dissonance to simultaneously argue that the > quantum threat requires immediate work, and yet we are also somehow > uncertain of if the algorithms are totally broken. Both cannot be true > at the same time. Rolling out PQ is trying to reduce the damage from an attacker having a quantum computer within the security lifetime of the user data. Doing that as ECC+PQ instead of just PQ is trying to reduce the damage in case the PQ part is broken. These actions are compatible, so how exactly do you believe they're contradictory? Here's an analogous example of basic risk mitigation: there's endless work that goes into having planes not crash, not hit turbulence, etc., but we still ask airplane passengers to keep their seatbelts on whenever they're in their seats. ---D. J. Bernstein _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
