I don't expect you to be knowledgeable about 25+ proposed algorithms. I expect you to be knowledgeable about the ballpark of the new key sizes that practically all of the candidates use. The shortest keys are in the ballpark of a few KB, and I won't go into the size of the largest ones.
You may not want to *adopt* them now - but you better be ready to support Key
Exchange for sizes far larger than what's currently implemented. And keep in
mind that while Signatures aren't a priority yet, that will come eventually.
On 2/12/20, 5:50 PM, "Stephen Farrell" <stephen.farr...@cs.tcd.ie> wrote:
Hiya,
On 12/02/2020 21:57, Martin Thomson wrote:
> Only a few of them. Some are OK, but the number is few, I agree. I
> haven't found a good summary of the second round candidates and I
> don't have time to dig into all of the candidates.
Fine reason to wait and see IMO.
I'd be much happier adopting this if we did that with
the explicit understanding that we won't produce an
RFC until the "winners" in the NIST process are known
and their properties understood. (I don't mean waiting
for a FIPS or formal NIST document but at least for
the final announcement from their process.)
If the plan were to adopt this and produce an RFC now
(e.g. to mix different curves or something) then I am
against that. There's no need for such combinations so
the real rationale here is PQC and we (at least I, but
I suspect also many IETF participants) don't know enough
about the relevant algorithms yet. (And expecting us
to be knowledgeable about 25+ algorithms isn't realistic.)
Cheers,
S.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
