[TLS] Koblitz curves [was RE: Curve25519 in TLS]
Dan Brown <dbrown@certicom.com> Thu, 12 September 2013 19:01 UTC
Return-Path: <dbrown@certicom.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07FA811E80F4 for <tls@ietfa.amsl.com>; Thu, 12 Sep 2013 12:01:19 -0700 (PDT)
X-Quarantine-ID: <kbf6f0pH4uMb>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -3.53
X-Spam-Level:
X-Spam-Status: No, score=-3.53 tagged_above=-999 required=5 tests=[AWL=-0.931, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbf6f0pH4uMb for <tls@ietfa.amsl.com>; Thu, 12 Sep 2013 12:01:06 -0700 (PDT)
Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 248CF11E81D2 for <tls@ietf.org>; Thu, 12 Sep 2013 12:00:33 -0700 (PDT)
Content-Type: multipart/mixed; boundary="===============0918104646=="
MIME-Version: 1.0
Received: from xct103cnc.rim.net ([10.65.161.203]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 12 Sep 2013 15:00:15 -0400
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT103CNC.rim.net ([fe80::b8:d5e:26a5:f4d6%17]) with mapi id 14.03.0123.003; Thu, 12 Sep 2013 15:00:14 -0400
From: Dan Brown <dbrown@certicom.com>
To: "'bmoeller@acm.org'" <bmoeller@acm.org>, "'tls@ietf.org'" <tls@ietf.org>
Thread-Topic: Koblitz curves [was RE: [TLS] Curve25519 in TLS]
Thread-Index: AQHOrZh+TZFlKeLBp0isVQ+VLxKJXJm+6ROAgAHgS7KAAYw5gP//2uywgAB2CQD//8J2IA==
Date: Thu, 12 Sep 2013 19:00:14 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF5BCFEEE@XMB116CNC.rim.net>
References: <a84d7bc61003011620i66fc7dfdre62b548fdd5ef7dd@mail.gmail.com> <522D25B9.7010506@funwithsoftware.org> <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au> <87zjrl21wp.fsf_-_@latte.josefsson.org> <522ED9A7.7080802@comodo.com> <87fvtbi8ow.fsf@latte.josefsson.org> <5231B8ED.7040301@comodo.com> <810C31990B57ED40B2062BA10D43FBF5BCFD3C@XMB116CNC.rim.net> <CADMpkcKcjc0JVidPPasuQ4H3SAJG7g8w5LS9z-E2-tyeD3RDmA@mail.gmail.com>
In-Reply-To: <CADMpkcKcjc0JVidPPasuQ4H3SAJG7g8w5LS9z-E2-tyeD3RDmA@mail.gmail.com>
Accept-Language: en-CA, en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.160.250]
MIME-Version: 1.0
Subject: [TLS] Koblitz curves [was RE: Curve25519 in TLS]
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Sep 2013 19:01:19 -0000
Hi Bodo, Aside: maybe discussion like this should move to CFRG, because its generality could affect other WGs, and its theoretical what-if nature may not interest many in TLS WG. For now, I just changed the subject line. To briefly recap: some people hypothesize (a) existence of an undisclosed weak curve classes and (b) authorities pushing curves, via seed searches, into the weak class. Koblitz curves resist (b). You said you do not believe (b). You raised the point again that Koblitz curves may be hit by (a) alone. (I tried to raise this point (a) for Koblitz curves, in the other thread, noting them to be special, just like Curve25519.) I have said before Koblitz curves provide evidence against (b) else: Why place a backdoor on one curve, but not another? My argument was a little vague on this point, so I will try to clarify it first You are quite right that if Koblitz fall to a different version of (a), then (b) would remain viable backdoor mechanism for the VR curves, because now all NIST curves would be weak. This event essentially presumes two undisclosed weak classes of curves (or one, which contains both the Koblitz curves and the all VR curves). In other words, it assumes a larger class of weak curves, so it is more unlikely. It is more far-fetched, albeit only slightly so. And everything here is hypothetical, remember. Ignoring (b) completely is another hypothesis worthy of consideration. In this case, a highly informal argument that Koblitz are less likely than VR curves to be affected by (a) is that the Koblitz curves slightly pre-date the VR curves, and by virtue of their simple coefficients, are more amenable to inspirational analysis. Put another way, the VR curve coefficients are not easy for a person to manipulate. So, any human research efforts could have targeted Koblitz but not VR curves. Also, research efforts just to find arbitrary weak classes of curves could be viewed as unlikely of hitting a VR curve, and thus be viewed as having less incentive (exception: strong believers in (b) would be much more likely to believe in a weak class containing the VR curves). So, it seems, at least to me, the fact that Koblitz have would have been subjected to more effort, or at least more incentive. (Indeed, your intuition, which is that a weak class is more likely to include Koblitz, is an instance of researchers seeing Koblitz curves as more likely target to achieve research success.) From the lack of published attacks, we can infer a lower probability of an undisclosed attack, because there may be a greater number of samples: attempts to discover such a class. But then again, the Suite B VR curves may also received quite a bit of scrutiny too. Best regards, Dan From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Bodo Moeller Sent: Thursday, September 12, 2013 1:42 PM To: tls@ietf.org Subject: Re: [TLS] Curve25519 in TLS > Unless NIST can prove that their curves aren't backdoored, I think it's [DB] Five NIST curves are Koblitz curves, which are not backdoored. Personally I don't expect any of the NIST curves to be backdoored, but I don't agree with the reasoning (which I've seen elsewhere before) that if you have doubts about the pseudorandom NIST urves due to their unexplained seeds, the NIST Koblitz curves are less suspect because that degree of freedom is missing. I won't repeat here why I'm not actually worried about the pseudorandom curves (I don't think I could add anything to your and Douglas Stebila's arguments in the thread "Testing consensus for adding curve25519 to the EC named curve registry"). Now *if* one assumes that there's a (thin-spread but non-negligible) class of weak curves among them (so that the seeds could have been chosen to create backdoors), why would it be more far-fetched to assume that the class of Koblitz curves is weak *in its entirety*? After all, these particular curves are known to have extra structure by design! Bodo
--------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
- [TLS] Testing consensus for adding curve25519 to … Adam Langley
- Re: [TLS] Testing consensus for adding curve25519… Russ Housley
- Re: [TLS] Testing consensus for adding curve25519… Rob P Williams
- Re: [TLS] Testing consensus for adding curve25519… Patrick Pelletier
- Re: [TLS] Testing consensus for adding curve25519… Douglas Stebila
- Re: [TLS] Testing consensus for adding curve25519… Douglas Stebila
- Re: [TLS] Testing consensus for adding curve25519… Nick Mathewson
- [TLS] Curve25519 in TLS Simon Josefsson
- Re: [TLS] Testing consensus for adding curve25519… Nico Williams
- Re: [TLS] Testing consensus for adding curve25519… Douglas Stebila
- Re: [TLS] Testing consensus for adding curve25519… Dan Brown
- Re: [TLS] Curve25519 in TLS Rob Stradling
- Re: [TLS] Testing consensus for adding curve25519… Nick Mathewson
- Re: [TLS] Testing consensus for adding curve25519… Dan Brown
- Re: [TLS] Curve25519 in TLS Simon Josefsson
- Re: [TLS] Testing consensus for adding curve25519… Douglas Stebila
- Re: [TLS] Curve25519 in TLS Kyle Hamilton
- Re: [TLS] Curve25519 in TLS Rob Stradling
- Re: [TLS] Curve25519 in TLS Yoav Nir
- Re: [TLS] Curve25519 in TLS Dan Brown
- Re: [TLS] Curve25519 in TLS Bodo Moeller
- [TLS] Koblitz curves [was RE: Curve25519 in TLS] Dan Brown
- Re: [TLS] Curve25519 in TLS Rob Stradling
- Re: [TLS] Curve25519 in TLS Simon Josefsson
- Re: [TLS] Curve25519 in TLS Rob Stradling
- Re: [TLS] Curve25519 in TLS Nico Williams
- Re: [TLS] Curve25519 in TLS Rob Stradling
- Re: [TLS] Curve25519 in TLS Paul Bakker
- Re: [TLS] Curve25519 in TLS Yoav Nir
- Re: [TLS] Curve25519 in TLS Rob Stradling
- [TLS] Curve25519 in TLS Simon Josefsson
- [TLS] Ed25519 for PKIX Simon Josefsson
- Re: [TLS] Ed25519 for PKIX Adam Langley
- Re: [TLS] Ed25519 for PKIX Simon Josefsson
- Re: [TLS] Curve25519 in TLS Manuel Pégourié-Gonnard
- Re: [TLS] Curve25519 in TLS Martin Rex
- Re: [TLS] Curve25519 in TLS Juho Vähä-Herttua
- Re: [TLS] Curve25519 in TLS Manuel Pégourié-Gonnard
- Re: [TLS] Curve25519 in TLS Watson Ladd
- Re: [TLS] Curve25519 in TLS Manuel Pégourié-Gonnard
- Re: [TLS] Curve25519 in TLS Simon Josefsson
- Re: [TLS] Curve25519 in TLS Martin Rex
- Re: [TLS] Curve25519 in TLS Nico Williams