Re: [Cfrg] Progress on curve recommendations for TLS WG
"D. J. Bernstein" <djb@cr.yp.to> Sat, 16 August 2014 02:16 UTC
Return-Path: <djb-dsn2-1406711340.7506@cr.yp.to>
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 760BE1A09EF for <cfrg@ietfa.amsl.com>; Fri, 15 Aug 2014 19:16:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.101
X-Spam-Level:
X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, UNPARSEABLE_RELAY=0.001] 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 gO1whN4JEWDk for <cfrg@ietfa.amsl.com>; Fri, 15 Aug 2014 19:16:39 -0700 (PDT)
Received: from mace.cs.uic.edu (mace.cs.uic.edu [131.193.32.224]) by ietfa.amsl.com (Postfix) with SMTP id 1379F1A09E8 for <cfrg@irtf.org>; Fri, 15 Aug 2014 19:16:38 -0700 (PDT)
Received: (qmail 23987 invoked by uid 1011); 16 Aug 2014 02:16:37 -0000
Received: from unknown (unknown) by unknown with QMTP; 16 Aug 2014 02:16:37 -0000
Received: (qmail 28153 invoked by uid 1001); 16 Aug 2014 02:16:27 -0000
Date: Sat, 16 Aug 2014 02:16:27 -0000
Message-ID: <20140816021627.28151.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: cfrg@irtf.org
Mail-Followup-To: cfrg@irtf.org
In-Reply-To: <810C31990B57ED40B2062BA10D43FBF5CCD05A@XMB116CNC.rim.net>
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/UQ3NFIfY5pmRUR6INwK2o591pPo
Subject: Re: [Cfrg] Progress on curve recommendations for TLS WG
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: Sat, 16 Aug 2014 02:16:41 -0000
Less rigidity means a larger collection of curves available for secret selection by the curve generator. This is important in the following scenario, which shouldn't be exaggerated but also shouldn't be ignored: * the curve generator is malicious; * the curve generator knows an attack that the public doesn't know; * some curve in the larger collection is vulnerable to the attack; * no curves in the smaller collection are vulnerable to the attack. A much simpler issue is that any curve, even an honestly generated one, might turn out to be vulnerable to a secret attack. We do _not_ have any way to protect against this---but, again, it's not the same issue. What we _do_ have are ways to stop the curve generator from amplifying a one-in-a-million secret attack into a guaranteed attack. Dan Brown is confusing these two issues when he says that "rigidity alone" does not ensure safety "against secret attacks". One way to achieve a reasonable level of rigidity is to choose the curve that is as _small_ as possible---while obeying public security criteria, obviously. (My experience is that defining "small" as "smallest cost", averaged in any plausible way across platforms, minimizes wiggle room: it's vastly more difficult to reach truly top speed than to merely come close. But that isn't the topic of this message.) What do we know, for various definitions of "small", about the security of taking the smallest curve? Answer: Maybe it's more secure than others. Maybe it's less. We simply don't know. The literature has * examples of attacks where the smallest curve resisting other attacks is _more_ secure than average and * examples of attacks where the smallest curve resisting other attacks is _less_ secure than average. Maybe a secret attack would be of the first type, or maybe it would be of the second type. In a previous message I pointed to seven known examples of the first type (for various notions of smallness) and two known examples of the second type. Koblitz, Koblitz (the co-inventor of ECC), and Menezes wrote a long paper http://eprint.iacr.org/2008/390 with a section devoted to this issue: 11.1. Special or random selection of parameters? A general philosophy one often encounters in cryptography is that whenever possible parameters should be chosen by some random process. If a special choice is made to increase efficiency, there is always the risk that the same property that made the choice so attractive will also lead to vulnerability to an unanticipated attack. [... several pages describing five detailed examples of how special choices can _improve_ security ...] Our purpose in giving these examples is not to lobby for the use of special curves in preference to random ones. Rather, our point is that conventional wisdom may turn out to be wrong and that, as far as anyone knows, either choice has risks. The decision about what kind of curve to use in ECC is a subjective one based on the user's best guess about future vulnerabilities. As frequently happens in cryptography, a close examination of a commonly accepted viewpoint on security issues reveals that opposing opinions or interpretations cannot be ruled out. Much as we might wish to convey to the outside world an impression of self-confidence and mathematical certainty about our recommendations (see Section 2), there is ample reason to wonder whether this self-confidence is justified. Brown keeps claiming, incorrectly, that the risks are entirely on one side. His argument consists of pointing to the well-documented risks on that side (such as MOV, one of the examples I had given) while ignoring the well-documented risks on the other side. ---Dan
- [Cfrg] Progress on curve recommendations for TLS … Paterson, Kenny
- Re: [Cfrg] Progress on curve recommendations for … Watson Ladd
- Re: [Cfrg] Progress on curve recommendations for … Russ Housley
- Re: [Cfrg] Progress on curve recommendations for … D. J. Bernstein
- Re: [Cfrg] Progress on curve recommendations for … Dan Brown
- Re: [Cfrg] Progress on curve recommendations for … Ilari Liusvaara
- Re: [Cfrg] Progress on curve recommendations for … Robert Ransom
- Re: [Cfrg] Progress on curve recommendations for … Johannes Merkle
- Re: [Cfrg] Progress on curve recommendations for … Johannes Merkle
- Re: [Cfrg] Progress on curve recommendations for … Alyssa Rowan
- Re: [Cfrg] Progress on curve recommendations for … Johannes Merkle
- Re: [Cfrg] Progress on curve recommendations for … Watson Ladd
- Re: [Cfrg] Progress on curve recommendations for … Dan Brown
- Re: [Cfrg] Progress on curve recommendations for … Johannes Merkle
- Re: [Cfrg] Progress on curve recommendations for … Watson Ladd
- Re: [Cfrg] Progress on curve recommendations for … Dan Brown
- Re: [Cfrg] Progress on curve recommendations for … Dan Brown
- Re: [Cfrg] Progress on curve recommendations for … Watson Ladd
- Re: [Cfrg] Progress on curve recommendations for … Andy Lutomirski
- Re: [Cfrg] Progress on curve recommendations for … Dan Brown
- Re: [Cfrg] Progress on curve recommendations for … Mike Hamburg
- Re: [Cfrg] Progress on curve recommendations for … Andrey Jivsov
- Re: [Cfrg] Progress on curve recommendations for … Michael Hamburg
- Re: [Cfrg] Progress on curve recommendations for … Watson Ladd
- Re: [Cfrg] Progress on curve recommendations for … D. J. Bernstein
- Re: [Cfrg] Progress on curve recommendations for … D. J. Bernstein
- Re: [Cfrg] Progress on curve recommendations for … Andrey Jivsov
- Re: [Cfrg] Progress on curve recommendations for … Michael Hamburg