IETF Logo Mail Archive

Re: [Cfrg] Recommending secp256k1 in FIPS 186-5

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Fri, 17 January 2020 14:10 UTC

Return-Path: <prvs=8285569969=uri@ll.mit.edu>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745F01200B6 for <cfrg@ietfa.amsl.com>; Fri, 17 Jan 2020 06:10:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.195
X-Spam-Level:
X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 QG7-VFsdDjBh for <cfrg@ietfa.amsl.com>; Fri, 17 Jan 2020 06:10:42 -0800 (PST)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 804DB120074 for <cfrg@irtf.org>; Fri, 17 Jan 2020 06:10:42 -0800 (PST)
Received: from LLE2K16-MBX03.mitll.ad.local (LLE2K16-MBX03.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTPS id 00HEAeav023556; Fri, 17 Jan 2020 09:10:40 -0500
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Christian Lundkvist <christian.lundkvist@consensys.net>
CC: "cfrg@irtf.org" <cfrg@irtf.org>, Oliver Terbu <oliver.terbu@consensys.net>
Thread-Topic: [Cfrg] Recommending secp256k1 in FIPS 186-5
Thread-Index: AQHVtoFYpsHr6TqKxUijjSfFIun+kKfBl4SAgABWxACAAAKNAIAAAvsAgAAFaICAAArcgIAtT5iAgAAS64A=
Date: Fri, 17 Jan 2020 14:10:38 +0000
Message-ID: <B3D1CA8F-E01E-477C-B9D4-55985EA1BA7A@ll.mit.edu>
References: <100b35bb-5ed6-4cca-80ee-5b2dda90fbbf@Spark>
In-Reply-To: <100b35bb-5ed6-4cca-80ee-5b2dda90fbbf@Spark>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
Content-Type: multipart/signed; boundary="Apple-Mail-163737D8-2923-465B-873A-C8737F5076F5"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-17_03:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2001170112
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/T3vw9Khwedd5kaY1AoYi9Ey-lCM>
Subject: Re: [Cfrg] Recommending secp256k1 in FIPS 186-5
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jan 2020 14:10:47 -0000

There were several publications a while ago that described attacks on this type of curves, which I don't have time (or desire) to dig out. Do a search.
There are other reasons as well that I choose not to go into here and now.

Suffices to say that the consensus was - we do not want to support this curve.

You like it - use it. Don't ask us to.

Thanks

Regards,
Uri

> On Jan 17, 2020, at 08:03, Christian Lundkvist <christian.lundkvist@consensys.net> wrote:
> 
> 
> Hi Uri,
> 
> Thanks for your response! As I understand it NIST is considering adopting support for the curve Ed25519. A large part of this is because this curve has seen fairly widespread use in the industry.
> 
> What is the reason you feel that this curve is worth supporting and the curve secp256k1 is not? Is it only due to the relative security considerations of these curves? Can you point us to any specific security weaknesses or exploits of the curve secp256k1 that you feel would make it unsuitable for digital signature use?
> 
> Best regards,
> Christian Lundkvist
>> On Dec 19, 2019, 12:06 -0500, Oliver Terbu <oliver.terbu@consensys.net>, wrote:
>> Looping in Christian who is our cryptographer.
>> 
>> Christian, could you please follow up?
>> 
>> Thanks,
>> Oliver
>> 
>> On Thu, Dec 19, 2019 at 5:27 PM Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu> wrote:
>> Sorry, I've said all I could (in a short email ;).
>> 
>> Regards,
>> Uri
>> 
>> Sent from my iPhone
>> 
>>> On Dec 19, 2019, at 11:09, Dan Burnett <daniel.burnett@consensys.net> wrote:
>>> 
>>> 
>>> Thank you.  Can you say more?  The standard argument of "strongest is best" I already get, but I suspect you have other arguments than that in mind.  I have cc'd Oliver Terbu, who worked on this doc, in case he has more specific questions for you.
>>> 
>>> -- dan
>>> 
>>> 
>>> On Thu, Dec 19, 2019 at 10:57 AM Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu> wrote:
>>> In my humble opinion it is not.
>>> 
>>> Regards,
>>> Uri
>>> 
>>> Sent from my iPhone
>>> 
>>>> On Dec 19, 2019, at 10:49, Dan Burnett <daniel.burnett@consensys.net> wrote:
>>>> 
>>>> 
>>>> Out of politeness I don't want to dump the whole summary into the email, but the brief answer is for products and solutions using Bitcoin, Ethereum, etc.  The question is whether it is strong enough to include, not whether it is weaker than something else.
>>>> 
>>>> -- dan
>>>> 
>>>> 
>>>> On Thu, Dec 19, 2019 at 10:37 AM Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu> wrote:
>>>> Why would I want another curve (secp256k1) that is weaker than the currently used secp256r1?
>>>> 
>>>>  
>>>> 
>>>> From: Cfrg <cfrg-bounces@irtf.org> on behalf of Dan Burnett <daniel.burnett@consensys.net>
>>>> Date: Thursday, December 19, 2019 at 10:31 AM
>>>> To: CFRG <cfrg@irtf.org>
>>>> Subject: [Cfrg] Recommending secp256k1 in FIPS 186-5
>>>> 
>>>>  
>>>> 
>>>> Hello,
>>>> 
>>>>  
>>>> 
>>>> I have been a participant in several IETF Working Groups over the years, most recently RTCWEB (and W3C's WebRTC), but not this RG in particular.  However, I frequently recommend this group as highly knowledgeable when it comes to wise choices in cryptographic recommendations.  I learn something new every time I sit in on this group's sessions at IETF meetings.
>>>> 
>>>>  
>>>> 
>>>> As mentioned in another thread, NIST is seeking feedback on their recently-released draft of FIPS 186-5. [1]
>>>> 
>>>> My company and others are concerned about the lack of endorsement for secp256k1 in this standard and have drafted a request for its addition.[2]  We would welcome any comments and/or support from this group and/or any of its members (directly in the Google Doc linked below).  All comments are welcome, including those arguing against this request :)
>>>> 
>>>>  
>>>> 
>>>> Thanks,
>>>> 
>>>>  
>>>> 
>>>> Dan Burnett
>>>> 
>>>> ConsenSys
>>>> 
>>>>  
>>>> 
>>>> [1] https://www..federalregister.gov/documents/2019/10/31/2019-23742/request-for-comments-on-fips-186-5-and-sp-800-186
>>>> 
>>>> [2] https://docs.google.com/document/d/1wygRHPMGhhanDev7iZSn_AlXw6FZdTK-cIh4fXD77jk/edit#heading=h.1xljt59f35x5
>>>> 
>>>>  
>>>> 
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg

v2.23.0 | Report a Bug | By Email