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

"Paterson, Kenny" <> Wed, 20 April 2016 08:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0D70F12DD78; Wed, 20 Apr 2016 01:44:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Jd4aar5ILtU5; Wed, 20 Apr 2016 01:44:07 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fe00::682]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E680212D7BA; Wed, 20 Apr 2016 01:44:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-rhul-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=g7lR2BVhr1ROcXY6xAEq4nBjDSm5FxXwdhmG/YVK95A=; b=ATAFBc8kkaelk4mkFlvbz08gP629lPcaMEvlWCAFasD11+Avolm9XeU4icndntIqXizZKcBg7kkoh5jH+odlo+7KVeEAaMMIUmEFcvwZ5fSyhWkjQ1jexPFVuPqccDkz/PXAIL/frVA9TgkTxCmaHvzEIDSeN4p3ylUBPiCJKoU=
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.1.466.19; Wed, 20 Apr 2016 08:43:50 +0000
Received: from ([]) by ([]) with mapi id 15.01.0466.022; Wed, 20 Apr 2016 08:43:50 +0000
From: "Paterson, Kenny" <>
To: Daniel Kahn Gillmor <>, "" <>, "" <>
Thread-Topic: draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519
Thread-Index: AQHRms27mjB4fMkE2EOrRhA6598tIZ+SnOqA
Date: Wed, 20 Apr 2016 08:43:50 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-ms-office365-filtering-correlation-id: bf883e4b-55f4-493d-4d8b-08d368f7e571
x-microsoft-exchange-diagnostics: 1; VI1PR03MB1824; 5:44bzpYqbkFIhfOphJBz4+8B0Wq1J2n+6AY9vfPDk23zr0Zerzh4NT8tUr4lCyhHF6ZhSxFFpsXS69bf4OD8O9UI2Bd7eeKbzRNszZO6DG4k3vauOWjhIzJG8orPtgSQfiyOse4C02HHzUk7YvHoifilprpjH1dawoG8+/Ye2CVUuwL/2WfWy3oRl2PrNo9tf; 24:HE0RL4xeXHTEcb/Y/5Y9qI6AIV7R6bI6b2c9JcQTt1udzfDuyNSS2phLe/8r3wmKyhGqu2AlMjjp9AbDFFFbJXjVLed//qCCEoTJRiv/sa0=; 7:KO4aQZE+9VIQI66q/+KLTt9LYGppDpShcvjNIzSFIAshF23SEqDXP/BPaI4iKeuQBtQTNxY04tBnykbdYnZOqGhwj1jW4kRAYW5hAVEwNnZYmdj63w1hgkXuakxrj2s9Aioo1th8kI6euSm59C3uFxZdya7DrQj/PziRfbYpy61ojIQsBOc4SB5Wn5tTTZvi0rbgawrxDdR9p6S6VspjQQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR03MB1824;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR03MB1824; BCL:0; PCL:0; RULEID:; SRVR:VI1PR03MB1824;
x-forefront-prvs: 0918748D70
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(53754006)(5004730100002)(122556002)(66066001)(5008740100001)(4326007)(11100500001)(5001770100001)(92566002)(4001350100001)(3280700002)(10400500002)(586003)(102836003)(1096002)(3846002)(6116002)(189998001)(81166005)(74482002)(77096005)(1220700001)(2950100001)(15975445007)(2900100001)(3660700001)(87936001)(54356999)(2906002)(76176999)(50986999)(19580405001)(106116001)(19580395003)(86362001)(2201001)(36756003)(5002640100001)(83506001)(230783001)(561944003)(2501003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR03MB1824;; FPR:; SPF:None; MLV:sfv; LANG:en;
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2016 08:43:50.4053 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB1824
Archived-At: <>
Cc: Ondřej Surý <>, Robert Edmonds <>, Benjamin Kaduk <>, 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 08:44:10 -0000

Hi Daniel,

Your proposal seems to me to be a very sensible idea.

We are quite keen to get draft-irtf-cfrg-eddsa "shipped", as it's needed
elsewhere in IETF and dependencies are building up.

So, @all, let's try to have a quick discussion on the proposal and see if
any reasons emerge for not adopting it.



On 20/04/2016 07:27, "Daniel Kahn Gillmor" <> wrote:

>Hi all--
>in draft-irtf-cfrg-eddsa-05, there is a context label defined for ed448,
>but no such label is defined for ed25519.  (the "context label" is a way
>to provide domain separation between signatures made in different
>contexts, avoiding cross-protocol attacks)
>people seem OK with domain separation for ed448, but we've rejected it
>for ed25519 to achieve backward compatibility with existing signatures,
>and to avoid API changes to existing ed25519 libraries, as discussed in
>threads like [0].
>I wanted to float one final middle-ground proposal that would allow us
>to align the APIs between the two by adding an optional context
>parameter to ed25519/ed25519ph.  If this isn't acceptable, please
>consider instead the proposed additional Security Considerations toward
>the end of this message.
>The proposal for including optional context labels in 25519 is simple:
> * in Table 1: Parameters of Ed25519, change H(x) from "SHA-512(x)" to
>   "SHA-512(context || x)", and change PH(x) to "context || x".
> * change the sentence describing the ph variant that follows the table
>   to:
>    Ed25519ph is the same but with PH being SHA-512(context || x)
>    instead, i.e., the input is hashed using SHA-512 before signing with
>    Ed25519.
>If "context" is unspecified by the user it is treated as the empty
>string and, the result is exactly the same as the current description.
>This is also easy for someone to implement with existing ed25519
>libraries with no API change: just concatenate before signing or
>This would mean that a signature with a context label for 25519 is not
>separated from a signature *without* a context label (a weaker domain
>separation than we're offering in ed448), but it at least provides a
>standard way for protocols that want to make domain-separated signatures
>to do so, which might help us to encourage domain separation in
>standards which contemplate the use of either Ed448 or Ed25519 (their
>abstract APIs are alignable).
>I also think we need some text explaining the difference between the two
>approaches.  If we adopt the above proposal, we could add something like
>this to the Security Considerations or section 10.3 ("Use of contexts"):
>  Note that the domain separation for Ed25519 and Ed25519ph is weaker
>  than the domain separation for Ed448 and Ed448ph in two ways:
>    (a) Signatures that do not use context labels can potentially
>  collide with signatures that use context labels.  This can only be
>  mitigated by never using the same key in multiple domains without
>  having a domain-specific context label for each use.
>    (b) Signature domains that use context labels where one context
>  label is a prefix of the other may also have collisions.  This can be
>  mitigated by always choosing a context labels that consist of
>  printable ASCII characters followed by a single zero-valued octet.
>  This weaker domain separation is accepted in Ed25519 due to widespread
>  existing context-free deployment and the desire to avoid breaking
>  backward compatibility. For Ed448, which is not yet as widely
>  deployed, the dom() function's stronger domain separation guarantees
>  are preferred.
>If we do not adopt the above changes, and leave ed25519 and ed25519ph
>without any attempt at domain separation, we also probably need a bit of
>text explaining why one primitive has domain separation and the other
>does not, probably in either Security Considerations or section 10.3.
>Otherwise, future people reading the draft would need to track down
>messages like those in [0] to understand the asymmetry.
>A proposal for text in this scenario:
>  Note that only Ed448 offers strong domain separation via context
>  labels, while Ed25519 lacks this capability.  This is due to a desire
>  to retain backward compatibility with existing Ed25519 deployments,
>  and to leave the Ed25519 API as simple as possible.
>  If an application or protocol needs domain separation in situations
>  where Ed25519 may be used, a weaker form of domain separation may be
>  had by prepending a context label (fixed octet string) to the message
>  before signing or verifying, using a different context label for each
>  signature domain.  For the prehash variant, prepend the context to the
>  message before pre-hashing.
>  To avoid collisions between domains when using this weaker form of
>  domain separation, context labels should consist of only printable
>  ASCII characters followed by a single-valued octet.
>What do folks think?
>     --dkg
>[0] see for example Ilari's response here to Bryan Ford at Message-Id:
>    and the "On the differences of Ed25519/448 and how it affects a vote
>    on twoshakes-d" thread starting at Message-Id: