Re: [Cfrg] Requirements for curve candidate evaluation update

Watson Ladd <watsonbladd@gmail.com> Thu, 14 August 2014 14:39 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 4EF711A02DE for <cfrg@ietfa.amsl.com>; Thu, 14 Aug 2014 07:39:54 -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 Tl2E_a8BSErB for <cfrg@ietfa.amsl.com>; Thu, 14 Aug 2014 07:39:51 -0700 (PDT)
Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89ACA1A0275 for <cfrg@irtf.org>; Thu, 14 Aug 2014 07:39:51 -0700 (PDT)
Received: by mail-yk0-f177.google.com with SMTP id 79so1016906ykr.8 for <cfrg@irtf.org>; Thu, 14 Aug 2014 07:39:50 -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; bh=J4K6YKj4Xyp5ZvRtj5qBHs5hClYIQ1Pm34uVbSGzCm0=; b=ng7EtZF5O9kVVvoZAuLdW7OB5hsYv/gkwoU6CwwxVl8Rc4w7JL44jnJDNgetRygcdP +Z9Uh12pfMP4uSgXbtGfisK/B9V9KgA7KnMqRav0cqSvUWS3GnOb/SweS/hiaAFRF3nM 8sP/qkScrYS3X4HZY2FdYDXzgOgWM8x9APoVlleFT25jhzMDze8L91UDsTxtgUBVbzrj vI4+HQmr9pVv429jDElein60svaAmw9lvE+zojFMJooM8NTRp63tNF81DRUeT9uePs95 xPv2CJGasQdYOiVz1gdKPVfCWScvtkXV4Imz/pZgVoCOzhR0EbmZ4CZnrmL2LU62yZpK qvfQ==
MIME-Version: 1.0
X-Received: by 10.236.45.10 with SMTP id o10mr17781735yhb.49.1408027190838; Thu, 14 Aug 2014 07:39:50 -0700 (PDT)
Received: by 10.170.202.8 with HTTP; Thu, 14 Aug 2014 07:39:50 -0700 (PDT)
In-Reply-To: <CAMm+Lwh7BAGW6hQfqcDeciYk5nvePwe39Szo0zeCn9hrQLgNBA@mail.gmail.com>
References: <CA+Vbu7wuAcmtAKJYEgAaSBTf6sj8pRfYpJhz2qV_ER=33mrk8Q@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7185A0C8CEB@USMBX1.msg.corp.akamai.com> <CA+Vbu7zfbx-OqU=ggXgutDb+GNwvS3QpkTwzU1c+2Lcv=3Gawg@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7185A0C9094@USMBX1.msg.corp.akamai.com> <CAMm+Lwg8EZ-MWN4hKxzN+g5L9-GjgEGV49NqYNEnK=34qrkb+w@mail.gmail.com> <53EC4DDD.7010503@akr.io> <CAMm+Lwh7BAGW6hQfqcDeciYk5nvePwe39Szo0zeCn9hrQLgNBA@mail.gmail.com>
Date: Thu, 14 Aug 2014 07:39:50 -0700
Message-ID: <CACsn0ckTNqhoff4Lpa2QmD1h+x=Zfwo7Rfm_ALuMCFWkW7duJA@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Phillip Hallam-Baker <phill@hallambaker.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/Xugw6rf6cI6T_kJ5i7SvSeuTWlA
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Requirements for curve candidate evaluation update
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: Thu, 14 Aug 2014 14:39:54 -0000

On Thu, Aug 14, 2014 at 5:26 AM, Phillip Hallam-Baker
<phill@hallambaker.com> wrote:
> On Thu, Aug 14, 2014 at 1:49 AM, Alyssa Rowan <akr@akr.io> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>>
>> On 14/08/2014 03:42, Phillip Hallam-Baker wrote:
>>
>>> To be clear, I am arguing that we put HSM support way ahead of a
>>> single model. HSM support is essential, a single model is
>>> someone's idea of tidiness.
>>
>> That is a null property. Anything we can specify can be implemented in
>> software or hardware. As I said before, there will _eventually_ be new
>> HSMs, and new HSM firmware. People have already begun work on that.
>
> What the constraint means is that if we come down to two curves and
> little to choose between them and there is a significant difference in
> the HSM situation then the curve that allows re-use of existing HSMs
> wins, if neither does that then the curve that has support from HSM
> manufacturers wins.
>
> So folk peddling a curve would do well to line up HSM vendor support.

Let's back up a bit: every curve can be expressed in Weierstrass form
over the same field, so will work with todays ECDSA implementations.
Good? No.

1: Some implementations may have dedicated hardware to do reduction on
the NIST primes
2: Some implementations may assume prime order for correctness
3: Some implementations may not permit the use of arbitrary parameters

So to the extent that we are changing curves, it's not clear that
there is any way, even if we use prime order Weierstrass over the same
primes, to get complete support on HSMs. It's also not clear that
different curves materially differ in this respect.

>
>
> It isn't quite true to say that you can do everything in hardware or
> software. There are very specific constraints here to do with side
> channels and IPR that could have a huge bearing on what curve families
> are viable and which are not.

All the proposals look about the same: if you were to quiz me on which
was which, just showing me the primes and the coefficients, I would
have to do some arithmetic to see if they were complete or not, and so
if they were the NUMS curves or not.

Sincerely,
Watson Ladd

>
>
>> The commercial world of this are however glacially slow-moving, partly
>> due to onerous and ineffective governmental certification requirements
>> (one of the things that has been - rightly - criticised). Several do
>> not support ECDSA (or ECDHE, where applicable) properly or at all, and
>> this is why RSA is still far more common in the wild and ECDSA is
>> quite honestly barely used by anyone publicly (there are _very few_
>> ECDSA PKIX roots...) - those that are using it are running it in
>> software and are therefore not relevant to your 'essential' requirement.
>
> There are very few serious CAs. So its not surprising there are few
> ECC roots. We have ECC roots, so do the other leading CAs. But the
> reason for the lag has been IPR FUD.
>
> _______________________________________________
> 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