Re: [Cfrg] Requirements for elliptic curves with a view towards constrained devices
William Whyte <wwhyte@securityinnovation.com> Sat, 22 November 2014 12:13 UTC
Return-Path: <wwhyte@securityinnovation.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 62DCB1A1B0F for <cfrg@ietfa.amsl.com>; Sat, 22 Nov 2014 04:13:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 OzM_CKA_Y3jW for <cfrg@ietfa.amsl.com>; Sat, 22 Nov 2014 04:13:15 -0800 (PST)
Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1A681A1B07 for <cfrg@irtf.org>; Sat, 22 Nov 2014 04:13:15 -0800 (PST)
Received: by mail-qa0-f42.google.com with SMTP id j7so4626374qaq.1 for <cfrg@irtf.org>; Sat, 22 Nov 2014 04:13:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=securityinnovation.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0LnAE6a8us++J59641tF5aoIvMK6OrrMCgLYBJHklT8=; b=Qlv87bQcgvN9SQ3erpiXLdvQ1wg1fei0VJvkmZst9L1zRP4MoOAZZhDANhE4hq3Ns4 aP0s4NIC/wCvV5FBNMaWAEUSuC3oOjSbZ+YqTNPI3+BzsGg+DXIWdteSXKiSaMnIk5iG TCCpJk9kLWLti4LY2s8XoDsmd17am5aTKvTHE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0LnAE6a8us++J59641tF5aoIvMK6OrrMCgLYBJHklT8=; b=fBD5MDZ+TF1hvUfHPDsaLYf5tAdxWLivEUVxCf8wMxt3Issyn4bfzMqJSnSQrFp9yK OUo95aSW4LZ22cG4yaMER9LDfQbsQjn+zNo+r2RWKpHj9VC8IKmsKNUrc2RO2Qx0TQzk jaGFrs+p+PNm+i14LTw6f9wMyQ0t0x/ImtJ2k1dUvL8wVaH9qmF7ip/3F7k1BpXliGUf ND2RsbsPEszQnoahraxxrdiDzudfN9j5DCSIOE2fpi9efXyESW13s+O2Cpdpvds3QjFN W/RyCMIwILnmVCWpuO5H8UGt38dNqlAjeSbaEXZnPh8D/78G9aq4sKSVmrEJNeGHGWPL zYyA==
X-Gm-Message-State: ALoCoQliY30AmI2zDhWYZ3MX3BSmrhd80h564IYl724RW97gYITo6ItnwJKtqoPF19Bf+VDdJNwE
MIME-Version: 1.0
X-Received: by 10.224.148.18 with SMTP id n18mr14055310qav.100.1416658394340; Sat, 22 Nov 2014 04:13:14 -0800 (PST)
Received: by 10.96.104.202 with HTTP; Sat, 22 Nov 2014 04:13:14 -0800 (PST)
In-Reply-To: <CACsn0ckUoijv-uD3yksOQpRW9E-smF1wg9=+L2BVrN1+wRv0tw@mail.gmail.com>
References: <8FBEB0194016E64D9DF7E7855CD88E0C073A6D@FRPASERV0088.emea.oberthurcs.com> <201411200901.53517.manfred.lochter@bsi.bund.de> <CACsn0cmV6aOMx+eiLa0iP7rYiU4ZVmeDbNPhTSz_a6oU1=kWjA@mail.gmail.com> <201411211351.04473.manfred.lochter@bsi.bund.de> <CACsn0ckUoijv-uD3yksOQpRW9E-smF1wg9=+L2BVrN1+wRv0tw@mail.gmail.com>
Date: Sat, 22 Nov 2014 07:13:14 -0500
Message-ID: <CACz1E9oS-CRsFAe2Yj82emoO7jic=59NtBDFq72M-8Msi7UOPw@mail.gmail.com>
From: William Whyte <wwhyte@securityinnovation.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: multipart/alternative; boundary="089e0153838e5cf9800508717c66"
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/1QmSv_o3gkLtUU0XvzXdLefK2_0
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Requirements for elliptic curves with a view towards constrained devices
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: Sat, 22 Nov 2014 12:13:18 -0000
On Fri, Nov 21, 2014 at 11:58 AM, Watson Ladd <watsonbladd@gmail.com> wrote: > The V2V projects aren't. Despite high performance constraints they are > not making optimal choices. Batch signatures would seem a natural fit, > and yet ECDSA is still being used. P256 seems to be selected, despite > Koblitz curves existing. But blinding won't be used: the performance > hit is too much, and the security model doesn't require it. It doesn't > seem like they will switch to Curve25519 if the CFRG recommends it. > Given the scale of the V2V projects and the difficulty of upgrading devices in the field, there's a strong argument that the risk-minimizing approach in V2V is to use the flavor of ECC that's had widespread deployment for the longest and which has best availability in hardware. Performance isn't the only consideration. The auto industry isn't particularly interested in being the first mover in adoption of a newer curve, and there's already been significant product development work focused on the NIST curves. There are also regulatory concerns. In the US, it's not clear that devices that implement a curve other than the NIST curves would be FIPS-certifiable, should this turn out to be a requirement (which also isn't clear). In Europe, BSI are strongly lobbying for the use of random curves. In an industry that's more heavily regulated than the internet, it makes sense to be biased towards solutions we already know the regulators will accept. I agree that ed25519 has very nice properties and all other things being equal it would be good to see it used in V2V. (I also feel that until we're told where the seeds came from, any continued use of the NIST curves is rewarding bad practice). The batching in particular seems like it could result in actual reductions in hardware cost for the verify-everything approach. (Not all incoming signatures need to be verified, though obviously if you do verify everything it gives you more flexibility in processing after reception). I will say though that I haven't heard crypto hardware suppliers in the V2V space making the argument that they could reduce costs and prices by moving to ed25519 and batching, and unless we do hear that it'll be very hard to make a change. Cheers, William
- [Cfrg] Requirements for elliptic curves with a vi… RONDEPIERRE Franck
- Re: [Cfrg] Requirements for elliptic curves with … Dan Brown
- Re: [Cfrg] Requirements for elliptic curves with … Watson Ladd
- Re: [Cfrg] Requirements for elliptic curves with … Lochter, Manfred
- Re: [Cfrg] Requirements for elliptic curves with … Manuel Pégourié-Gonnard
- Re: [Cfrg] Requirements for elliptic curves with … Lochter, Manfred
- Re: [Cfrg] Requirements for elliptic curves with … Watson Ladd
- Re: [Cfrg] Requirements for elliptic curves with … Lochter, Manfred
- Re: [Cfrg] Requirements for elliptic curves with … Alyssa Rowan
- Re: [Cfrg] Requirements for elliptic curves with … Watson Ladd
- Re: [Cfrg] Requirements for elliptic curves with … Andy Lutomirski
- [Cfrg] Handling invalid points D. J. Bernstein
- Re: [Cfrg] Handling invalid points Michael Hamburg
- Re: [Cfrg] Handling invalid points Michael Hamburg
- Re: [Cfrg] Requirements for elliptic curves with … Watson Ladd
- Re: [Cfrg] Handling invalid points Natanael
- Re: [Cfrg] Requirements for elliptic curves with … William Whyte
- Re: [Cfrg] Handling invalid points Ilari Liusvaara
- Re: [Cfrg] Handling invalid points Stephen Farrell
- Re: [Cfrg] Requirements for elliptic curves with … D. J. Bernstein
- Re: [Cfrg] Handling invalid points D. J. Bernstein
- Re: [Cfrg] Handling invalid points Adam Langley