Re: [Cfrg] revised requirements for new curves
Adam Langley <agl@imperialviolet.org> Tue, 09 September 2014 20:23 UTC
Return-Path: <alangley@gmail.com>
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 4D9031A010A for <cfrg@ietfa.amsl.com>; Tue, 9 Sep 2014 13:23:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 LufmNyl2zrFo for <cfrg@ietfa.amsl.com>; Tue, 9 Sep 2014 13:23:11 -0700 (PDT)
Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 081151A00FA for <cfrg@irtf.org>; Tue, 9 Sep 2014 13:23:09 -0700 (PDT)
Received: by mail-la0-f47.google.com with SMTP id q1so605151lam.20 for <cfrg@irtf.org>; Tue, 09 Sep 2014 13:23:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=TmF9kXlfw1Gy4iEOaPHTF3+uVpF0zdy7v0Vz8lMbmm0=; b=Z+t9yVF60QPj0X3b6nxvQIq/0WZ2XN883JgSpP5BaMaaPmSrRIHM1mFn3h43pfosNY t+RTd/xhwLFE7zW69ggT/3b/+gp1hOjn58gR1FKnfj9A3cGeXUkXNRM5BZw1xpI1QqNH M2fCIWx9xBuTATBiC2Yuy7JglV1JKVaeJ4lQBroijcwEOsCVwSsv3lcvC8F0JEqZDnD+ k5odDPHm6oEQ36z0tFo3Jedw6kQwrysMA8SYhpgy0M8HmpYZlrGv8iQhSBQr95hVrQjh UXt14PTxPZo62we6dp2IE1FiWXXtd8Vhllugvtq08EkfK0Jcz9gzJMG5L9lk3CtG/ink 1gdA==
MIME-Version: 1.0
X-Received: by 10.112.135.230 with SMTP id pv6mr4522225lbb.105.1410294186771; Tue, 09 Sep 2014 13:23:06 -0700 (PDT)
Sender: alangley@gmail.com
Received: by 10.112.170.37 with HTTP; Tue, 9 Sep 2014 13:23:06 -0700 (PDT)
Date: Tue, 09 Sep 2014 13:23:06 -0700
X-Google-Sender-Auth: BGh18AUVH6V6mk0SK7xKwgoCU3w
Message-ID: <CAMfhd9UaJtcaRurEOtN289ribT7ZH6OUB55or+T1NN6U8jv9Rw@mail.gmail.com>
From: Adam Langley <agl@imperialviolet.org>
To: cfrg@irtf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/Gq6gOSe0mt0Hz_Wou30L806XjqA
Subject: Re: [Cfrg] revised requirements for new 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: Tue, 09 Sep 2014 20:23:13 -0000
(I'm commenting with my Google hat on. I'm on vacation at the moment and haven't circulated this around internally but I believe that this reflects our position. Where I'm less sure I've used "I".) > SE5. Required: each set of curve parameters should be generated by a > well-defined procedure that allows only a limited and quantified amount of > flexibility. If the selected procedure involves the choice of an initial > seed, then the seed will be selected by multiple independent parties using > a procedure having the property that no collusion of all but one or fewer > of the parties can exert any control over the chosen seed. [RC] Although flexibility should be eliminated where possible, we believe that forgoing sensible optimisations because of a fear that someone might know a magic attack on a subset of curves and might be guiding the selection them that would be a mistake. We are not looking for a replacement for P-256 because we seriously worry that the NSA backdoored it. We're looking for a replacement because we think that we can get something much faster and simpler. Past a point, constraining the curve based on that fear isn't valuable to us. > SE6. Required: the selected curves should provide levels of security that > match to a good approximation 128-bit, 192-bit and 256-bit security > levels, as these levels are currently commonly understood in the wider > security community. [NC] We don't want three curves. I'm not completely convinced that we even want two, but two is plausible. For symmetric primitives, matching powers of two makes sense because it fits well with software implementation. For curves that motivation is much weaker. Above the 120ish bit level one is no longer fighting stronger attackers, but hedging against a breakthrough (but not too much of one). Matching 192 or 256 bit security levels is a *misunderstanding* in the wider community, and is thus of the lowest priority. > IP2. Desired: securely, simply and efficiently implementable world-wide in > a patent-free manner. [RC] This is probably a requirement for us, unless the "royalty-free" was legally strong, didn't include registration etc. I cannot specify exactly what we would require in that case because it's not my area. > IN2. Required: minimise work needed to generate suitable OBJECT > IDENTIFIERs for Subject Public Key Information Fields, as defined in RFC > 5480 (PKIX). [C] I don't think that I understand what this means, or rather, I can't imagine how a curve could fail it. By having a name so long that it caused tooling problems perhaps? > IN2. Desired: usable with minimal changes to existing IETF RFCs for CMS, > SSH, IKE, IKEv2, Kerberos PKINIT. [RC] The cost of making a change in these systems is largely fixed. I think that trading off too much to make the change smaller is often a false economy. If the thinking here was to try and reuse ECDSA with new curves for reasons of easy of patching then I think that would be an example of such a false economy. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org
- Re: [Cfrg] revised requirements for new curves Paterson, Kenny
- Re: [Cfrg] revised requirements for new curves William Whyte
- Re: [Cfrg] revised requirements for new curves Manuel Pégourié-Gonnard
- Re: [Cfrg] revised requirements for new curves Phillip Hallam-Baker
- Re: [Cfrg] revised requirements for new curves Stephen Farrell
- Re: [Cfrg] revised requirements for new curves Paterson, Kenny
- Re: [Cfrg] revised requirements for new curves Paterson, Kenny
- Re: [Cfrg] revised requirements for new curves Watson Ladd
- Re: [Cfrg] revised requirements for new curves Paterson, Kenny
- Re: [Cfrg] revised requirements for new curves David Jacobson
- Re: [Cfrg] revised requirements for new curves Manuel Pégourié-Gonnard
- Re: [Cfrg] revised requirements for new curves D. J. Bernstein
- Re: [Cfrg] revised requirements for new curves Michael Hamburg
- Re: [Cfrg] revised requirements for new curves Paterson, Kenny
- Re: [Cfrg] revised requirements for new curves Adam Langley
- Re: [Cfrg] revised requirements for new curves Paterson, Kenny
- Re: [Cfrg] revised requirements for new curves Adam Langley
- Re: [Cfrg] revised requirements for new curves Damien Miller
- Re: [Cfrg] revised requirements for new curves Damien Miller
- Re: [Cfrg] revised requirements for new curves Torsten Schuetze
- Re: [Cfrg] revised requirements for new curves Eric Rescorla
- Re: [Cfrg] revised requirements for new curves Markulf Kohlweiss
- Re: [Cfrg] revised requirements for new curves Phillip Hallam-Baker
- Re: [Cfrg] revised requirements for new curves Alyssa Rowan
- Re: [Cfrg] revised requirements for new curves Michael Hamburg
- Re: [Cfrg] revised requirements for new curves Phillip Hallam-Baker
- Re: [Cfrg] revised requirements for new curves Michael Hamburg
- Re: [Cfrg] revised requirements for new curves Andrey Jivsov
- Re: [Cfrg] revised requirements for new curves Andrey Jivsov