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

Alexey Melnikov <> Thu, 27 November 2014 20:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 60E681A01AE for <>; Thu, 27 Nov 2014 12:41:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id esz9U8c28CdD for <>; Thu, 27 Nov 2014 12:41:45 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 144151A0195 for <>; Thu, 27 Nov 2014 12:41:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1417120904;; s=selector;; bh=vfs4BQpJmrv5ohaoN1lR81Zn/3XgTsp9ePRdGDo5XeU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Yb52/92OQAs+eOHNpAqbuCnQncvjWdXJbNFR7zqzQXlZQGlV3xPSKD2uhfQCL6LVzdkv5p /9W2mifcNabiworq2OnskcpAudtCKWcC7nk/8feaBKXZzKgPBB81PX4ZN7GxZqxo+TgP/0 rMrOTPdCyMaGY8ANVNq1cxZObekADvQ=;
Received: from [] ( []) by (submission channel) via TCP with ESMTPSA id <>; Thu, 27 Nov 2014 20:41:44 +0000
X-SMTP-Protocol-Errors: PIPELINING
From: Alexey Melnikov <>
X-Mailer: iPad Mail (12B435)
In-Reply-To: <>
X-Identity-Key: id1
Date: Thu, 27 Nov 2014 20:45:01 +0000
X-Account-Key: account1
X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; DSN=0; uuencode=0; attachmentreminder=0
Message-Id: <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
References: <> <>
To: Alyssa Rowan <>, "" <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=Apple-Mail-29574D59-EDB0-4E4C-A693-08927E93A015
Content-Transfer-Encoding: 7bit
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 20:41:47 -0000

Hi Alyssa,

> On 27/11/2014 06:57, Alyssa Rowan wrote:
>> 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
> authors
Of course. CFRG consensus would be determined by the chairs, after discussion of the proposal.
> ).
> 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
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.
> 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 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. People should treat the draft as any other contribution to the ECC discussion in the RG.

Best Regards,
Alexey, as co-chair
> 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.