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

[Daniel Kahn Gillmor <[e-mail]>]

On Wed 2016-04-20 10:29:53 -0400, Ilari Liusvaara wrote:
> On Wed, Apr 20, 2016 at 08:51:22AM -0400, Daniel Kahn Gillmor wrote:
>> On Wed 2016-04-20 07:27:00 -0400, Salz, Rich wrote:
>> > This is okay with me, except for one pedantic clarification.  "Empty
>> > string" has a specific meaning in C, it's a single NUL byte.  Since
>> > our other uses of context including the NUL terminator, to avoid
>> > prefix attacks, then I think the wording needs some editing.
>
> Eh, I thought the other uses had length prefixing to avoid prefix attacks?

they do, but we can't have that while still preserving backward
compatibility with the deployed implementations of ed25519, and while
making it relatively easy to use with ed25519 libraries that don't offer
explicit contexts.

If you wanted to do a length-prefixed context, but apply it only in the
case where the context exists (has non-zero length), that's another
option that would preserve backward compatibility with the deployed base.

But i think that's marginally more complicated to reason about and to
implement, and it still doesn't address the potential for collision
between contextualized and context-free domains, so i'm not sure what
we'd gain.

>> the "empty string" message in my message was not part of the proposed
>> wording change to the draft, but i can see how it might be confusing if
>> it were to make it into an edit.
>> 
>> If we need additional clarification in the draft to avoid confusion, i
>> propose:
>> 
>>   If no context label is supplied, it is treated as an octet string of
>>   zero length; that is, (context || x) is the same as x.
>
> Also, anyone up to some quick analysis to show that doesn't interact
> harmfully with Ed25519 when using the same keys?

eh?  this is specifically and only about how to apply a context label in
Ed25519 and Ed25519ph, since it's already defined for Ed448 -- what do
you mean "interact harmfully with Ed25519" ?

> Also, that wouldn't solve the troublesome interaction between Ed25519
> and Ed25519ph...

That's true, this proposal doesn't try to solve that problem.  I hope it
can be evaluated independently.

       --dkg