[Cfrg] updated Python script for signature proposals

["D. J. Bernstein" <[e-mail]>]

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?

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