IETF Logo Mail Archive

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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Mon, 15 April 2019 03:36 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
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 E3DD1120334 for <cfrg@ietfa.amsl.com>; Sun, 14 Apr 2019 20:36:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz
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 ILJ2KX0gWDfp for <cfrg@ietfa.amsl.com>; Sun, 14 Apr 2019 20:36:49 -0700 (PDT)
Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EC4C120044 for <cfrg@irtf.org>; Sun, 14 Apr 2019 20:36:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1555299409; x=1586835409; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=K0PAaODNLGUZjwiL2aDW08EDmtUYS1qiH+gCF40eOTs=; b=CVPoB+JFWQT1WTwF6lnQz8OiHN2nviKkvNYgPgtJIBPJPausYvGCsxLn zKX0V02fXcj6HlZBktkPyfPHnLuwkMeQLY5YX7kad3w16BXKyd+4St+J0 rUv496ZQx5bcO5/JpqF/c0GMoNoBDcDmCgWlQwk5fxCMW8bnkcGAYrW2n qP7+7NFaGTcage7xXb0QzVWRjpqtea/tR1Ee1aT7K2JlohXYk4TgZZPXW 9Rp4VDkdfKuVfbarBUBaHOzyqDiGEBLp17xi9U+GyVhPm/tP+f5QZ/Gt/ MsagpaM0vGqUqeqxvkdtFF4pg/h/coN72pQy6F36kMQS1SuTrYj0yN6DV g==;
X-IronPort-AV: E=Sophos;i="5.60,352,1549882800"; d="scan'208";a="56594292"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.3.5 - Outgoing - Outgoing
Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-d.UoA.auckland.ac.nz) ([10.6.3.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 15 Apr 2019 15:36:44 +1200
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 15 Apr 2019 15:36:44 +1200
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Mon, 15 Apr 2019 15:36:44 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Björn Haase <bjoern.haase@endress.com>, "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
CC: CFRG <cfrg@irtf.org>
Thread-Topic: [Cfrg] Fwd: I-D Action: draft-yonezawa-pairing-friendly-curves-01.txt
Thread-Index: AQHU2YhHElp7qJVa306c7sp7VaiA0aYKZlUAgAA63ACABtxrAIACXiwAgAwGegCAAD6YAP//creAgAEMZwCAAWPLAIAAENIAgATQZgCAAARKgIAAL2WAgAEVMb///15bAIACF2QAgBMhxu8=
Date: Mon, 15 Apr 2019 03:36:43 +0000
Message-ID: <1555299362578.89262@cs.auckland.ac.nz>
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> <810C31990B57ED40B2062BA10D43FBF501DB4A31@XMB116CNC.rim.net> <B79CBA86-3C81-4973-84C2-7DAD7B659CB4@ericsson.com> <CADPMZDCHgsP6=ssJymeoq7RP1eshWf4zk+N9Cf1DY-fk+ntCgA@mail.gmail.com> <1554167337418.62603@cs.auckland.ac.nz> <1A5915E5-E50A-426E-B8F5-6CCCA47AB392@ll.mit.edu>, <DB8PR05MB599359EAB383B467DBE6DDB283570@DB8PR05MB5993.eurprd05.prod.outlook.com>
In-Reply-To: <DB8PR05MB599359EAB383B467DBE6DDB283570@DB8PR05MB5993.eurprd05.prod.outlook.com>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/-fiI6QAYAz9Y2FJo4Gx1yQxHIyQ>
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, 15 Apr 2019 03:36:52 -0000

Björn Haase <bjoern.haase@endress.com> writes:

>Saying this, I think that it is important to have researchers working on PQ-
>Crypto such that we have a solution "in the box", even if the actual
>probability that we'd actually need it might be small.

If it was researchers publishing via standard academic venues that'd be fine,
the problem is that the CFRG is a de facto standards body so anything
published will become an Internet standard.  At that point the yet-to-be-
given-a-cool-name rule [0] which says that the best crypto is the latest
trendiest bleeding-edge stuff and not the long-established stuff that we have
a lot of experience with will kick in, and whatever PQC is written up will
start being deployed and rushed into production before the RFC is even
published.

The end result will be the worst of both worlds, we'll have a bunch of PQC
algorithms that work nothing like existing stuff so that people will be able
revisit thirty years of mistakes in applying it, alongside the existing crypto
that also needs to be supported.

So standardising PQC at this point is hugely premature.  Leave it for academic
conferences from which it can be pulled as required, but don't give
implementers an excuse to re-make all the mistakes that have been made in the
past with an entirely new set of algorithms.

Peter.

[0] Suggestions for a name welcome, currently "The Hipster Crypto Rule" but
    I'm not too happy with that.

v2.23.0 | Report a Bug | By Email