Re: [Cfrg] ECC desiderata

"Blumenthal, Uri - 0668 - MITLL" <uri@ll.mit.edu> Fri, 08 August 2014 18:16 UTC

Return-Path: <prvs=32978e657e=uri@ll.mit.edu>
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 ACE851A0004 for <cfrg@ietfa.amsl.com>; Fri, 8 Aug 2014 11:16:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.277
X-Spam-Level:
X-Spam-Status: No, score=-3.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RAZOR2_CHECK=0.922, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
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 mnovWpwc0Vmx for <cfrg@ietfa.amsl.com>; Fri, 8 Aug 2014 11:16:15 -0700 (PDT)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 60D4C1A0008 for <cfrg@irtf.org>; Fri, 8 Aug 2014 11:16:14 -0700 (PDT)
Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s78IFxaP031691 for <cfrg@irtf.org>; Fri, 8 Aug 2014 14:16:14 -0400
From: "Blumenthal, Uri - 0668 - MITLL" <uri@ll.mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A4E90612-4229-4EB7-9B5D-D27D2CD3EC09"
Message-ID: <5AC6A085-5E1B-4A1E-B950-6E230ED04DF2@ll.mit.edu>
MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Date: Fri, 08 Aug 2014 14:15:50 -0400
References: <20140808160744.7250.qmail@cr.yp.to> <CADMpkcKRvi7WcbR==XF1G5b94jN7Y5+a2j_zDE8AZFTzy_UERg@mail.gmail.com>
To: "cfrg@irtf.org" <cfrg@irtf.org>
In-Reply-To: <CADMpkcKRvi7WcbR==XF1G5b94jN7Y5+a2j_zDE8AZFTzy_UERg@mail.gmail.com>
X-Mailer: Apple Mail (2.1510)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.27, 0.0.0000 definitions=2014-08-08_05:2014-08-08,2014-08-08,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1408080219
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/OthqZTqC3xQG64h6rr26PbmqJMg
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:16:17 -0000

On Aug 8, 2014, at 14:07 , Bodo Moeller <bmoeller@acm.org> wrote:
> D. J. Bernstein <djb@cr.yp.to>:
> 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.

+1

I'd much rather deal with cofactor 1 curves.