[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]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.