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