Re: [Cfrg] CFRG feedback on signing with secp256k1 curve

Dan Brown <danibrown@blackberry.com> Wed, 13 June 2018 13:25 UTC

Return-Path: <danibrown@blackberry.com>
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 8378B130E2C for <cfrg@ietfa.amsl.com>; Wed, 13 Jun 2018 06:25:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 BFHHiuDTtnCh for <cfrg@ietfa.amsl.com>; Wed, 13 Jun 2018 06:25:13 -0700 (PDT)
Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) (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 A206C12D949 for <cfrg@irtf.org>; Wed, 13 Jun 2018 06:25:12 -0700 (PDT)
X-Spoof:
Received: from xct105cnc.rim.net ([10.65.161.205]) by mhs213cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Jun 2018 09:25:09 -0400
Received: from XCT115CNC.rim.net (10.65.161.215) by XCT105CNC.rim.net (10.65.161.205) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 13 Jun 2018 09:25:09 -0400
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT115CNC.rim.net ([::1]) with mapi id 14.03.0319.002; Wed, 13 Jun 2018 09:25:08 -0400
From: Dan Brown <danibrown@blackberry.com>
To: Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>, "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: [Cfrg] CFRG feedback on signing with secp256k1 curve
Thread-Index: AQHUAxny2QDpz7mxiUKj2QQF6lvHhQ==
Date: Wed, 13 Jun 2018 13:25:07 +0000
Message-ID: <20180613132505.8654932.52182.25755@blackberry.com>
References: <MW2PR00MB0300CA51291C5238E7272C52F57F0@MW2PR00MB0300.namprd00.prod.outlook.com>
In-Reply-To: <MW2PR00MB0300CA51291C5238E7272C52F57F0@MW2PR00MB0300.namprd00.prod.outlook.com>
Accept-Language: en-US, en-CA
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_2018061313250586549325218225755blackberrycom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/N-XU09enlfMYEbl3L4IWCM5D8WQ>
Subject: Re: [Cfrg] CFRG feedback on signing with secp256k1 curve
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.26
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: Wed, 13 Jun 2018 13:25:18 -0000

Hi Mike,

Well, secp256k1 has cofactor 1, same as NIST P256. So it does not map to Montgomery or Edwards form, and may be more prone to side channel attacks. Offhand I don't have references, but I think they can be found.

It has also special structure: j-invariant 0 ‎and efficient endomorphism. There is no known attack on ECDLP for this feature, but the consensus is that it may be riskier than a less special curve. Again, I could probably find refs. It is implicit in that NIST did not recommend it.

Gallant-Lambert-Vanstone found a way to speed up Pollard rho attacks on ECDLP given an efficient endomorphism, but the speedup for secp256k1 would be very little, maybe *2, i.e. 1 bit of security, but don't quote me.

Menezes-Okamoto-Vanstone attacked various special curves, including supersingular curves with j=0, but secp256k1 is not affected. Nonetheless, the shared feature of j=0 with an MOV-attacked curve, is an informal red flag, aka early warning sign, aka crack in the concrete.

Indeed, in 1985, Miller suggested using special curves, but also cautioned they could be risky.

Despite the consensus about the risk of special curves, they have been proposed for their other benefits. Pairing curves are special too, but secp256k1 does not have a pairing. Yet others have proposed special curves for their speed. Koblitz, Koblitz and Menezes suggested special curves might better survive a collapse in regular curves.

That all said, I'm not aware of a specific study of secp256k1. If none exist, then it's a bit odd.

Well, I hope that helps. I can try to figure the exact references later.

Best regards,

Dan

From: Mike Jones
Sent: Monday, June 11, 2018 8:03 PM
To: cfrg@irtf.org
Subject: [Cfrg] CFRG feedback on signing with secp256k1 curve


Dear CFRG,

You’ll recall that the “secp256k1” elliptic curve is described by Dan Brown and Certicom in “SEC 2: Recommended Elliptic Curve Domain Parameters” http://www.secg.org/sec2-v2.pdf (the same document that described the secp256r1 curve – a.k.a., P-256).

I recently wrote  https://tools.ietf.org/html/draft-jones-webauthn-secp256k1-00<https://tools.ietf..org/html/draft-jones-webauthn-secp256k1-00> with a very specific and narrow purpose: to register JOSE and COSE curve identifiers for the SECG secp256k1 elliptic curve and associated algorithm identifiers for signing.   This curve is already being used by FIDO UAF, the W3C Verifiable Claims interest group, and several blockchain projects.  I want to get standard identifiers registered so these projects can use standards-based, rather than ad-hoc, cryptographic representations.  A path forward for this document is being discussed at secdispatch@ietf.org<mailto:secdispatch@ietf.org>.

As part of the SECDISPATCH evaluation, Ekr had suggested that I ask the CFRG for references to security analyses of secp256k1.  No matter what you or I may think of Blockchain, because Blockchain is using secp256k1 and is under tremendous scrutiny, it’s my assumption that if major security flaws were known, people would be widely talking about them.  But I’d like to replace my assumption with an actual security analysis or two and thoughts from the CFRG, if possible.

                                                       Thanks,
                                                       -- Mike