Re: [Cfrg] Hardware requirements for elliptic curves
"Lochter, Manfred" <manfred.lochter@bsi.bund.de> Mon, 15 September 2014 10:53 UTC
Return-Path: <manfred.lochter@bsi.bund.de>
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 4C11F1A0B01 for <cfrg@ietfa.amsl.com>; Mon, 15 Sep 2014 03:53:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.201
X-Spam-Level:
X-Spam-Status: No, score=-8.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, UNPARSEABLE_RELAY=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 IO4SErTsWaCK for <cfrg@ietfa.amsl.com>; Mon, 15 Sep 2014 03:53:45 -0700 (PDT)
Received: from m2-bn.bund.de (m2-bn.bund.de [77.87.228.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADA441A0AFA for <cfrg@irtf.org>; Mon, 15 Sep 2014 03:53:44 -0700 (PDT)
Received: from m2.mfw.bn.ivbb.bund.de (localhost.mfw.bn.ivbb.bund.de [127.0.0.1]) by m2-bn.bund.de (8.14.3/8.14.3) with ESMTP id s8FArg65017706 for <cfrg@irtf.org>; Mon, 15 Sep 2014 12:53:42 +0200 (CEST)
Received: (from localhost) by m2.mfw.bn.ivbb.bund.de (MSCAN) id 5/m2.mfw.bn.ivbb.bund.de/smtp-gw/mscan; Mon Sep 15 12:53:42 2014
X-P350-Id: 20b6296a531a5abe
X-Virus-Scanned: by amavisd-new at bsi.bund.de
From: "Lochter, Manfred" <manfred.lochter@bsi.bund.de>
Organization: BSI Bonn
To: cfrg@irtf.org
Date: Mon, 15 Sep 2014 12:53:28 +0200
User-Agent: KMail/1.9.10 (enterprise35 20140205.23bb19c)
References: <CALCETrWWoQJn58nJucvC1YM_3gi_hZvzY5c-QbA19huMOabyYQ@mail.gmail.com> <5411E4BB.3010000@gmx.net> <CACsn0ckpGFdPfge8j2-iBoYb=shFWUxTehA7JziyJw2vWBBNww@mail.gmail.com>
In-Reply-To: <CACsn0ckpGFdPfge8j2-iBoYb=shFWUxTehA7JziyJw2vWBBNww@mail.gmail.com>
X-KMail-QuotePrefix: >
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-ID: <201409151253.28918.manfred.lochter@bsi.bund.de>
X-AntiVirus: checked by Avira MailGate (version: 3.2.1.26; AVE: 8.3.24.24; VDF: 7.11.172.30; host: sgasmtp2.bsi.de); id=28090-BMjEr5
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/nngAK3pvK6YqLvZNCF8JMfO1OJs
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 10:53:49 -0000
Watson, 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. If this will not be the case the crucial points are interoperability and cost: Assume a server using software optimized code wants to talk to a smart card implementation of ECC, supporting random primes. Which curve will be selected for this communication by TLS? I see three possible solutions: a) The special prime curve is selected. This means that the smart card has to be certified (e.g. according to the Common Criteria) for use with this curve. Note that certificates usually specify which curve has to be used. Adding new curves increases the cost of certification. It has also turned out that protection of hardware implementations of ECC over special prime fields is more costly. b) The random prime curve is selected. In this case the software side has to provide a second implementation of ECC that supports random primes. This leads to a small increase of cost on the software side. c) Client and server do not support a common curve. In this case no secure communication can be established. This course is counterproductive and should not be chosen. A possible solution would thus be to make at least one curve over a random prime field mandatory (for each security level). This solution implies that there will be more than one standard curve. Sincerely Manfred Lochter __________ ursprüngliche Nachricht __________ Von: Watson Ladd <watsonbladd@gmail.com> Datum: Freitag, 12. September 2014, 03:56:54 An: Torsten Schuetze <torsten.schuetze@gmx.net> Kopie: "cfrg@irtf.org" <cfrg@irtf.org> Betr.: Re: [Cfrg] Hardware requirements for elliptic curves > So I don't understand why you are asking for something that the > brainpool curves don't already give you. We are not removing curves > from TLS, and we already knew that FIPS users were likely to not adopt > the new curves, so nonsupport isn't an issue. Even if we had only the > NIST curves, and did nothing, you would be in the same position. There > is an enormous performance benefit in software for special primes, and > the sort of side channel attacks that require special blinding don't > matter on servers, even if the curve is implemented on hardware. > > I think it's clear that the desired properties are different enough > that there is no way to satisfy everyone. > > Sincerely, > Watson Ladd > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg -- Lochter, Manfred -------------------------------------------- Bundesamt für Sicherheit in der Informationstechnik (BSI) Referat K21 Godesberger Allee 185 -189 53175 Bonn Postfach 20 03 63 53133 Bonn Telefon: +49 (0)228 99 9582 5643 Telefax: +49 (0)228 99 10 9582 5643 E-Mail: manfred.lochter@bsi.bund.de Internet: www.bsi.bund.de www.bsi-fuer-buerger.de
- [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