Re: [Cfrg] Thoughts on a Next-Generation Elliptic Curve Signature Scheme?

[Robert Ransom <[e-mail]>]

On 1/11/14, Alyssa Rowan <[e-mail]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> At some point, clearly we're going to need a signature scheme for
> these "Chicago curves" specified in SafeCurves, for later use to
> replace ECDSA with something which is a more convenient fit for them
> and doesn't want random numbers for each signature, for future use in
> certificates, authentication, and the like.
>
> I feel like now would be a good point, hence this request for ideas.
>
> On 11/01/2014 17:40, Robert Ransom wrote:
>> Dr. Bernstein's EdDSA is even worse: it prohibits every curve that
>>  Dr. Bernstein himself has specified since Curve25519.
>
> EdDSA seem like a pretty good start for a new signature scheme to me,
> even if as it stands I think it's closely tied to Ed25519 itself
> (basically, due to the size and construction?).

EdDSA specifies some details that are irrelevant to how the signature
scheme works: it specifies that the coordinate field's order must be
congruent to 5 mod 8, and it specifies that the curve group must have
cofactor 8 (cofactor 4 is possible even mod 2^255 - 19, e.g. a=-1,
d=446 if I'm retyping it correctly).


> Either the Edwards curves or the Edwards isomorphism of one of the
> Montgomery curves would do, although the ones specified as Edwards
> curves would likely be cleaner, particularly Curve1174, Curve3617 and
> E521: in fact, those would be the three I'd plump for, as I think they
> provide three pretty good security/efficiency points.

Please, not Curve1174.  If you don't like Curve25519's awkward
fractional value of Edwards-form d, use the isogenous curve with
a=-1,d=121665 over the same field.


> We're going to need a hash, too. I suggest that we should use one of
> the new hash algorithms that came out of the SHA-3 competition. All
> the finalists have something to recommend them (I really like Skein
> and BLAKE myself):

BLAKE2 is better than BLAKE.

> but the least controversial in my eyes, and so the
> one I'd on consideration suggest, is Keccak, given it was the winner
> and thus has the additional backing of being SHA-3. (I can see ways
> its particular attributes might prove helpful, too.)

Because NSA wants other people to rely on Keccak?  Really?

I can see advantages to using a sponge, but “NSA wants us to eat it”
has never been a good argument.


Robert Ransom