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

Damien Miller <djm@mindrot.org> Thu, 04 April 2019 00:25 UTC

Return-Path: <djm@mindrot.org>
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 ADA591201AF for <cfrg@ietfa.amsl.com>; Wed, 3 Apr 2019 17:25:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 UxGLkkZm7gMc for <cfrg@ietfa.amsl.com>; Wed, 3 Apr 2019 17:25:30 -0700 (PDT)
Received: from newmailhub.uq.edu.au (mailhub2.soe.uq.edu.au [130.102.132.209]) (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 D8934120193 for <cfrg@irtf.org>; Wed, 3 Apr 2019 17:25:27 -0700 (PDT)
Received: from smtp2.soe.uq.edu.au (smtp2.soe.uq.edu.au [10.138.113.41]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id x340PKTx004837; Thu, 4 Apr 2019 10:25:20 +1000
Received: from mailhub.eait.uq.edu.au (holly.eait.uq.edu.au [130.102.79.58]) by smtp2.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id x340PKSt024045 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 4 Apr 2019 10:25:20 +1000
Received: from haru.mindrot.org (haru.mindrot.org [130.102.96.5]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTP id x340PJEi014866; Thu, 4 Apr 2019 10:25:19 +1000 (AEST)
Received: from localhost (localhost [127.0.0.1]) by haru.mindrot.org (OpenSMTPD) with ESMTP id 39d8d7b5; Thu, 4 Apr 2019 11:25:19 +1100 (AEDT)
Date: Thu, 04 Apr 2019 11:25:19 +1100
From: Damien Miller <djm@mindrot.org>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
cc: Björn Haase <bjoern.m.haase@web.de>, "cfrg@irtf.org" <cfrg@irtf.org>
In-Reply-To: <1554249372811.54517@cs.auckland.ac.nz>
Message-ID: <alpine.BSO.2.21.1904041123080.97827@haru.mindrot.org>
References: <155231848866.23086.9976784460361189399@ietfa.amsl.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> <1554185903715.11087@cs.auckland.ac.nz> <86950110-c278-31d2-ae3e-a2485d0243ed@web.de> <1554249372811.54517@cs.auckland.ac.nz>
User-Agent: Alpine 2.21 (BSO 202 2017-01-01)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="5996640300817186816-1585731023-1554337519=:97827"
X-Reference: <CAMCcN7RTQU=a+SYVkGUHZ4enOhkA9j9i6ivMRDUwb+aXPZ9hBg@mail.gmail.com>
X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub
X-Scanned-By: MIMEDefang 2.75 on 130.102.79.58
X-UQ-FilterTime: 1554337521
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/IhMrYKHo7ZZtSrTdgZZHx4E_9jA>
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: Thu, 04 Apr 2019 00:25:33 -0000

On Tue, 2 Apr 2019, Peter Gutmann wrote:

> Björn Haase <bjoern.m.haase@web.de> writes:
> 
> >We know that the cost of conventional attacks is low and many applications
> >are actually "worth" the effort of an attack.
> 
> Another thing about PQC is that all of this is entirely new crypto that we
> have no experience in using.  We've had decades of experience with using
> PreQC, and have mostly managed to get it right (a lot of the attacks being
> performed were known about years ago but were ignored until someone published
> an attack paper with accompanying tools and newsworthy name, and even then
> there's a huge amount of code in PreQC crypto designed specifically to prevent
> entire classes of attacks), while we have zero experience with using PQC.
> Which means we're going to see years if not decades of new attacks, or the
> same old attacks that were fixed in PreQC implementations, popping up with
> PQC.  It's quite possible that PQC will make us a lot *less* secure, if QC
> never really happens but the expected vulnerabilities in using PQC do.

If anything this prediction (with which I agree) heightens the need for
strong and performant preQC algorithms, so they may be (ahem) paired
with the postQC algorithms to ensure that the combination is resistant
to attack in at least the classical setting.

-d