[saag] Re: [Ext] Re: draft-paulwh-crypto-components-02
Wang Guilin <[email protected]>
| Newsgroups | gmane.ietf.saag |
|---|---|
| Message-ID | <[email protected]> |
Dear Christian and all, I do agree with your concerns, which is sometimes called cryptographic agility or diversity of algoritms. But the situation may be a little more complex. As it is not very clear when CRQC will come into reality, and also no full confidence in the security of PQ algooritms, hybrid solutions seem the main approach for PQ migration in IETF and secuirty research community. This approach is more conservative on security, but may lead some additional complexity to migration engineering. For the typical hydbrid solution of T/PQ with 1 traditional algorithm and 1 PQ algorithm, once this PQ algorithm is found with security flaws (due to algorithm design, program coding, or misuse of algorithm etc), a back up PQ algorithm should be available for being switched in the given scenario (a protocol or an application). However, such a quick switching actually does not give good protection for the data exchanged before the flaw in the PQ algorithm is found. So, an even more conservative hybrid solution is to have 1 traditional algorithm combined with 2 PQ algorithms, with a few more PQ algorithms in store as back up. So, in the case either of the 2 PQ algorithms is found insecure, a new back up PQ algorithm can come to replace. Theregore, the data exchanged before flaw is found could be protected well. Cheers, Guilin From:Christian Huitema <[email protected]<mailto:[email protected]>> To:Paul Hoffman <[email protected]<mailto:[email protected]>>;Paul Wouters <[email protected]<mailto:[email protected]>> Cc:saag <[email protected]<mailto:[email protected]>> Date:2025-02-18 03:15:20 Subject:[saag] Re: [Ext] Re: draft-paulwh-crypto-components-02 On 2/17/2025 10:12 AM, Paul Hoffman wrote: > On Feb 14, 2025, at 06:20, Paul Wouters<[email protected]> wrote: > >> The recent past (eg non-pq) shows a narrowing of algorithms to mostly be 1 NIST and 1 non-NIST algorithm. > Defining "NIST algorithm" is both time-dependent and error-prone. I prefer to think of what many WGs do is "look at what NIST has done, see if there is anything that is widely-believed to be better, and pick". X25519 and friends is an excellent example of this. I think the mention of NIST here is a bit of distraction, focusing on administrative issues instead of technology. Over time, I have seen a different concern, based on the life time of algorithm. At some unpredictable time in the future, any algorithm may become broken by some innovative attack. If all implementations implemented only that algorithm, all implementations will become vulnerable until they get updated and start supporting a different algorithm. But if implementations supported two different algorithms, they can instead immediately switch to the non-broken algorithm. We have seen that with RSA versus Elliptic curve cryptography, with 80 bit hashes versus 128 bits or 128 bits versus 256, with Elliptic curves of different groups, with AES128GCM versus ChaCha20, or with Elliptic curve cryptography versus post quantum cryptography. At any given time, the trend is to have two algorithms, one because it is fast and commonly used, the other because it is a safe alternative, unlikely to be broken at the same time as the commonly used one. -- Christian Huitema _______________________________________________ saag mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ saag mailing list -- [email protected] To unsubscribe send an email to [email protected]