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

Daniel Kahn Gillmor <> Wed, 20 April 2016 15:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0328F12D688; Wed, 20 Apr 2016 08:57:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oYvgEK50NJUx; Wed, 20 Apr 2016 08:57:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AEF7012D528; Wed, 20 Apr 2016 08:57:39 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTPSA id AE085F991; Wed, 20 Apr 2016 11:57:36 -0400 (EDT)
Received: by (Postfix, from userid 1000) id 532911FF1D; Wed, 20 Apr 2016 11:57:36 -0400 (EDT)
From: Daniel Kahn Gillmor <>
To: Ilari Liusvaara <>
In-Reply-To: <>
References: <> <> <> <> <>
User-Agent: Notmuch/0.21+128~g620f892 ( Emacs/24.5.1 (x86_64-pc-linux-gnu)
Date: Wed, 20 Apr 2016 11:57:36 -0400
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Cc: Robert Edmonds <>, "" <>, "" <>, Ondřej Surý <>, "Kaduk, Ben" <>, Martin Thomson <>
Subject: Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Apr 2016 15:57:41 -0000

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.