Re: [Cfrg] Formal request from TLS WG to CFRG for new elliptic curves

Michael Hamburg <mike@shiftleft.org> Sun, 20 July 2014 17:25 UTC

Return-Path: <mike@shiftleft.org>
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 75EAA1B28B8 for <cfrg@ietfa.amsl.com>; Sun, 20 Jul 2014 10:25:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.556
X-Spam-Level: *
X-Spam-Status: No, score=1.556 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.982, SPF_PASS=-0.001] autolearn=no
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 TNKzvz4JmHOl for <cfrg@ietfa.amsl.com>; Sun, 20 Jul 2014 10:25:25 -0700 (PDT)
Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AA171B28AE for <cfrg@irtf.org>; Sun, 20 Jul 2014 10:25:25 -0700 (PDT)
Received: from [192.168.1.124] (unknown [192.168.1.1]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id 1DEE03AA12; Sun, 20 Jul 2014 10:23:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1405877021; bh=Ov67VpDOn0BWVp3HxW1mKrprOavirmbLxE4+a2DOAr8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=EkniTbew7mjWY9L46oonurDQBrCO+RaEbOuM0xCL4B6O4Y15KDQSeISDAeo0bA/qv nmoQ2F2zeK4rhW4ckdsLrfoBYdBv0GEp1QuAB7J3gyN5iUXXOFgwy5Ky8Drdk147sv 6isWmVX4ZrVtYh911KPd0dAIFKYp0WsM5YbTR2B4=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Michael Hamburg <mike@shiftleft.org>
In-Reply-To: <53CBDFF8.5050204@cs.bris.ac.uk>
Date: Sun, 20 Jul 2014 10:25:21 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <0F4DF570-7886-4D0A-8817-DEEF64FBA8A8@shiftleft.org>
References: <53CBDFF8.5050204@cs.bris.ac.uk>
To: Nigel Smart <nigel@cs.bris.ac.uk>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/NF60MQq5mctv3Ft-l1ife6qc7DI
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Formal request from TLS WG to CFRG for new 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: Sun, 20 Jul 2014 17:25:27 -0000

You sound a little bit like you’re trolling us, Nigel.  It’s one thing to say that the marginal security and performance gains of the new curves isn’t worth the complexity of supporting them in TLS.  It’s another to say that every crypto curve should have all the properties that NIST chose for theirs (except 512 bits instead of 521), and that it shouldn’t have any other properties, even twist security.  Do you have any justification for those criteria?

— Mike

On Jul 20, 2014, at 8:27 AM, Nigel Smart <nigel@cs.bris.ac.uk>; wrote:

> Hi
> 
> It seems there is a lot of noise about new types of curves, curvexxxyy this,
> and NUMS that.
> 
> Note the request is for new ELLIPTIC CURVES not elliptic curve PROTOCOLS
> 
> Thus any curve should be IMHO usable with any STANDARD protocol, in any
> STANDARD way of implementing the protocol. Without this constraint one is
> bound to get implementation errors.
> 
>  - Curve25519 is a combined curve/protocol; so is out of scope IMHO. As
>     someone is bound to use the underlying curve with some other protocol
>     and make mistakes.
> 
> Benjamin Black is correct; having new types of this that and the other for
> a marginal security gain, and/or a marginal performance gain is IMHO
> inviting problems.
> 
> Thus the ONLY response in my view as responsible cryptographers is
> to recommend curves which
> 
>   i) Whose data format for point transfer/curve definition is in Weierstrass
>      form
>          - I dont care if some implementation wants to use some super-duper
>            form to do some calculation; the data transfer must enable
>            interoperability.
> ii) Whose group order is prime
>          - Not having prime group order is inviting problems. Thus Edwards
>            curves are out as I am sure they require non-prime group order
> iii) The "b" coordinate should be generated by a hash value on some
>      random string.
> iv) Usual security constraints; base field has 256 and 512 bits of security
>       to match AES 128 and AES 256; MOV criteria; SmartASS criteria;
> v) Ignore "esorteric" constrains like twist security etc.
> 
> So basically I cannot see what is wrong with the NIST curves. And if people
> want something new then they should really come up with a credible
> reason for wanting something new. No argument I have seen warrants
> the massive change in software and infrastructure that is being proposed.
> If people really are that worried about this NIST curves then
>   i) They should probably stop using the internet full stop, as that means
>      the NSA probably has massive more capability than even Snowden has
>      revealed.
>  ii) Generate curves as above; and not trust some new fingle-fangled ideas
>      which are not supported by all the major cryptographers who have
>      worked on ECC.
> 
> BTW I still stand by my statement that we should recommend EC-Schnorr
> as an extra hash function.
>  - Minor change in code needed to support it (compared to some of the other
>    proposals)
>  - Provides some "hedge" against future collisions in SHA-256 and SHA-3.
>  - Has IMHO (and this is purely subjective) better provable security than
>    EC-DSA
> But that is not what we have been asked to comment on; as this is a new
> "protocol" (i.e. signature scheme).
> 
> Yours
> 
> Nigel
> 
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg