Re: [Cfrg] Hardware requirements for elliptic curves

Dirk Feldhusen <dirk.feldhusen@src-gmbh.de> Mon, 15 September 2014 14:34 UTC

Return-Path: <dirk.feldhusen@src-gmbh.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 054E31A0368 for <cfrg@ietfa.amsl.com>; Mon, 15 Sep 2014 07:34:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 s31ssAYLwjp1 for <cfrg@ietfa.amsl.com>; Mon, 15 Sep 2014 07:34:16 -0700 (PDT)
Received: from apfel.src-bonn.de (apfel.src-bonn.de [78.35.41.6]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA8A71A0339 for <cfrg@irtf.org>; Mon, 15 Sep 2014 07:34:15 -0700 (PDT)
Received: from imail (imail.src-gmbh.lan [192.168.8.3]) by apfel.src-bonn.de (Postfix) with SMTP id C8CF695A1; Mon, 15 Sep 2014 16:34:11 +0200 (CEST)
Message-ID: <5416F8E3.1030807@src-gmbh.de>
Date: Mon, 15 Sep 2014 16:34:11 +0200
From: Dirk Feldhusen <dirk.feldhusen@src-gmbh.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Alyssa Rowan <akr@akr.io>, cfrg@irtf.org
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> <51e8c23b-1599-4523-a436-bf9125130773@email.android.com>
In-Reply-To: <51e8c23b-1599-4523-a436-bf9125130773@email.android.com>
Content-Type: multipart/alternative; boundary="------------000305080000040501030807"
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/4SvKyq6lQH65AWfSLLCj8j5cUpk
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 14:34:18 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Am 15.09.2014 14:50, schrieb Alyssa Rowan:
> 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>)

I don't understand why securing generic elliptic curve implementation
should be harder. Regularised scalar multiplication methods are
quite standard in security implementations. But (nearly) time constant
modular multiplication or LIM routines for fixed bit length I've seen up
to now only in hardware. Contrariwise for software implementations, see
the for instance bunch of publications on RSA timing attacks. Why there
are no time dependencies on the arguments for  modular multiplication
with special primes?
Even when the algorithm is time constant in theory there could be
properties of the hardware which could complicate the situation, for
instance the bug attacks (Crypto 2008) or cache timing attacks on the AES.
Side channel resistance is a property of the software together with the
underlying hardware.

Cheers,
Dirk

(where are the marshmallows?)


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
 
iEYEARECAAYFAlQW+OAACgkQQ9KtQ4ejsgyxOgCfTiU3dYWL5GHOSeLS1HH5hItw
YB0AoMc3X2eq8FMnZkoXRy1nbtRxJ6iE
=f3v7
-----END PGP SIGNATURE-----