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

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Mon, 01 April 2019 20:09 UTC

Return-Path: <prvs=9994972d99=uri@ll.mit.edu>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8F61200CC for <cfrg@ietfa.amsl.com>; Mon, 1 Apr 2019 13:09:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04Q7fO-hGfBH for <cfrg@ietfa.amsl.com>; Mon, 1 Apr 2019 13:09:23 -0700 (PDT)
Received: from llmx3.ll.mit.edu (LLMX3.LL.MIT.EDU [129.55.12.49]) by ietfa.amsl.com (Postfix) with ESMTP id 55C3A1204CD for <cfrg@irtf.org>; Mon, 1 Apr 2019 13:09:16 -0700 (PDT)
Received: from LLE2K16-MBX01.mitll.ad.local (LLE2K16-MBX01.mitll.ad.local) by llmx3.ll.mit.edu (unknown) with ESMTP id x31K9B5R023878; Mon, 1 Apr 2019 16:09:11 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Marek Jankowski <mjankowski309@gmail.com>
CC: Paterson Kenneth <kenny.paterson@inf.ethz.ch>, "yonezawa@lepidum.co.jp" <yonezawa@lepidum.co.jp>, CFRG <cfrg@irtf.org>
Thread-Topic: [Cfrg] Fwd: I-D Action: draft-yonezawa-pairing-friendly-curves-01.txt
Thread-Index: AQHU2YhP7WSRj7kLJk6h4vQXxVMdaKYLg1EAgAA63ACABtxrAIACXiwAgAwGegCAAD6YAP//creAgADJWQCAAabZAP//zcOAgAQMtwCAAN8/AA==
Date: Mon, 01 Apr 2019 20:09:10 +0000
Message-ID: <29A51AE5-A51F-4021-B4B7-F55032620995@ll.mit.edu>
References: <155231848866.23086.9976784460361189399@ietfa.amsl.com> <737ea2b3-74e3-d02e-a44d-c44cca5db036@lepidum.co.jp> <CAEseHRrSiJ72tQepyTiL=pSBcRRLGXhnJyy_QzOubWax+v=Ntw@mail.gmail.com> <CAEseHRqh4d0VaeSaj4CWr_ZxJbbpm33ZaLF-aYGBjVowFNLFeQ@mail.gmail.com> <c57bbf7b-3177-eb64-a3c0-26842fccbb89@lepidum.co.jp> <CAEseHRrVomCo6KD7gidCRBzKJDzFZRQ+q0+PjfBr8tQT4dVpMQ@mail.gmail.com> <b016d1f6-68e4-9728-c738-ab72c593dfd1@lepidum.co.jp> <CAEseHRoLGFbf74HT9n2beryc9Liqf2Hz+_rh-yo6Q8hNqwCvNQ@mail.gmail.com> <CAMCcN7RTQU=a+SYVkGUHZ4enOhkA9j9i6ivMRDUwb+aXPZ9hBg@mail.gmail.com> <7AE82BE8-768D-4B70-B7F1-EAF6894E428E@ll.mit.edu> <9CABDAD4-AAB7-46BF-BED7-6A917F828F11@inf.ethz.ch> <27F5D9B6-A44D-4A12-B81D-C4FB01052113@ll.mit.edu> <CAMCcN7S4F9H-wr-DCHQWK1KcoRMZM6ShW5z14oUz94_ajY8FPw@mail.gmail.com>
In-Reply-To: <CAMCcN7S4F9H-wr-DCHQWK1KcoRMZM6ShW5z14oUz94_ajY8FPw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.17.0.190309
x-originating-ip: [172.25.1.85]
Content-Type: multipart/alternative; boundary="_000_29A51AE5A51F4021B4B7F55032620995llmitedu_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-01_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904010129
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/CL62RTBFgK4nyDCYdg7vNUCP044>
Subject: Re: [Cfrg] Fwd: I-D Action: draft-yonezawa-pairing-friendly-curves-01.txt
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Apr 2019 20:09:27 -0000

Marek,

Thank you for your comments. Please see inline.

From: Marek Jankowski <mjankowski309@gmail.com>


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

I think we differ in how much we do or do not know about security of post-quantum schemes. I think all of the NIST PQC submissions came with security proofs, so – no offense meant – I think the “we don’t know much about PQ …” part is a bit disingenuous. If I’m wrong here, or am missing something, or you see problems with the proofs of, e.g., SIKE  – please feel free to post here and/or let me know.

Regardless of how sure/unsure we are of the PQ schemes, we’d probably agree that we are sure that all the “classical” asymmetric crypto (factoring-based, DL-based, etc.) is completely broken with quantum computers. That means – the question is how much time we have before all the classical asymmetric is dead, and how that maps onto the required security lifetime for our data.

I agree that some data won’t need to live that long, and could be fine with “classic” protection, whatever it is. Who/how is going to ensure that only the appropriate data is protected by this mechanism?

Research, implementation, standardization, commercialization of implementation, deployment in the field all take time. It is quite possible that by the time this (or other non-quantum-resistant) approach becomes deployable technology, it gets life-time of zero or only a couple of (or a few) years. If/when, e.g., a hash-function is broken – you simply replace it with a new one as a field upgrade (and even that turned out to be a big hurdle in the field, one wonders why).  As you and Mike pointed out, there is no PQ-secure analog for BLS. Once it is broken, it will stay broken for good, until a new discovery is made. Is it a risk you’re willing to accept? If so, may I ask why?


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

As I said above, most/all of the NIST PQC submissions came with security proofs. There’s no need to resort to “non-proven PQ scheme”. Unless you’re not happy with the proofs…? In which case, please share what makes you happy with “pre-quantum” proofs and unhappy with PQ ones.

For the second part, it depends on whether the data signed today needs to stay secure in and after year x. One problem is – we do not know how soon (or far away) that year x is. But we do know that it is not a Sci-Fi any more. Quantum computers are built today, they just aren’t a direct threat yet.


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

You are probably correct here. I.e., if I authenticate to a remote Web site today with a smartcard, somebody’s ability to break my smartcard’s key several years from now is probably not very important. Except that there’s a chance that I logged in to a secure web site to fill out some sensitive form, disclosure of which even several years from now would be highly undesirable.

As you see, it may be hard to draw a line apriori between OK and Not OK.


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

There is a difference between getting an RFC and getting into practical use. But I concede your point.

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.

My concern here is that the life window of the non-quantum is shrinking, maybe shrinking rapidly (and alas, I don’t know how fast). So, with every year and every day there is less and less sense to invest time and efforts into non-quantum crypto. Are we already at the point when it already doesn’t make …? I personally think we are.

Dan Brown made a good point about hybrid approaches. Offhand, I concur with him. Perhaps we need to invest more efforts there.



On Fri, Mar 29, 2019 at 5:59 PM Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu<mailto:uri@ll.mit.edu>> 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.