Re: [Cfrg] EC signature: next steps

[Simon Josefsson <[e-mail]>]

Den Tue, 1 Sep 2015 18:41:09 +0300
skrev Re: EC signature: next steps:

> On Tue, Sep 01, 2015 at 09:04:22AM +0200, Simon Josefsson wrote:
> > Ilari Liusvaara <[e-mail]> writes:
> > 
> > > On Mon, Aug 31, 2015 at 03:06:43PM +0200, Simon Josefsson wrote:
> > >> Alexey Melnikov <[e-mail]> writes:
> > >> 
> > >> > - are there errors of fact or omission that need to be
> > >> > corrected?
> > >> 
> > >> 1) I don't understand by this part of Ilari's writeup: 'dictated
> > >> by ???'.
> > >
> > > I earlier tought that the prehash comes from the key, but then
> > > read comment by DJB stating that this is not the case.
> > 
> > Do you have a reference?  I believe the
> > http://ed25519.cr.yp.to/eddsa-20150704.pdf paper is clear on this.
> > Simply explained, the prehash is a parameter of the signature
> > system.
> 
> So it is denoted in the key (since signature system parameters need to
> be fixed by the key) after all?

I don't understand what you mean by "denoted in the key"?  The encoding
of the public key does not contain the prehash OID or anything similar,
if that is what you refer to.

The prehash is a parameter of the signature system, similar to many
other parameters (curve, base point, encodings, etc).  A key is only
valid for a particular signature system, unless some other (likely
higher level) protocol or mechanism specify how it could safely be used
with another signature system.

> > > As for personalization, the problem is that protocols A and B (or
> > > even just different versions of the same protocol!) can interpret
> > > the same message in rather different ways.
> > 
> > Do you have a concrete example?  I would consider that a protocol
> > flaw.
> 
> The problem is that each protocol or version might be reasonable
> alone, but still interact badly.
> 
> The worst are "challenge signing" protocols. One could argue that is a
> design flaw, but that kind of construct is used because it is simple.

Are there any IETF protocols like that?  I'm not sure if this is an
imaginary or real problem.  The traditional solution is to use one key
per protocol anyway.

> > >> 3) What is NPOT?
> > >
> > > (Order) Near Power Of Two. The difference of order and nearest
> > > power of two is on order of sqrt(l).
> > >
> > > Such orders produce even distributions of x mod l, where x is n
> > > bits long with smaller n than usual.
> > >
> > > Both Curve25519 and Curve448 are NPOT. 
> > 
> > How is this relevant to the chose of signature scheme?
> 
> It isn't really relevant.

Then I suggest either that it is dropped from the comparison, or that
its meaning/relevance is clarified.

/Simon