Re: [Cfrg] Formal request from TLS WG to CFRG for new elliptic curves
Nigel Smart <nigel@cs.bris.ac.uk> Sun, 20 July 2014 15:28 UTC
Return-Path: <csnps@bristol.ac.uk>
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 9D37A1B2C57 for <cfrg@ietfa.amsl.com>; Sun, 20 Jul 2014 08:28:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 HvdUw6RbmIlj for <cfrg@ietfa.amsl.com>; Sun, 20 Jul 2014 08:27:58 -0700 (PDT)
Received: from eu1sys200aog123.obsmtp.com (eu1sys200aog123.obsmtp.com [207.126.144.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0921D1B2C56 for <cfrg@irtf.org>; Sun, 20 Jul 2014 08:27:57 -0700 (PDT)
Received: from mail-wi0-f172.google.com ([209.85.212.172]) (using TLSv1) by eu1sys200aob123.postini.com ([207.126.147.11]) with SMTP ID DSNKU8vf+j+KMMFEkbYfZOgXjEhuLVzkFt4q@postini.com; Sun, 20 Jul 2014 15:27:58 UTC
Received: by mail-wi0-f172.google.com with SMTP id n3so2955183wiv.11 for <cfrg@irtf.org>; Sun, 20 Jul 2014 08:27:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:message-id:date:from:user-agent :mime-version:to:subject:content-type:content-transfer-encoding; bh=NNju6jN8MnB3ZIWN9ZvJPuvSdKRZglyx+S5Wd8WT/DY=; b=V47CjlgqfCttudUJxKLDAgEDmQz2gz3lBvUHEvHQmJR1/yFHFMJdG/QxLX4/qOOYVd rNQa+KpHv6NT+O/BvhGGhnziQMOyA+K7LqzPoO8cXyHiG1VDkvJrfrxi6QVcALSDioYj sjgdT12GF/b948wWHiebyOAZynG/GsqICEtgjVEz0euTvGZLC1Li9YBRnL3l6dFnz3yX YMVJC26dAWDE6QiGxZ54nK6nx8wFJp4GcpoyHqO1tAb1+gr+HpP6DnTE4CpFvbV+Ico1 sCVeU2CgkGBmRCcu/8d12TGb+XlICmZnltEshhfCfhqccbwqNgHtUboamsMhW2IV4ABM XOfA==
X-Gm-Message-State: ALoCoQna1aUllgQ9sOZ8p5E+vrfbHX6WcpJpL7xhqpsvHnLXyWSHfECPLfbCqWWo2kQMxTHIAI5mz9SAPGctx8BPVQR02HEAoLVZj6HvGMFoGbJOJdUmaH2Qhxt9u8x1zYdM+YE97v2U
X-Received: by 10.194.91.228 with SMTP id ch4mr14270459wjb.59.1405870074510; Sun, 20 Jul 2014 08:27:54 -0700 (PDT)
X-Received: by 10.194.91.228 with SMTP id ch4mr14270447wjb.59.1405870074399; Sun, 20 Jul 2014 08:27:54 -0700 (PDT)
Received: from [192.168.1.78] (host86-168-27-89.range86-168.btcentralplus.com. [86.168.27.89]) by mx.google.com with ESMTPSA id cx5sm30444329wjb.8.2014.07.20.08.27.53 for <cfrg@irtf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Jul 2014 08:27:53 -0700 (PDT)
Sender: Nigel Smart <csnps@bristol.ac.uk>
Message-ID: <53CBDFF8.5050204@cs.bris.ac.uk>
Date: Sun, 20 Jul 2014 16:27:52 +0100
From: Nigel Smart <nigel@cs.bris.ac.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "cfrg@irtf.org" <cfrg@irtf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/fGzyeDz-m7-o_1VfD1fGyLnFFdc
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 15:28:00 -0000
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] Formal request from TLS WG to CFRG for new… Paterson, Kenny
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Watson Ladd
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Michael Hamburg
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Ben Laurie
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Johannes Merkle
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Watson Ladd
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Michael Hamburg
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Joseph Salowey (jsalowey)
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Andy Lutomirski
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Simon Josefsson
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Dan Harkins
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Benjamin Black
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Benjamin Black
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Benjamin Black
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Igoe, Kevin M.
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Paterson, Kenny
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Joseph Salowey (jsalowey)
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Benjamin Black
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Benjamin Black
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Watson Ladd
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Paterson, Kenny
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Manuel Pégourié-Gonnard
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Nigel Smart
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Salz, Rich
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Tanja Lange
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Michael Hamburg
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Nigel Smart
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Watson Ladd
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Michael Hamburg
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Patrick Longa Pierola
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Brian LaMacchia
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Andrey Jivsov
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Watson Ladd
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Andrey Jivsov
- Re: [Cfrg] Formal request from TLS WG to CFRG for… David McGrew
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Watson Ladd
- Re: [Cfrg] [TLS] Formal request from TLS WG to CF… Salz, Rich
- Re: [Cfrg] Formal request from TLS WG to CFRG for… Joachim Strömbergson
- Re: [Cfrg] [TLS] Formal request from TLS WG to CF… Benjamin Black
- Re: [Cfrg] [TLS] Formal request from TLS WG to CF… Peter Gutmann