Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519

[Ilari Liusvaara <[e-mail]>]

On Thu, Apr 21, 2016 at 02:30:50PM -0400, Benjamin Kaduk wrote:
> On Thu, 21 Apr 2016, Ilari Liusvaara wrote:
> 
> > On Wed, Apr 20, 2016 at 05:41:28PM -0400, Daniel Kahn Gillmor wrote:
> >
> > H(x)=SHA-512(context||x) without any lengths or separators does not behave
> > that way. It does not have trivially computable collisions (but easily
> > computed ones might still exist, or worse, a way to extract the private key).
> >
> > That is, signature for ('abc','def') is not expected to validate for
> > ('abcd','ef').
> 
> I think I'm confused.  Surely if I set chunk = { 'a', 'b', 'c', 'd', 'e',
> 'f'} containing six octets, then SHA-512(chunk) is the same, whether I
> construct chunk from 'abc','def' or 'abcd','ef'.  So you must be talking
> about something else, but I'm not sure what.

I actually implemented the scheme (modifying the python reference
implementation in the draft (modifying H(x) to be SHA512(context|x)).

- Modified and base scheme generate identical signatures and validate
  identical signatures for empty context (as expected).
- Signature of ('abc','def') is different from signature of ('abcd','ef')
  and does not cross-validate. Nor does either cross-validate with
  ('',abcdef).

> > It is also not possible to compute the result using stock Ed25519 code
> > with any non-empty context.
> 
> Can you be more specific?  Is the complaint just that one would need to
> use a temporary buffer and copy the data to be signed in order to put in
> the prefix?

No. I am saying you can't put in the prefix unless you have Ed25519
implementation modified to support it. Buffering the message won't
help.

> > > With a context label, for every domain that defines a sane context
> > > (e.g. the guidance i suggested of printable-ascii followed by '\0'), we
> > > can rule out inter-domain replay as a successful forgery because no
> > > context will be a prefix of any other context.
> >
> > Also, contexts cause large amount of API problems. And it is very easy
> > to use in spec without understanding the problems, resulting spec that
> > is very annoying to implement.
> 
> >From where I am sitting, it seems like there are two options: does the
> signing API include a context input?  If yes, use that input; if no,
> prepend the context to the message to be signed in my own code.  What am I
> missing?

This does not work.


-Ilari