Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Consensus and a way forward]

Alyssa Rowan <> Thu, 27 November 2014 22:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B0E6B1A00B2 for <>; Thu, 27 Nov 2014 14:13:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Jax0WNL9hYpW for <>; Thu, 27 Nov 2014 14:13:26 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 56AAE1A0019 for <>; Thu, 27 Nov 2014 14:13:26 -0800 (PST)
Message-ID: <>
Date: Thu, 27 Nov 2014 22:13:28 +0000
From: Alyssa Rowan <>
MIME-Version: 1.0
To: Alexey Melnikov <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Cc: "" <>
Subject: Re: [Cfrg] draft-black-rpgecc-00-.txt [was: Consensus and a way forward]
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: Thu, 27 Nov 2014 22:13:30 -0000

Hash: SHA512

On 27/11/2014 20:45, Alexey Melnikov wrote:

> While it would be nice to have an open source implementation with
> a liberal license, there is no requirement to have an open source 
> implementation to consider this proposal. And IRTF process doesn't 
> require that either.

Indeed. But given the previous comments about benchmarking, how would
we fairly evaluate it otherwise - and moreover, how attractive would the
resulting proposal actually be to others?

As Adam's pointed out, this proposal has generated something extremely
close to an existing curve that's already on the table. I am not sure
that there is a good clear justification for the only thing
differentiating this proposal from that proposal; I don't currently
think it's an improvement there.

If we added - on the basis of wanting to ensure secure implementations
of many possible things we might use it for (such as ECDH) are as simple
as possible - the pretty reasonable criteria that there should be no
weak keys, it would generate Curve25519, I understand. I would accept
that outcome: and it has been very warmly received by the RG before, I
recall. And then we'd have an equally clear process for a larger curve.
(I bear Mike's comments in mind, of course; it needs discussion.)

If we didn't want to do that, I'd want to be crystal-clear about the
value of why not, and hence why anyone outside would ever want to
choose this proposal above Curve25519. (Because right now, I wouldn't.)

> I don't think asking for a transcript of all such discussions is 
> reasonable. Repeating some of the discussion, in particular in 
> response to clarifying questions might be.

Having reconsidered: perhaps you're right! I simply wish the process to
be as transparently and openly argued as possible, that's all: that is,
after all, the primary value of IRTF making such recommendations, rather
than major players such as Google and Microsoft making them by fiat.

> People should treat the draft as any other contribution to the ECC 
> discussion in the RG.

Indeed; I think it is a very encouraging sign overall, and provides a
very good base narrowing the points (if you'll forgive the pun!) of
technical contention. Hopefully we can converge on curves which are
widely acceptable.

- --