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

[Stephen Farrell <[e-mail]>]

(Speaking as a random RG participant, not as an IESG member...)

I just had a quick read of that, and while I'm not qualified
to judge all the details this seems like a fine text to me
and also seems to me to meet what I understand are the main
reasonable constraints that folks have expressed.

I'm sure the RG could figure out how to split that text into
multiple documents easily enough when considering how to deal
with other security levels so I don't think Brian's concern
is a showstopper (his concern is one that needs to be dealt
with I agree).

If the chairs were able to determine if the RG had reached
rough consensus on the meaty content of [1], but that there
is still work to be done, then I think we'd have made
significant progress.

Cheers,
S.

[1] https://www.imperialviolet.org/cfrgcurve/cfrgcurve.xml

On 01/01/15 22:00, Adam Langley wrote:
> Since everyone is agreed to within an isogeny of curve25519 at ~128
> bits, and since there's no performance reason to pick one isogeny over
> another (see my mail from yesterday), I've created an outline for what
> currently appears (to me) to be the only way that we might reach
> agreement.
> 
> It takes the generation procedure from draft-black-rpgecc-01,
> generates the resulting curve with p=2^255-19 and then ends up with
> curve25519 by pointing out that there's no difference in security
> between isogenies and motivates it by compatibility with existing
> practice.
> 
> Then it includes draft-turner-thecurve25519function in order to nail
> down the wire-format and describe how to perform ECDH.
> 
> The resulting agglomeration is at
> https://cdn.rawgit.com/agl/cfrgcurve/master/cfrgcurve.xml (requires
> XSLT support in the browser) and https://github.com/agl/cfrgcurve.
> (Although, until there's clarity on whether the outline is viable, the
> details in the draft are unimportant.)
> 
> I have not listed the authors of the two source documents as authors
> yet because that might suggest that they support the result. Instead
> I've made the sources clear in section 1.
> 
> It does not suggest a signature scheme, despite several people
> suggesting that it would be required in recent days, because I don't
> think that we're at that point yet.
> 
> 
> Cheers
> 
> AGL
>