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

[Alexey Melnikov <[e-mail]>]

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 
>> http://www.ietf.org/id/draft-black-rpgecc-00.txt .
> 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
> SUPERCOP?
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.