Re: [Cfrg] updated Python script for signature proposals

[Dan Brown <[e-mail]>]

> -----Original Message-----
> From: D. J. Bernstein
> 
> Dan Brown sent me an update last week with an implementation of
> "brown_noinverse", which if I understand correctly is his current
proposal. 

[DB] Yes that's my current proposal (modulo the PRF), for small curves, in
response to the poll for avoiding inversion.  For larger curves, I've
recommended SHA-3, but script only has a small curve.

If the CFRG allows non-IUF modes, then my proposal would switch over to
hinput = R + m, in non-IUF mode (i.e. settings where EdDSA uses prehash is
the identity, e.g. in python
  def prehash(m):
    return m)

Question: according to the current python script, eddsa and liusvaara use
SHA256 to prehash.  Wouldn't it preferable to use SHA512 or SHA384 because
of the potentially securer wider pipe (and maybe speed on 64-bit)?  

The script's comments say that prehash is "meant to show clearly how the two
different hashes are used."  So, I am wondering if SHA-256 is your official
preference for IUF mode EdDSA, or if the choice of SHA-256 is _just_ an
expository choice to "clearly" explain the different roles of the hashes.
If your IACR eprint proposal says something different than SHA-256, maybe
the script should match that?  Of course, the prehash is one of many things
that can be worked out in preparing the I-D and RFC.

> I've now updated the script accordingly

[DB]  Thanks so much.

>---sorry for not getting this done sooner:

[DB] No problem at all, no need to apologize!  Indeed, I also delayed
sending you the update.  If preferred, I send updates directly to list?
That would at least save you the trouble.

> 
>    http://ed25519.cr.yp.to/cfrg/signatures.py
> 
> He also started on a split between IUF and non-IUF (with R before m for
his
> non-IUF mode); I haven't tried to integrate this yet.
> 

[DB] I was hoping that all the schemes in your illustrative demo python
script could be IUF split, with three signing functions (init, update,
final). The update function receives all message fragments, and the final
function would produce the signature, while the init function might do
almost nothing.  The verifying functions could also be split, but that's
less important (and perhaps ill-advised being a poor security model, since
partial verification is almost always a bad idea).