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

David Jacobson <> Thu, 21 April 2016 05:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9DCF712E97F for <>; Wed, 20 Apr 2016 22:47:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Fe-ZdvFUwW2Z for <>; Wed, 20 Apr 2016 22:47:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DC38C12E985 for <>; Wed, 20 Apr 2016 22:47:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s2048; t=1461217626; bh=ghiRhTeFVkDLz6+fpGbuIwG04vyDTl0aCI1Cy1wUbOQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=JHbTi6eTs+pM9i4yqKZ/lVHd2ABrPKs013t2dL16HAylZ80eJcLgMjdSKiSCrNdAO0ymJtHzihGsONx0hhqvhI1ELAWyJiBszgq4bUTQa1pVJENxJGITO/jNZhnnlUsQVzgdxCHJ9OOZMJuir0naBYv5a9eKmBAHua40MkxKzYufcBQNGiyy0a6nJXB7EuvzuMtUBAapIV728LcUjV0HmwmkYltBX9ykBCB15Ki4xLmQbdDnUN+SFNHxawtzQ6FVgBwAx327HdBFpB+2unshFZX6YvwYk/bVDrTOhbT/Ven/L6Syd7dB9y7rliPECio5ErbBjCKu0dn1vFi5bv2ywA==
Received: from [] by with NNFMP; 21 Apr 2016 05:47:06 -0000
Received: from [] by with NNFMP; 21 Apr 2016 05:47:06 -0000
Received: from [] by with NNFMP; 21 Apr 2016 05:47:06 -0000
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: sygdBa8VM1k1Qr0MGqmd2WFXmU.l1bbfZxQmR9Wsn_3eRB3 OT7l6R10fH2UPMQUOdRQJH3KXy6g4z9MGFIZhw6mLqNHjT0IPM2IPzzFs0HE GGbyBwGv.cyk2egeOpyKdYV_2neW1Hqai1nkFLTR4rQDjcebH3NXqcD3fjv6 kPtACt_rA_sBsWOfZj1sDxz6uHTwnASsBiQSK3wBL_2y2Sgc.5LQYDwNOv7K BaJkujvryxcfyQcG_Or3tX349vNrVYcYmuSox1AbYAbzCprklMoAVylaxufV QKhxecUkPhVLm.b6jlR8FPHA_9EXEV5U59LzkjR7J4oXGn8yGb422nO9PH5N 7.t9VX98N7wAEPrTeob8UZhT3jtOgOaMXBpaY6JDxw8Qj6.xKsldHVkfnhpo CHRL4X02c071JHA_WZo6q.jxpHfQVuNWhaVpR6p7Igvws41r_fQlMcYztjpS 4Y7VRFD8xedKR1XYbhzT6szyTposkFhpsVt05CxIbaBvXgdBdlRntSVfjkuJ W5GpYGa5m6W5cElR9OJzFAcZ8Yf.bUE9Z1yZYK7Lnnz2Z.iitwn4xydcU
X-Yahoo-SMTP: nOrmCa6swBAE50FabWnlVFUpgFVJ9Gbi__8U5mpvhtQq7tTV1g--
To: Benjamin Kaduk <kaduk@MIT.EDU>, "D. J. Bernstein" <>
References: <> <> <>
From: David Jacobson <>
Message-ID: <>
Date: Wed, 20 Apr 2016 22:47:04 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
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: Thu, 21 Apr 2016 05:47:08 -0000

On 4/20/16 4:38 PM, Benjamin Kaduk wrote:
> On Wed, 20 Apr 2016, Daniel Kahn Gillmor wrote:
>> On Wed 2016-04-20 16:51:20 -0400, D. J. Bernstein wrote:
>>>        * More to the point, how is this supposed to be better than having
>>>          the application sign a more informative message, using the
>>>          traditional concept of a signature system?
>> "more informative" assumes that you know exactly how any bytestring is
>> going to be interpreted in every other context.
> To perhaps step back a bit, a signature scheme taking an optional context
> label input with specified semantics (i.e., the label is prepended,
> recommended to end with a NUL byte, etc.) is a way to strongly suggest
> that application protocols using that signature scheme provide such "more
> informative message"s, and gives guidance as to what the structure of the
> more informative message could be.

If you want to include a NUL byte to separate the context from the 
following stuff, then to avoid ambiguity you need to require that the 
context not contain any NUL bytes.   And this rules out general binary 
blobs as context values, including general ASN.1 objects.

NIST Special Publication 800-108 (about key derivation functions) made 
this mistake.  Even though Section 7.4 requires a 1-to-1 mapping from 
inputs to the internal blob send to the PRF, the constructs used in 
Section 5 does not achieve that requirement when the label is allowed to 
be an object that contains a NUL byte.

> I don't really care if the application protocol makes its message being
> signed more informative (i.e., specific to the particular protocol message
> at hand) by manually putting that data at the front of its signing input
> and ignoring the context input, or by using the context input.  I just
> want it to happen, since that improves the overall safety of the internet.
>> If we define a standard way that a signature or key derivation domain
>> can distinguish itself from any other domain, then we can avoid
>> cross-protocol attacks for every scheme that adopts this standard.
>> Without it, each protocol will define how it thinks it should structure
>> a message that is "informative enough" to be distinct from every other
>> signed message in every other protocol -- but how will this be
>> determined without cross-protocol coordination?  This mechanism offers a
>> means for cross-protocol coordination by selection of distinct context
>> strings.  (for signature schemes like Ed448 that aren't using the
>> prefix-approach, the only requirement is context string uniqueness,
>> since they are prefix-resistant)
> Having a contetx input to newly specified signature schemes (and a
> registry to ensure global prefix-uniqueness, which dkg and Martin and I
> are working on a draft for) is a way to help protocol designers that
> aren't cryptographers do the right thing, cryptographically speaking.
> Perhaps there are better ways to encourage this behavior, but this is the
> best proposal I've seen so far, for this issue.
> -Ben
> _______________________________________________
> Cfrg mailing list