Re: [Cfrg] Hardware requirements for elliptic curves
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Mon, 15 September 2014 18:09 UTC
Return-Path: <ilari.liusvaara@elisanet.fi>
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 0C7671A891C for <cfrg@ietfa.amsl.com>; Mon, 15 Sep 2014 11:09:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 4ypUhxCQ4Gs4 for <cfrg@ietfa.amsl.com>; Mon, 15 Sep 2014 11:09:23 -0700 (PDT)
Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D9C61A892E for <cfrg@irtf.org>; Mon, 15 Sep 2014 10:26:40 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 2E94E90132; Mon, 15 Sep 2014 20:26:38 +0300 (EEST)
Date: Mon, 15 Sep 2014 20:26:37 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: "Lochter, Manfred" <manfred.lochter@bsi.bund.de>
Message-ID: <20140915172637.GA30420@LK-Perkele-VII>
References: <CALCETrWWoQJn58nJucvC1YM_3gi_hZvzY5c-QbA19huMOabyYQ@mail.gmail.com> <201409151253.28918.manfred.lochter@bsi.bund.de> <51e8c23b-1599-4523-a436-bf9125130773@email.android.com> <201409151743.19854.manfred.lochter@bsi.bund.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <201409151743.19854.manfred.lochter@bsi.bund.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/zYVLkWXkGfVCHkp7Pq2u-cqLjrY
Cc: cfrg@irtf.org
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 18:09:28 -0000
On Mon, Sep 15, 2014 at 05:43:19PM +0200, Lochter, Manfred wrote: > __________ ursprüngliche Nachricht __________ > > Von: Alyssa Rowan <akr@akr.io> > > > 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!? > > What is your measure for inefficiency? Cost per Signature? Or time per > signature? Or something different? Relatively to what? Both cost per signature and cost per verification of signature. Can fairly easily be 2x cost. And nobody wants that sort of cost, unless 1) Legally mandated to. 2) Having to interoperate. And nobody is proposing to remove the Brainpool codepoints from TLS. Special servers that communicate with smartcards or whatever (most don't!) can implement those. Having to implement random curves would be RFC6919 "MUST (but we know you won't)". > > > > 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...). > > This is not a hardware question. Actually the problem is that curves over > special primes need more SCA countermesures. This is also true for software > running on a general purpose processor. One problem here is that general purpose CPUs are hugely complex, so it is very difficult to know how various operations affect side channels like EM or PA. But withstanding software-only attacks (and that goes far beyond global timing) is likely a huge help here. And those software-only attacks are not jokes. Modern CPUs and OSes tend to be extremely vulernable. Special-purpose crypto chips can at least be designed at hardware level to reduce SCA attacks (sometimes well, sometimes badly). -Ilari
- [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