Re: [Cfrg] Hardware requirements for elliptic curves

Alyssa Rowan <akr@akr.io> Mon, 15 September 2014 12:50 UTC

Return-Path: <akr@akr.io>
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 5F1E71A0329 for <cfrg@ietfa.amsl.com>; Mon, 15 Sep 2014 05:50:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-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 GsqNx2xoSnN1 for <cfrg@ietfa.amsl.com>; Mon, 15 Sep 2014 05:50:40 -0700 (PDT)
Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DDAF1A0326 for <cfrg@irtf.org>; Mon, 15 Sep 2014 05:50:40 -0700 (PDT)
User-Agent: K-9 Mail for Android
In-Reply-To: <201409151253.28918.manfred.lochter@bsi.bund.de>
References: <CALCETrWWoQJn58nJucvC1YM_3gi_hZvzY5c-QbA19huMOabyYQ@mail.gmail.com> <5411E4BB.3010000@gmx.net> <CACsn0ckpGFdPfge8j2-iBoYb=shFWUxTehA7JziyJw2vWBBNww@mail.gmail.com> <201409151253.28918.manfred.lochter@bsi.bund.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="UTF-8"
From: Alyssa Rowan <akr@akr.io>
Date: Mon, 15 Sep 2014 13:50:33 +0100
To: cfrg@irtf.org
Message-ID: <51e8c23b-1599-4523-a436-bf9125130773@email.android.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/kJHkN3DFaPI_fDTUlqgpZi-b9bQ
Subject: Re: [Cfrg] Hardware requirements for elliptic curves
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: Mon, 15 Sep 2014 12:50:42 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 15 September 2014 11:53:28 BST, "Lochter, Manfred" <manfred.lochter@bsi.bund.de> wrote:
>you are right when you assume that Brainpool users can live with what
>they
>have, if Brainpool-like curves will be mandatory to implement for TLS
>1.3.

The question of what should be MTI in TLS 1.3 and why is plainly a matter for the upstream TLS list to debate, not CFRG.

If people want random primes, Brainpool already gives you those - that's Watson's point. I don't think that's what upstream are looking for, though. If people wanted that, they'd be using it already: yet UTA actually removed Brainpool from their draft recommendations recently due to its rarity and performance.

It just doesn't look like the pendulum's swinging that way, and I can see why: the relatively poor performance of Brainpool-class random primes in software; the difficulty of securing generic elliptic curve software routines against timing side-channels; and the sheer cost-multiplication potential of a proposal to mandate the option of using relatively-inefficient crypto near-universally across the web - including at CDN scale!? I think personally you'd face a massive uphill struggle arguing for random curve support to ever be anything better than MAY. But that's something I reckon you should take over to those lists if you *really* want to raise it? (I'll bring marshmallows! <g>)

If your hardware is truly securely flexible, then you can adapt with no trouble; if it's not flexible enough to securely work with efficient sparse primes that also perform well in software, well, you probably need to consider at least updating it so it is (how is it with the NIST "Solinas primes"? Equally bad, one would have thought? Yet they're the most deployed by far...).

Also, please don't forget: FIPS 140-2 (/3?) evaluations/certifications are not exclusive to hardware, and neither are Common Criteria EAL*: both happen for certain software implementations.

- --
/akr
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQI3BAEBCgAhBQJUFuCZGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE
jtkWi2t6rk4P/2aqUxG+sRZfFlGZbEd2Urojxt7cyN6Bpi3iEQMjBTCgMcdnIWFb
l1K7K6LJABJMrNTE7Yx89ZUYCSSziZPpaajyX7pUNJeqTxIDMPukS2Dw8u7eZfc7
0fcba4ApF7XTx+6lyLP+xRaFCj3OxmLHTuQPY0ww278f4N3B8FyeIH/re50NbpAz
FWunGh9rPN15JKFbj1QCfIDKcqLyrMrVMGQdfj/txLITJ2eIYyQqyQ3VfoSPE2KG
rcEv0OHxdxK9xVCjn8rzymaHHI6kb3pJeDQX9g7iXYvpILcPRAYsI7HM943I+0BX
zc/WC+bIfo519Mjbnzuq9AMukb41m2lAqYHM4mhn9GFkTCsJLg0b7n35P46OKhMI
SHJAsfY330M4ViubsdQL7EyB8rdhApYcAdH4i7uOTkrXqv4GCNgIMpH7/6AgTP7z
mkWDiTPBeDX8fPat652/3BycRnxJ93IoCvSWp27rWi5FVrKnd2uuRqyp6OESU/rS
f/yM/8GgeaKhaA02hWeRuyy37DWRTLBNpps2qc9sbG2HKjHCNYYOgHDaF39GGBqr
rRniOfH6WjE4zg7gLqhN1kFrgKpS8R2Z6GWQz1LM1VTRq2Hp0neY1wEoi7ZTen4O
T/yFc90g0JF0AUTfYMUpYMyI6mIXCrQbub8h9JcWOrH22PumJHNhBFXS
=ivge
-----END PGP SIGNATURE-----