Re: [Cfrg] Safecurves draft

Johannes Merkle <johannes.merkle@secunet.com> Thu, 09 January 2014 12:15 UTC

Return-Path: <Johannes.Merkle@secunet.com>
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 8B7F71AE29B for <cfrg@ietfa.amsl.com>; Thu, 9 Jan 2014 04:15:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.138
X-Spam-Level:
X-Spam-Status: No, score=-3.138 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] 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 voE7KTkiY5z7 for <cfrg@ietfa.amsl.com>; Thu, 9 Jan 2014 04:15:44 -0800 (PST)
Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 27A641AE247 for <cfrg@irtf.org>; Thu, 9 Jan 2014 04:15:43 -0800 (PST)
Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 669751A0078; Thu, 9 Jan 2014 13:15:32 +0100 (CET)
X-Virus-Scanned: by secunet
Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Bh9YLHwSImuC; Thu, 9 Jan 2014 13:15:31 +0100 (CET)
Received: from mail-gw-int (unknown [10.53.40.207]) by a.mx.secunet.com (Postfix) with ESMTP id 3FC1F1A006C; Thu, 9 Jan 2014 13:15:31 +0100 (CET)
Received: from [10.53.40.200] (port=7808 helo=mail-srv1.secumail.de) by mail-gw-int with esmtp (Exim 4.80 #2 (Debian)) id 1W1EST-000668-Ln; Thu, 09 Jan 2014 13:11:33 +0100
Received: from [10.208.1.57] ([10.208.1.57]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Jan 2014 13:15:31 +0100
Message-ID: <52CE92E2.9020804@secunet.com>
Date: Thu, 09 Jan 2014 13:15:30 +0100
From: Johannes Merkle <johannes.merkle@secunet.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Dan Brown <dbrown@certicom.com>, Watson Ladd <watsonbladd@gmail.com>, "cfrg@irtf.org" <cfrg@irtf.org>
References: <20140109031144.6111382.52184.8264@certicom.com>
In-Reply-To: <20140109031144.6111382.52184.8264@certicom.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Jan 2014 12:15:31.0352 (UTC) FILETIME=[7D96A980:01CF0D34]
Subject: Re: [Cfrg] Safecurves draft
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: Thu, 09 Jan 2014 12:15:46 -0000

Dan Brown schrieb am 09.01.2014 04:11:
> I don't object to these curves.
> 

I also support the draft. Diversity in available EC parameters is important as a safeguard to potential future
improvements in cryptoanalysis. And I acknowledge that certain applications may require particular efficient ECC
implementations for which the Brainpool curves may not be eligible.


> Still, could we please call these curves something more specific and neutral than just "safe"?
> 
> Aren't many other curves safe so far as we know?
> 
> For example, take the Brainpool curves, use a Montgomery (Brier-Joye?) ladder, and an extra careful implementation, and do ECDHE, with some other kind of safe auth. Is that not safe?
> 
> Indeed, what about the NIST curves?
> 

I share Dan's concerns with the naming as "safe curves". Not only is this name misleading w.r.t the potential security /
safety of other curves (well, for the NIST curves we simply don't know), but it may also turn out to be extremely
unfortunate in the (unlikely) event that the "safe curves" become vulnerable to a new (currently unforeseen) attack. In
this case, the name "safe curve" will turn out to be fatally misleading.

Johannes