I personally do not find the proposed approach appealing (or even useful). There are three possibilities.
a. Quantum computers capable of breaking crypto (QC) become practical *and*
NIST PQC winner(s) resist both quantum and classic attacks;
b. QC become practical, and NIST PQC candidates fail (doesn't matter whether
they fall to classic or quantum attack!);
c. QC do *not* materialize, *and* PQC candidates fail to classic attacks.
The only possibility justifying the hybrid exchange is (c), which I personally
find the least probable. In both (a) and (b) addition of ECC does not make the
KE any more secure than without it.
--
Regards,
Uri
There are two ways to design a system. One is to make is so simple there are
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
- C. A. R. Hoare
On 7/6/21, 21:19, "TLS on behalf of Douglas Stebila" <[email protected] on
behalf of [email protected]> wrote:
Dear TLS working group,
We wanted to see if there is any further feedback on our draft "Hybrid key
exchange in TLS 1.3"
(https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/) and what steps
are required for it to advance further. We have not received any new feedback
from the working group since we posted our last non-trivial update in October
2020.
The draft as written does not actually specify any post-quantum algorithms
nor give identifiers for specific algorithm combinations, only the formats for
hybrid key exchange messages and key derivation. We have received a suggestion
that the draft be updated to include identifiers for hybrid key exchange
combining elliptic curve groups and the KEMs currently in Round 3 of the NIST
PQC standardization process, so that implementations can begin testing
interoperability using numbers listed in the draft, rather than relying on ad
hoc lists for such purposes. Is that something the working group would like to
see, or would you prefer to leave it as it currently stands, without any
specific algorithm identifiers?
Douglas, Scott, and Shay
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
