Re: [Cfrg] Hardware requirements for elliptic curves

Watson Ladd <watsonbladd@gmail.com> Wed, 17 September 2014 01:59 UTC

Return-Path: <watsonbladd@gmail.com>
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 193011A00AF for <cfrg@ietfa.amsl.com>; Tue, 16 Sep 2014 18:59:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level:
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 UAvSnrxvzuoK for <cfrg@ietfa.amsl.com>; Tue, 16 Sep 2014 18:59:54 -0700 (PDT)
Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8BB91A0099 for <cfrg@irtf.org>; Tue, 16 Sep 2014 18:59:53 -0700 (PDT)
Received: by mail-qg0-f49.google.com with SMTP id j5so976523qga.22 for <cfrg@irtf.org>; Tue, 16 Sep 2014 18:59:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=fSMrAGvRFYo/u6B3M5YIqfGd6iVfDSNUFPuvlcL6js0=; b=qT7brnJNvxcFX1RVjDQfy740t4iVprbN8YHz8AUdsiDQf+Svezb2+GPVlFfGdpnaXV Rv8aOuxReiIz9KJJaLvpBI2bY+1NT9tDql9+6wCH6kt3NE+wmfCjMrOq7KINBMufCAjP Qwf7Q5m5jHyrBvHqFPPneB6p1fUQ9mviQW3UpeQRLwRN0bLKKO079Ak7ALcj5S5HwPix QQmTc+l8Fr3IA+bH9KsL5UmM+efqhaAj9bIXHXjclNBFjrrTyojSuoiWWnpIW0Vj2VcM fW6rmLWAcFx57nDi2rmRXrWg3tJ51AIDSKXYVDGGJ5FEbGM6DRB0kEJ46CF+upgqt5Vb hPQA==
MIME-Version: 1.0
X-Received: by 10.236.160.225 with SMTP id u61mr47608629yhk.4.1410919192896; Tue, 16 Sep 2014 18:59:52 -0700 (PDT)
Received: by 10.170.207.216 with HTTP; Tue, 16 Sep 2014 18:59:52 -0700 (PDT)
In-Reply-To: <201409151743.19854.manfred.lochter@bsi.bund.de>
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>
Date: Tue, 16 Sep 2014 18:59:52 -0700
Message-ID: <CACsn0cmGnmrfJoGC0YSEO5Fj6K05y3EWySrrHON06qKp8NVwUQ@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "Lochter, Manfred" <manfred.lochter@bsi.bund.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/4gwHYSsinUrTeO1Awcdh_dzUf0o
Cc: "cfrg@irtf.org" <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: Wed, 17 Sep 2014 01:59:56 -0000

On Mon, Sep 15, 2014 at 8:43 AM, Lochter, Manfred
<manfred.lochter@bsi.bund.de>; wrote:
>
>
>
>
>
> __________ ursprüngliche Nachricht __________
>
> Von:            Alyssa Rowan <akr@akr.io>;
> Datum:  Montag, 15. September 2014, 14:50:33
> An:             cfrg@irtf.org
> Kopie:
> Betr.:  Re: [Cfrg] Hardware requirements for elliptic curves
>
>
>>
>> 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;
>
> Actually I don' t see your point here. Watson's mail was about special primes
> versus random primes. The use of special primes does not harden
> implementations against timing attacks. But the use of special primes makes
> additional SCA countermeasures necessary, thus increasing implementation
> cost.

Most users do not need power or EM SCA protection: they rely on
distance together with physical controls, or are so screwed anyway
that it doesn't matter.

Amazon's Cloud HSM doesn't have RSA blinding turned on by default,
showing the extent to which side channels are a concern.
>
>> 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?
>
>> 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>)
>
> Can we agree on licorice?
>
>>
>> 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.
> In fact the discussion here is not about hardware or software. It is about
> different hardware platforms (e.g. server, smart card) on which ECC is
> running under different attack models.

Exactly right: the costs are so wildly different that the best
solution when you don't worry about power analysis is very different
from when you do. That's an argument for two different solutions, not
one that satisfies no one.

Sincerely,
Watson Ladd
>>
>> 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.
>
> Oh, really? Then you have a CC protection profile for TLS running in software
> available for review? At which EAL?
>
> --
> 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 mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin