Re: [Cfrg] ECC reboot (Was: When's the decision?)

Watson Ladd <watsonbladd@gmail.com> Fri, 17 October 2014 16:23 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 828EA1A1BC6 for <cfrg@ietfa.amsl.com>; Fri, 17 Oct 2014 09:23:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 OBGMuf5iOndW for <cfrg@ietfa.amsl.com>; Fri, 17 Oct 2014 09:23:23 -0700 (PDT)
Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7063F1A1BA9 for <cfrg@irtf.org>; Fri, 17 Oct 2014 09:23:23 -0700 (PDT)
Received: by mail-yk0-f179.google.com with SMTP id 200so479571ykr.24 for <cfrg@irtf.org>; Fri, 17 Oct 2014 09:23:22 -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=PmwK3ZP4A5IyAC5RPh3GGpQyfTO8zY9GNWVo0yrKO5I=; b=k5hYXgwupCFkQQgzDmW221yIqcXxIBcvnt14lOzYxnQd1bYi+JCDvpJM1cLC6NhHYH 51RSmUfWXuiIJsR18ZGbm4o3TFmGOdySMELYOBK11pR9TCWlNtiLBO8jzyWFCcP99491 zt3olcf1nktsvOjHGaiRctS2Nn5keSIcHF51u2Sx/cgXr5eV5NoZIpGLuk11AnS49G+6 NaXKUc7TBUtD+LE0M4/VcUjs7SoJXuivzITia1I+VbinB+X6GX+ONbQpYWRPdSY+hB8M uoZhq4bLCRcMIMKJNRKioLL/b3BgysMzlbbF/WkmQ+yOlNEbenO9acvwaJ58a0l66/hq LG9Q==
MIME-Version: 1.0
X-Received: by 10.236.22.37 with SMTP id s25mr5681426yhs.138.1413563002690; Fri, 17 Oct 2014 09:23:22 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Fri, 17 Oct 2014 09:23:22 -0700 (PDT)
In-Reply-To: <0FC829CD89DE224E98637A5D757BC1B81F02460A@GSBEEX01.int.gematik.de>
References: <D065A817.30406%kenny.paterson@rhul.ac.uk> <543FF1A7.8030908@secunet.com> <544002AF.1020107@akr.io> <5440DFA7.80208@secunet.com> <20141017094755.GA29915@LK-Perkele-VII> <0FC829CD89DE224E98637A5D757BC1B81F02460A@GSBEEX01.int.gematik.de>
Date: Fri, 17 Oct 2014 09:23:22 -0700
Message-ID: <CACsn0ckL=oSdy8Dos3ZaE505nQxz+7fTnVVjJdfdM6=H0wy+Tw@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "Hallof, Andreas" <Andreas.Hallof@gematik.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/j_9S8H08Fl194iDiGq764lfRRdU
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] ECC reboot (Was: When's the decision?)
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: Fri, 17 Oct 2014 16:23:25 -0000

On Fri, Oct 17, 2014 at 9:13 AM, Hallof, Andreas
<Andreas.Hallof@gematik.de> wrote:
>> And what's wrong with just using Brainpool for implementations that need random primes for extended side channel resistance?
> Nothing is wrong about that.
>
> The point that Mr. Merkle is addressing, is that there is a huge world outside PC/Server-based TLS-Authentication.
> I have the impression the current discussion at the cfrg is too narrowly focused on software implementations in unconstrained environments with only global timing SCA.
>
> In the infrastructure surrounding the german eHealth-Card the majority of all TLS-Connection are based on smartcards on one communication-endpoint (the other being a server / non-smartcards).
> The same is true for the smartmeter-infrastructure.
>
> Like it is stated in http://eprint.iacr.org/2014/832 a result of the current discussion at the cfrg could be that there are two sets of curves.
> I have the impression the Brainpool-group would happily accept/(=> switch to) the one set (with random primes), that has the necessary cryptographic properties.
> Thus reducing the implementation-costs at smartcards, Web-browsers, servers etc..

What sort of decision do you think we are going to make? We obviously
cannot remove curves. So Brainpool will remain in TLS. The question is
about curves which make software implementations easier and faster.
Why does hardware matter for the choice we are going to make?

>
>> Performance.
> If a ECDSA-Brainpool-based-signaturecreation cost around 90 ms on a cheap smartcard, it is of little concern to me if it would be 20% faster or slower.
> SCA-resistance is a concern for me.
>
>
> Regards,
>  Andreas Hallof
>
> --
> Andreas Hallof, Datenschutz und Datensicherheit / Kryptographie
>
> -----Ursprüngliche Nachricht-----
> Von: Cfrg [mailto:cfrg-bounces@irtf.org] Im Auftrag von Ilari Liusvaara
> Gesendet: Freitag, 17. Oktober 2014 11:48
> An: Johannes Merkle
> Cc: cfrg@irtf.org
> Betreff: Re: [Cfrg] ECC reboot (Was: When's the decision?)
>
> On Fri, Oct 17, 2014 at 11:21:43AM +0200, Johannes Merkle wrote:
>>
>> Alyssa Rowan wrote on 16.10.2014 19:38:
>> > I can see why they might want that, if VPR is the most convenient
>> > for their implementations - but from what I see from the hesitant
>> > adoption of Brainpool in the wider community,
>>
>> this assertion is only true for software implementations. Brainpool
>> curves are used by more than 50 million smart cards rolled out and
>> several vpn solutions (e.g., based on IPSec) widely used within German
>> and EU public authorities.
>
> And what's wrong with just using Brainpool for implementations that need random primes for extended side channel resistance? Not rigid enough? Not standard enough?
>
>
> For software implementations only needing defenses against software attack (including attacks from different process in the same host/VM) there is plenty wrong with using Brainpool.
>
> If attacker can get enough access to pull off EM attacks against most of the endpoints, one has more severe problems than software vulernable to EM attack.
>
> There is a good reason (singular!) why NIST/NSA curves are used far far more in TLS than Brainpool, despite there being codepoints for both:
> Performance.
>
>
> -Ilari
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg
>
> _______________________________________________
> 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