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

Benjamin Kaduk <kaduk@MIT.EDU> Wed, 20 April 2016 23:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 667F412E65A for <>; Wed, 20 Apr 2016 16:38:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.197
X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ayTa4GfZDiET for <>; Wed, 20 Apr 2016 16:38:31 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C512012E24B for <>; Wed, 20 Apr 2016 16:38:31 -0700 (PDT)
X-AuditID: 1209190f-ca3ff70000004b9e-10-571812f6c954
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 35.C5.19358.6F218175; Wed, 20 Apr 2016 19:38:30 -0400 (EDT)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id u3KNcT80030648; Wed, 20 Apr 2016 19:38:30 -0400
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id u3KNcPSe011844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Apr 2016 19:38:28 -0400
Received: (from kaduk@localhost) by ( id u3KNcP0X003295; Wed, 20 Apr 2016 19:38:25 -0400 (EDT)
Date: Wed, 20 Apr 2016 19:38:25 -0400
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: "D. J. Bernstein" <>
In-Reply-To: <>
Message-ID: <>
References: <> <>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBIsWRmVeSWpSXmKPExsUixCmqrftNSCLcYNZ5GYuju9pYLI5+38Ns 0dr9mcmB2aOrN8rjbHc7q8eSJT+ZApijuGxSUnMyy1KL9O0SuDLmHi8quCtUMenjGuYGxm7+ LkYODgkBE4mGPXpdjFwcQgJtTBJX3n9hgXA2Mkos+f2ODcI5xCQx+81+dgingVHi4cRrQGWc HCwC2hJrL69gB7HZBFQkZr7ZyAZiiwDZjydcYAKxmQXsJH6v/cMKYgsLlEicmHsSrIZTwFTi 3PYjLCBn8Ao4SlycXQwSFhKIkrjw9RTYeFEBHYnV+6eA2bwCghInZz5hgRipJbF8+jaWCYwC s5CkZiFJLWBkWsUom5JbpZubmJlTnJqsW5ycmJeXWqRropebWaKXmlK6iREcoJL8OxjnNHgf YhTgYFTi4Q2oFQ8XYk0sK67MPcQoycGkJMr74hdQiC8pP6UyI7E4I76oNCe1+BCjBAezkgjv TQGJcCHelMTKqtSifJiUNAeLkjgvIwMDg5BAemJJanZqakFqEUxWhoNDSYKXCxiJQoJFqemp FWmZOSUIaSYOTpDhPEDDrwiCDC8uSMwtzkyHyJ9iVJQS5y0FSQiAJDJK8+B6wQlkN5PqK0Zx oFeEeSNAVvAAkw9c9yugwUxAg/nvioIMLklESEk1MHpIB61/fVRnCp9Qa3ulQMuFhU4vjZdZ 3DhfP/HPybvl+g/l+TTDpH/V3Nh8Yf+Mk5O+Tbv6pKEqb9WB6RI6+y9KcNnPWuQXw/IgI3aj nCD7sitbFyZ4+mw7OF0qkFH/1Kt7VXds5r5ca7RpxoqZHV9d77tWbEpmYzcTKgswqyl1Udzx UVrXb4YSS3FGoqEWc1FxIgCw6j/m+wIAAA==
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: Wed, 20 Apr 2016 23:38:34 -0000

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.

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.