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