Re: [Cfrg] Fwd: I-D Action: draft-yonezawa-pairing-friendly-curves-01.txt

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

It doesn’t but we did already discuss that, and good arguments were put forth for continuing the work despite this. (See the mail archive, I guess.)

So far I’ve found this (which IMHO doesn't look like a set of good arguments):

>  1) Pairing-based crypto threw open the doors to lots of nice new crypto possibilities, enabling stuff that we couldn't do before
>  2) Gradually post-quantum crypto is catching up and demonstrating capabilities that mirror some (but not all) of these achievements
>  3) Post-quantum crypto depends on hard problems that it will take time to develop full confidence in, even in regard to attacks from non-quantum computers
>  4) In the meantime (and that could be quite a long time) it makes perfect sense to proceed with the development and standardization
>       of non-quantum safe methods.
>  5) In the year x out pops a quantum computer. However in the year x-1 out popped well-developed and well-understood
>       post-quantum crypto replacements in which we can have complete confidence. 

Re. (1): sure, it would do great stuff, but for how long? What’s the expected lifetime of an algorithm/protocol/approach that would justify efforts spent on formalizing, implementing, and deploying it? What application field or use case would support it?

Re. (2) and (3): sure, but irrelevant with regard to the main question - is it worth developing (for deploying later, as there's an inevitable lag) non-quantum-resistant crypto now?

Re. (4): I see no logic in that statement. We don't have full confidence in post-quantum hard problems, therefore we should standardize methods that we know are not quantum-resistant?

Re. (5): It's only true for data that loses value rapidly. It may work for, e.g., throw-away TLS sessions, but not for, e.g., sensitive email. It seems to ignore the fact that data produced in year x-k (encrypted by good and intercepted by bad players) may still have value in year x, x+1, etc.

I cannot (nor do I want to) tell people what to research or experiment with, and what not to. But common sense suggests that systems/algorithms that do not offer long-term protection won't see large-scale commercial deployment, IRTF draft or not.