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

Alyssa Rowan <> Thu, 27 November 2014 06:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9D8651A888C for <>; Wed, 26 Nov 2014 22:57:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.003
X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4kkXRijRkv3v for <>; Wed, 26 Nov 2014 22:57:55 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E2F9F1A8893 for <>; Wed, 26 Nov 2014 22:57:54 -0800 (PST)
Message-ID: <>
Date: Thu, 27 Nov 2014 06:57:55 +0000
From: Alyssa Rowan <>
MIME-Version: 1.0
To: "" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
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 06:57:56 -0000

Hash: SHA512

On 27/11/2014 04:25, Benjamin Black wrote:

> Over the past couple of weeks we have been working with Adam
> Langley to see if we could find a compromise with which we could
> all live. I'm pleased to say we have been successful in
> accommodating our respective performance and trustworthy generation
> concerns, and I hope the resulting proposal will be attractive to
> others, as well. The generation procedure is document in a draft
> I've just posted that can be found at 
> .

An interesting proposal (of course, not a consensus as Hannes has
pointed out, only a proposal representing a compromise between the

The IPR section in that draft is remarkably short: of course you
cannot patent numbers. (That's copyright's job. <g>) In order to
satisfy IP1 and IP2 requirements we're going to need more information
about the status of specific algorithms on those curves which people
will actually use. As Dan Brown's recent message should highlight, we
should evaluate the patent status and can't ignore it (unless we plan
on ignoring them for long enough that they go away, and in that case,
we need to know when!).

In order to evaluate the performance of simple and secure
implementations of algorithms over these curves, of course we are also
going to need safe, efficient implementations for those algorithms,
ideally available under a liberal licence so stakeholders can actually
use it (specifically I'm afraid Apache 2.0 won't do due to its licence
incompatibilities), which also satisfy our patent concerns. Do you
have such an implementation ready to publish that we can plug into

As this is an exercise in transparency, which is the most important
thing that we hope to differentiate anything we produce from, say, the
NIST curves, kindly disclose onto this list all of the technical
discussions which have produced these compromise in criteria between
the authors (or, in the alternative, hold them here afresh and let's
see if they produce the same consensus). That is a discussion that I
feel should be properly held publicly here, and at the very least,
absolutely requires public documentation for posterity.

I note that if you run your algorithm on 2^521-1 you get E-521. If you
ran it on 2^255-19, why didn't you get the twisted Edwards form of
Curve25519? Kindly elucidate your objections to the same.

- --