Re: [Cfrg] updated Python script for signature proposals

On Wed, Jul 22, 2015 at 1:25 AM, D. J. Bernstein <djb@cr.yp.to> wrote:
> http://ed25519.cr.yp.to/cfrg/signatures.py has various updates. It still
> doesn't have the PRF details for 'brown'. The 128-bit hash and 320-bit
> PRF for 'hamburg' are also wild guesses.
>
> I see that one of the spec bugs---verification failing because of a
> missing negation---has been resolved in Mike's slides the same way as in
> the script, namely computing
>
>    S = (r - inth * a) % l
>
> but I also don't think this is the best resolution. EdDSA's
>
>    S = (r + inth * a) % l
>
> is slightly simpler than subtraction for small implementations, and it's
> trivial to put the minus sign into the public key instead of the scalar.
> EdDSA actually goes a step beyond this, juggling the order of operations
> so that the simplest implementations can avoid all scalar negations and
> all point negations; this seems to require (R,S) signatures rather than
> (h,S) signatures, but it would clearly work as a tweak for all the
> schemes except 'hamburg'.
>
> Another way to simplify the script would be to switch 'ladd' to the
> point encoding used by the other schemes. The point encoding is actually
> underspecified in most proposals, so I just copied the EdDSA encoding;
> but Watson's proposal clearly specifies an extra byte (33 bytes instead
> of 32 for Curve25519) and clearly specifies a comparison to (q-1)/2,
> which is slightly more complicated than extracting the bottom bit of x.
> Does anyone have reasons to deviate from the EdDSA encoding?

I'll switch to EdDSA encoding then.

>
> It's clear that there are some particular issues where the proposals
> have reasons for diverging, but there are some other discrepancies that
> seem to be easily removable distractions.
>
> ---Dan
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.