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-----
- [Cfrg] Hardware requirements for elliptic curves Joppe Bos
- Re: [Cfrg] Hardware requirements for elliptic cur… Alyssa Rowan
- Re: [Cfrg] Hardware requirements for elliptic cur… Michael Hamburg
- Re: [Cfrg] Hardware requirements for elliptic cur… Johannes Merkle
- Re: [Cfrg] Hardware requirements for elliptic cur… Michael Hamburg
- Re: [Cfrg] Hardware requirements for elliptic cur… Alyssa Rowan
- Re: [Cfrg] Hardware requirements for elliptic cur… Andy Lutomirski
- Re: [Cfrg] Hardware requirements for elliptic cur… Robert Ransom
- Re: [Cfrg] Hardware requirements for elliptic cur… Lochter, Manfred
- Re: [Cfrg] Hardware requirements for elliptic cur… Johannes Merkle
- Re: [Cfrg] Hardware requirements for elliptic cur… Wieland.Fischer
- Re: [Cfrg] Hardware requirements for elliptic cur… Alyssa Rowan
- Re: [Cfrg] Hardware requirements for elliptic cur… Watson Ladd
- Re: [Cfrg] Hardware requirements for elliptic cur… Patrick Georgi
- Re: [Cfrg] Hardware requirements for elliptic cur… Paul Lambert
- Re: [Cfrg] Hardware requirements for elliptic cur… Torsten Schuetze
- Re: [Cfrg] Hardware requirements for elliptic cur… Torsten Schuetze
- Re: [Cfrg] Hardware requirements for elliptic cur… Andy Lutomirski
- Re: [Cfrg] Hardware requirements for elliptic cur… Mike Hamburg
- Re: [Cfrg] Hardware requirements for elliptic cur… Torsten Schuetze
- Re: [Cfrg] Hardware requirements for elliptic cur… Watson Ladd
- Re: [Cfrg] Hardware requirements for elliptic cur… Mike Hamburg
- Re: [Cfrg] Hardware requirements for elliptic cur… Alyssa Rowan
- Re: [Cfrg] Hardware requirements for elliptic cur… Lochter, Manfred
- Re: [Cfrg] Hardware requirements for elliptic cur… Alyssa Rowan
- Re: [Cfrg] Hardware requirements for elliptic cur… Dirk Feldhusen
- Re: [Cfrg] Hardware requirements for elliptic cur… Lochter, Manfred
- Re: [Cfrg] Hardware requirements for elliptic cur… Ilari Liusvaara
- Re: [Cfrg] Hardware requirements for elliptic cur… Watson Ladd
- Re: [Cfrg] Hardware requirements for elliptic cur… Peter Gutmann
- [Cfrg] Trusting government certifications of cryp… D. J. Bernstein
- Re: [Cfrg] Trusting government certifications of … David Jacobson
- Re: [Cfrg] Trusting government certifications of … Torsten Schütze
- Re: [Cfrg] Trusting government certifications of … Watson Ladd
- Re: [Cfrg] Trusting government certifications of … Dirk Feldhusen
- Re: [Cfrg] Trusting government certifications of … Michael Hamburg
- Re: [Cfrg] Trusting government certifications of … Dirk Feldhusen
- Re: [Cfrg] Trusting government certifications of … Lochter, Manfred
- Re: [Cfrg] Trusting government certifications of … Mike Hamburg
- Re: [Cfrg] Primes vs. hardware side channels David Leon Gil
- [Cfrg] Primes vs. hardware side channels D. J. Bernstein
- Re: [Cfrg] Primes vs. hardware side channels Alyssa Rowan