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

[Marek Jankowski <[e-mail]>]

Dear Uri,

Please allow me to step in and share my opinion regarding developing non
quantum secure schemes.

A. As Mike says, we don't know much about current post-quantum schemes,
even against a classical attacker. Due to their theoretical complexity, it
may take dozens of years to develop considerable trust in such schemes. In
the meantime it is worthwhile to develop (classically-)strong PK schemes
with cryptographic advantages. What I mean is - until PQ schemes are made
secure, we will use classical schemes; I think the capabilities pairings
offer (e.g. IBE, short and aggregateable signatures) are appealing enough
to justify standardization.

B. > 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 agree; yet, given the choice to encrypt data using a provably
(classically-)secure scheme, and a non proven PQ scheme, I would prefer the
former: we don't know if current PQ schemes may be broken by a classical
computer before year x. Classical computers are available today to millions
of potential bad guys, while even when quantum computers are built, it
makes sense that for some time very few people will have access to one.
It is also worth mentioning that pairing based crypto offers signature
schemes with nice qualities (see the recent I-D by Boneh et al.); for
signatures it is perfectly acceptable to use quantum-vulnerable schemes
today. (But not in year x.)

C. Post quantum crypto is generally much more resource intensive than
classical crypto (including pairings), in both complexity and traffic.
Therefore pairing based cryptography works better for lightweight
processors. Data encrypted by such devices is likely to be irrelevant in
20-30 years after transmission (e.g. IoT, smart cars). So it is OK to use
classical crypto there.

D. Pairings are getting into practical use. Examples are several RFCs
(5091, 6508, 6539, 6509), Cloudflare's GeoKey Manager and more, as listed
in the I-D. The rising popularity strengthens the need for a well thought
out standard/set of standards.

To conclude, I believe that developing PQ crypto and classical PK crypto
should be done in parallel, and not one instead of the other. While using
non quantum secure chemes will threaten one's data once a quantum computer
is built, I think it should not slow down research of new crypto
capabilities.

Regards,
Marek.

On Fri, Mar 29, 2019 at 5:59 PM Blumenthal, Uri - 0553 - MITLL <
[e-mail]> wrote:

> 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.
>
>
>