Re: [Cfrg] ECC reboot

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Fri, 24 October 2014 11:37 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 707881A8AB5 for <cfrg@ietfa.amsl.com>; Fri, 24 Oct 2014 04:37:26 -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 5cX_tSSgMLG2 for <cfrg@ietfa.amsl.com>; Fri, 24 Oct 2014 04:37:23 -0700 (PDT)
Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6FD51A8993 for <cfrg@irtf.org>; Fri, 24 Oct 2014 04:37:21 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 92CCF1A2648; Fri, 24 Oct 2014 14:37:18 +0300 (EEST)
Date: Fri, 24 Oct 2014 14:37:18 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Alyssa Rowan <akr@akr.io>
Message-ID: <20141024113718.GA21089@LK-Perkele-VII>
References: <54400E9F.5020905@akr.io> <CAMm+LwhVKBfcfrXUKmVXKsiAMRSTV+ws+u07grmxkfnR2oYJoQ@mail.gmail.com> <5218FD35-E00A-413F-ACCB-AA9B99DEF48B@shiftleft.org> <m3r3y6z3z8.fsf@carbon.jhcloos.org> <CA+Vbu7x4Y_=JZ9Ydp=U5QnJokL28QMQnV4XUn9S6+CUZR9ozEw@mail.gmail.com> <5444D89F.5080407@comodo.com> <90C609A5-ECB2-4FDC-9669-5830F3463D2B@akr.io> <5448DBE2.10107@comodo.com> <CACsn0cne95adtTbCf6WyAZGyCSyLXo5L0302rm7238yHAsE5EQ@mail.gmail.com> <54493DB1.5070204@akr.io>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <54493DB1.5070204@akr.io>
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/4sTxHiA9xu9SAw3--ozheX6m-xo
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] ECC reboot
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, 24 Oct 2014 11:37:26 -0000

On Thu, Oct 23, 2014 at 06:41:05PM +0100, Alyssa Rowan wrote:
> 
> On 23/10/2014 15:27, Watson Ladd wrote:
> 
> I echo your concerns about verification performance and secp384r1, but
> that _is_ a particularly ugly baby. We can do better than that, even if
> we pick a curve which is more secure, which is indeed the selling point
> of Curve41417 and/or Ed448-Goldilocks. (I actually wonder how a
> well-optimised E-521 would do, even. I guess we'll find out.)

There's also 416-bit prime equally fast to Ed448 prime (-> ~7% faster
scalarmult for 16 less bits of security).

> Future reference note: May be useful to have state-of-the-art
> implementations of NIST secp256r1, NIST secp384r1, NIST secp521r1 in the
> performance shootout as anchors?

I think definitely so. I would set CPU budget for high curve at secp384r1.

This should give at least ~190 bits of security, possibly >200.

> The way the sign/verify workload is on ECDSA works out well for many
> servers (where sign's the bottleneck) but it's a little unfortunate for
> roots (where verify is).

Simple idea: One could cache CA certificate validations (and also sites
using exceptionally long keys).

There shouldn't be THAT many CA certificates out there in open internet
for that to be a serious storage challenge. And while there are undoubtedly
more in private, one typically does not see very much of those.


> > How long do you think it would take to make an HSM that supports 
> > our choice?
> 
> Depends: from what I've seen a few HSMs are flexible enough to run
> whatever we choose. (I'll refrain from discussion of specific vendors:
> it is for them to speak up if they wish.)
> 
> By the way, as a matter of practicality, would we perhaps be looking at
> some kind of hybrid transition period where existing ECDSA-P384-SHA384
> roots sign (purely by way of example) EdDSA-Curve25519-SHA512 end-entity
> certificates? How would the choice of end-entity algorithms be
> restrained by the signing algorithms and curves used on the roots, or
> not? (I appreciate that may not really be a question for here, but for
> upstream in TLS or PKIX.)

I think this is technically possible (dunno if it is a good idea).

> > Is this a matter of grab an ARM chip, add some custom firmware, 
> > bypass caps, and epoxy (say ~ 6 months), or is it a more involved 
> > process?
> 
> Yes, you _could_ indeed do that. It depends what you want out of it;
> whether that's a _good_ approach is another question entirely. (Epoxy
> doesn't really do a lot of good, by the way! <g>)

E.g. doesn't stop EM attacks. And apparently even if software is hardened
against software attacks, it tends to be rather vulernable to EM attacks.

I would imagine such software would be written to apply heavy blinding,
at great cost for signing time. But such signing doesn't occur that
often.

> > (I'm also unsure of how ECDSA handles cofactors. Will check this)
> 
> I think djb posted about that one?
> 
> Picking a new curve but using an old, relatively-fragile signature
> scheme when we know we could do better and safer now that the Schnorr
> patent expired seems a little silly to me, too. That's a discussion for
> a future date, however.

Heck, there are even older signature schemes that are easier
(no need for private inversion when signing).


-Ilari