Re: [Cfrg] Requirements for curve candidate evaluation update
Watson Ladd <watsonbladd@gmail.com> Wed, 13 August 2014 01:14 UTC
Return-Path: <watsonbladd@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 497701A6F76 for <cfrg@ietfa.amsl.com>; Tue, 12 Aug 2014 18:14:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-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 ZINAk3rdVx5I for <cfrg@ietfa.amsl.com>; Tue, 12 Aug 2014 18:14:19 -0700 (PDT)
Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2DD51A6F74 for <cfrg@ietf.org>; Tue, 12 Aug 2014 18:14:19 -0700 (PDT)
Received: by mail-yh0-f49.google.com with SMTP id b6so8216232yha.8 for <cfrg@ietf.org>; Tue, 12 Aug 2014 18:14:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=q5Klhrp35QrUwBPQraq5AG3eY1JZO34vXjAPIFmFjrM=; b=GTDzyd5feyPkIRuSB9we38XFUy4EJR3hwb3rzCnes3wb9fU5Qc5jI0onPTP2vMndzB ebUwU86zBomTKrkJVvfwv6hI9pEJBqaWVcKSVgZA/9MeHaSiVmqmIe9Kd1m3pWuLLN9q CVH7LnzbzMJG7jzQ+4nVdNe1plSAtKky3D8+WmjCg1eCcEyv9jQSW/X5L/MuLRWL2GWc KRloteCloCIy9xB5SatVQfFgvqKguw1lm1YqcYr5spbIUKDR9kQRSCuSyIJA2ZaVMUdv pgqLheUSBqO4og/7ZOIRbfBHsHHB1K/lhVfxMXd87P8U7erW6aJwfYgf2eh1PiNsXNwy w0lw==
MIME-Version: 1.0
X-Received: by 10.236.97.101 with SMTP id s65mr1799418yhf.51.1407892459048; Tue, 12 Aug 2014 18:14:19 -0700 (PDT)
Received: by 10.170.202.8 with HTTP; Tue, 12 Aug 2014 18:14:18 -0700 (PDT)
In-Reply-To: <CA+Vbu7wuAcmtAKJYEgAaSBTf6sj8pRfYpJhz2qV_ER=33mrk8Q@mail.gmail.com>
References: <CA+Vbu7wuAcmtAKJYEgAaSBTf6sj8pRfYpJhz2qV_ER=33mrk8Q@mail.gmail.com>
Date: Tue, 12 Aug 2014 18:14:18 -0700
Message-ID: <CACsn0cmzixM0zUkb9mHuo8eAYXdCpEr_cdvzuj4AbMG4of8PKg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Benjamin Black <b@b3k.us>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/hsWZHh4Kp7hE4MEVerMNpsdj5ZY
Cc: "cfrg@ietf.org" <cfrg@ietf.org>
Subject: Re: [Cfrg] Requirements for curve candidate evaluation update
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: Wed, 13 Aug 2014 01:14:22 -0000
On Tue, Aug 12, 2014 at 2:58 PM, Benjamin Black <b@b3k.us> wrote: > The CFRG, while part of IRTF, cannot separate itself from the practical > demands of IETF. The CFRG brings a different set of skills to bear, but the > outcome of its work must be pragmatic. The original list of requirements in > the request forwarded by Kenny reflected the required pragmatism in asking > only for new curves based on the 15 years of research and deployment > experience with the NIST curves. Every other aspect of the problem was and > is constrained by the existing RFCs, existing installed base, and existing > customer expectations. > > Returning to the engineering requirements for new curves, the curves must > take into consideration the well-established fact that many implementations > will not be authored by professional cryptographers and almost no users of > systems relying on them will be professional cryptographers. If we require, > rather than allow, multiple curve models be implemented to support different > algorithms or for different security levels, we are increasing complexity > and hence opportunities for security and interoperability errors. If we > require new security levels, we are again working against the existing > protocols, implementation and deployment experience, customer expectations, > even user interfaces. None of these can simply be dismissed because they are > inconvenient. They are the facts on the ground. > > 1. Curves must be generated using a rigid process, and the more rigid the > better. > > 2. The curves we recommend should only require implementation of a single > curve model, which implies: > > a) ECDHE and ECDSA must be supported with a single curve model. > > b) The same curve model must be used for all security levels. This doesn't distinguish among curves. Read DJB's email "curves, coordinates and computations" email. It's a question about what protocols should do: why should we prohibit x-coordinate only exchanges, if protocols see a security or bandwidth benefit to them? > > 3. For the purposes of evaluating candidates, ephemeral in ECDHE means used > exactly once per key exchange. How does this help distinguish between curves? > > 4. The security levels are 128, 192, and 256 bits and each curve will only > be evaluated at one of those levels. Well, this is not what the NIST curves are (P521, not P512). Nor does Curve25519 fit this model, and yet it continues to be adopted, despite being against "existing protocols, implementation and deployment experience, customer expectations, and even user interfaces". Of course, what does evaluation at a level mean? Will people get upset if we give them more security for the same speed? What about the cofactors? Should we complain about those also? > > 5. No changes to coordinate wire formats. Does this mean just Weierstrass? Or is a change to Edwards somehow not a change in the wire format? (Of course this doesn't constrain the curves either) > > The outcome of these is that we need 3 rigidly generated curves in either > short Weierstrass or twisted Edwards form. Anything beyond that should be > addressed at a later point, and should not block progress on this specific > request for new curves. Except the Microsoft curves send points on a twisted Edwards curve with a=-1, and q=3 (4), so aren't complete without using an isogeny and a slower formula. This is a much more serious problem, as it makes implementation quite a bit more complicated. If we assume implementors don't know crypto, then complete formulas are very necessary. Lastly, the requests on the table for TLS and SSH do change the point format and use new algorithms: clearly these facts aren't actually facts. Sincerely, Watson Ladd > > > b > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin
- [Cfrg] Requirements for curve candidate evaluatio… Benjamin Black
- Re: [Cfrg] Requirements for curve candidate evalu… Salz, Rich
- Re: [Cfrg] Requirements for curve candidate evalu… Watson Ladd
- Re: [Cfrg] Requirements for curve candidate evalu… William Whyte
- Re: [Cfrg] Requirements for curve candidate evalu… Mike Hamburg
- Re: [Cfrg] Requirements for curve candidate evalu… Benjamin Black
- Re: [Cfrg] Requirements for curve candidate evalu… Phillip Hallam-Baker
- Re: [Cfrg] Requirements for curve candidate evalu… David Jacobson
- Re: [Cfrg] Requirements for curve candidate evalu… Salz, Rich
- Re: [Cfrg] Requirements for curve candidate evalu… Salz, Rich
- Re: [Cfrg] Requirements for curve candidate evalu… Phillip Hallam-Baker
- Re: [Cfrg] Requirements for curve candidate evalu… Phillip Hallam-Baker
- Re: [Cfrg] Requirements for curve candidate evalu… Benjamin Black
- Re: [Cfrg] Requirements for curve candidate evalu… Benjamin Black
- Re: [Cfrg] Requirements for curve candidate evalu… Alyssa Rowan
- Re: [Cfrg] Requirements for curve candidate evalu… Phillip Hallam-Baker
- Re: [Cfrg] Requirements for curve candidate evalu… Phillip Hallam-Baker
- Re: [Cfrg] Requirements for curve candidate evalu… Alyssa Rowan
- Re: [Cfrg] Requirements for curve candidate evalu… Watson Ladd
- Re: [Cfrg] Requirements for curve candidate evalu… D. J. Bernstein
- Re: [Cfrg] Requirements for curve candidate evalu… Tanja Lange
- Re: [Cfrg] Requirements for curve candidate evalu… Phillip Hallam-Baker