IETF Logo Mail Archive

Re: [Cfrg] ECC desiderata

Bodo Moeller <bmoeller@acm.org> Fri, 08 August 2014 18:07 UTC

Return-Path: <SRS0=XLB+=5C=acm.org=bmoeller@srs.kundenserver.de>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5FD1B2CA4 for <cfrg@ietfa.amsl.com>; Fri, 8 Aug 2014 11:07:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.693
X-Spam-Level: **
X-Spam-Status: No, score=2.693 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RAZOR2_CHECK=0.922, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 kv1gCeK43tou for <cfrg@ietfa.amsl.com>; Fri, 8 Aug 2014 11:07:37 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83C8D1A0021 for <cfrg@irtf.org>; Fri, 8 Aug 2014 11:07:37 -0700 (PDT)
Received: from mail-yk0-f177.google.com (mail-yk0-f177.google.com [209.85.160.177]) by mrelayeu.kundenserver.de (node=mreue103) with ESMTP (Nemesis) id 0Mbb9R-1Wwue20JSn-00J3XP; Fri, 08 Aug 2014 20:07:35 +0200
Received: by mail-yk0-f177.google.com with SMTP id 79so4069044ykr.22 for <cfrg@irtf.org>; Fri, 08 Aug 2014 11:07:33 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.101.138 with SMTP id b10mr17262564yhg.91.1407521253884; Fri, 08 Aug 2014 11:07:33 -0700 (PDT)
Received: by 10.170.129.17 with HTTP; Fri, 8 Aug 2014 11:07:33 -0700 (PDT)
In-Reply-To: <20140808160744.7250.qmail@cr.yp.to>
References: <20140808160744.7250.qmail@cr.yp.to>
Date: Fri, 08 Aug 2014 14:07:33 -0400
Message-ID: <CADMpkcKRvi7WcbR==XF1G5b94jN7Y5+a2j_zDE8AZFTzy_UERg@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: "cfrg@irtf.org" <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="20cf301b606f5a08e805002214ce"
X-Provags-ID: V02:K0:HQovlRfzq0YWVMzit8cqcEgOG5Q8sOZoBwPjHK2adr1 xx4Gc/Mj2O8+cq0kWF41k66ZehtFfflV1fOE8Jrw8fUr7s04LJ O2mxxhe8bTjDZYyPoMAa6GBR00wH45e+C6lwsggJ0Xh3uvwUHW tc2Kt/h5K82fRhIIsqcaViuKPMqZ/0PIScyOwzVg4avTKLyQME LXWQCytLQ59LGc5Or/1XVf0rPsBR5MOHEYqg8vEH0eL/p2Kgnb 8AwWht7db8Czn7RYZf2gsQ4eeIy2vB26gQmzTVEP6hRXR1Bp5y LrYD1uaRyEwB7inxg8M+UP85cxcmYIJi5v79S3kfSMzb7VRqYN Oc7IPBnQGkKD5vadtiJdDjybTzBeX61/TtVgDVrKubEch/zT91 sIJerkV0VSn7fB0/KmudcXaLO4UU4NBRRQA4hhnJfcWJSZ1FIM qxsuW
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/rpN0vJlaoPqBvG9c5-RhBJPaQqw
Subject: Re: [Cfrg] ECC desiderata
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Aug 2014 18:08:27 -0000

D. J. Bernstein <djb@cr.yp.to>:


>    D1. Speed and simplicity (and speed-simplicity combinations) for
>    secure implementations.
>
>    D2. Avoiding speed incentives and simplicity incentives towards
>    insecure implementations.
>
> Curves with cofactor 1 obviously score so badly on these axes---without
> having any compensating advantages---that I think they should be taken
> off the table.


The speed advantages are pretty compelling, but I don't agree that curves
with cofactor 1 don't have *any* compensating advantages.

As the example of TLS with its protocol flaws shows (see the unknown
key-share attacks in https://secure-resumption.com/tlsauth.pdf), it is
possible to end up in a situation in which public-key validation *does*
matter; it's easier to get right with cofactor 1.  Using a cryptographic
scheme that normally has no need for this can turn into a disadvantage,
unless you "redundantly" do such checks anyway.
​
Bodo

v2.23.0 | Report a Bug | By Email