Re: [Cfrg] A draft merging rpgecc and thecurve25519function.

Brian Smith <> Fri, 02 January 2015 12:04 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 60C4F1A1A22 for <>; Fri, 2 Jan 2015 04:04:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uKw9lwRt2VbX for <>; Fri, 2 Jan 2015 04:04:14 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C2A661A1A04 for <>; Fri, 2 Jan 2015 04:04:13 -0800 (PST)
Received: by with SMTP id uy5so53061554obc.4 for <>; Fri, 02 Jan 2015 04:04:13 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JSX4mps4f/6Nt2bAAbMb6JlbWWPLbI2oz44l2AIJKzw=; b=gFH2crwdnqqBRK+e0Y78qM4D9wZOwJ8l2kD9OJKlQ+3OZavUklO2nGg3aG5JNNGeIR 5Lf+acjfQ7tctOdudEggbpewDXxpNQiKNtF6xQ7dD++TSJNZ5cX5v0/YDA1EIQr0t0C4 lfZUSwBUsTxKYac7ClusFr7utFifItkPcsQFMOtzN9J281lOGRakh8UW6NTimZ8xv2ri e2b6g4a8Ft5A3g/gZAov/GwX/95NvVVtuhnlvO2pZ1WXxBWvfkwT6NnCu5fV5gMEFkiH fXGICYI9vmA5F7fX1znVedzyusTZ9SryyEzTLNhA0hDfBcZEQAb/Z0IZFcTBveSZUdN9 5CwA==
X-Gm-Message-State: ALoCoQkvJIofpS+KEY9kFSwGvR+Yb4JmOamI99gkBURdkHurt+ojmf8iX6ecF2U8DDiwbvrVBv/q
MIME-Version: 1.0
X-Received: by with SMTP id ut8mr17736467obc.11.1420200252874; Fri, 02 Jan 2015 04:04:12 -0800 (PST)
Received: by with HTTP; Fri, 2 Jan 2015 04:04:12 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Fri, 02 Jan 2015 04:04:12 -0800
Message-ID: <>
From: Brian Smith <>
To: Adam Langley <>
Content-Type: text/plain; charset="UTF-8"
Cc: "" <>
Subject: Re: [Cfrg] A draft merging rpgecc and thecurve25519function.
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 02 Jan 2015 12:04:18 -0000

Adam Langley <> wrote:
> I've created an outline for what currently appears (to me) to
> be the only way that we might reach agreement.

As far as Curve25519 is concerned, whether or not agreement is reached
within CFRG seems to not matter any more, because Curve25519 is
already clearly the choice at the 128-bit security level, and it is
also now the default choice if no agreement is reached. It's already
implemented and documented elsewhere so no new CFRG document is even
really needed for it, though it would be nice to have one.

It isn't clear that it is best to restrict the choices in the stronger
security levels to the generation procedure in this document. More
importantly, that isn't something that needs to be decided before
everybody can move forward with Curve25519.

There are a lot of people that don't care much about the curves
stronger than Curve25519 and who don't intend to implement them. The
problem with your suggested approach is that all these people are
likely to join in support of this document in order to ensure
Curve25519 move forward, causing the people that *do* care about the
higher-security curves to get steamrolled, even if they have a
stronger case. In other words, politics would trump technical
arguments. That's bad.

Consequently, CFRG should wrap up the process for Curve25519, and
separately decide what to do at the higher security levels. This would
more likely ensure that the better technical choices are made at the
higher security levels. This makes sense because the urgency for
Curve25519 is notably higher than the urgency for the other security

It does seem reasonable to say that, before a curve that doesn't
result from the generation procedures is chosen at a higher security
level, there should be a clear, strong justification for that choice.
But, I don't think we should exclude the possibility of such a strong
justification existing for some curve(s). Further, I don't think we
should exclude the possibility of the generation procedure being
tweaked again, like when it was tweaked to make Curve25519 fit.