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

Bryan Ford <> Sat, 21 May 2016 09:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6ECC112D0CA; Sat, 21 May 2016 02:43:41 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 N3pUVbsfYsSe; Sat, 21 May 2016 02:43:39 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AA12312B029; Sat, 21 May 2016 02:43:38 -0700 (PDT)
Received: by with SMTP id v200so13212489wmv.0; Sat, 21 May 2016 02:43:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=kj1+3SjcJrrdgfbaVnl7A0Q23A6NzYzmfMckyFoNB0g=; b=e3b5Vtk6WvccGtlt9KGIj5jjisRHQTLmNaCNbVUVZyBXvY3h4aJwtIgL+6EwDHRz0k tligqjuZ5jezKHtRFb2HJT1sN6b5emTz3aaDKMNHaVc1DAO6Oxxww/6M3cXkUc1XKtRd aLsl9UTDyfqgdQiLNcGIAda69XZuYwxho+ENoHl94bWs1bGa97Enn9B8+/EvRkojTQuS oIy9eUiSDjV8EauMt2oB2oasev7/XhNCEoebw7Pjo1J1WfIhmwy89ca8sk+XQ9BYt3BI 40zR0xTOlaIRa53tKEAjFLuvFfTIftNHk3roe/p4zu/FIu00T8vQB+ClKgpvM2PkmiPh bEig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=kj1+3SjcJrrdgfbaVnl7A0Q23A6NzYzmfMckyFoNB0g=; b=dgmdAoJGOvd7y+KcnlUJRM8/uK9th2wiq1iOBI3o/q35QXoxSpfHKTGMLrSTgLiC1o U3nufpENTO2L9cA4TR9CtLGDVmM00Dd7rJW88UVwXCIXPb4l/vRl2NS/uZpwKBzpissi rdDUlLJL8Tw36TdN6sFPqULC4AZ7C3g5dmbIfm5GBq3rtt+sAj9beVsY9/u9qH0lzSiG BdcuzrleAOBDSG1wZ3eWmxRjbukKSXflSXs9aT+TAzdYhUZslCFo6iEF4PJl7ejDbwiW 3e4LdEJxsdqUcNa+S6UgCrnMlLU6WmaNyUsdT4yEGfUzDoH2mg6YCQd32jrFB6VcFKeU bNlg==
X-Gm-Message-State: AOPr4FWSS+Lu8Zha9hYH7tyIL9QMN+lQ3kX0Y8fgMd0v/QtkdJhhobZulwmfSJMHCk7nxA==
X-Received: by with SMTP id hc10mr7316374wjc.71.1463823817117; Sat, 21 May 2016 02:43:37 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id j6sm24146698wjb.29.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 21 May 2016 02:43:35 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_89427D0E-135D-4472-BCF1-BED27EC1E3CC"; protocol="application/pgp-signature"; micalg="pgp-sha256"
X-Pgp-Agent: GPGMail 2.6b2
From: Bryan Ford <>
In-Reply-To: <>
Date: Sat, 21 May 2016 11:43:33 +0200
Message-Id: <>
References: <>
To: Daniel Kahn Gillmor <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Resent-To: <>
Cc: Robert Edmonds <>,,, Ondřej Surý <>, Benjamin Kaduk <>
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: Sat, 21 May 2016 09:43:41 -0000

I see after a long absence that I missed a new flare-up of the Great Context Debate (tm). :)

When I originally proposed the hashing scheme that included contexts for Ed448, I brought up this Ed25519 backward-compatibility issue, and suggested a few alternatives, at least one of which as I recall was similar to DKG’s suggestion.

At any rate, I agree with DKG and others that it would be nice for the RFC to specify a way to deal with an *optional* context parameter for Ed25519 - for consistency with Ed448 if nothing else - while preserving Ed25519 backward compatibility when the context parameter is missing/empty.  No one is forced to use it, but having it in the RFC - and in the APIs of implementations that choose to support it - both makes the RFC more self-consistent and offer a small robustness benefit to new protocols that decide to use contexts.

While the same domain-separation benefit can always be achieved by just prefixing the message, having an explicit context parameter in an API forces the software developer who’s calling that API to see it, and think “do I need to pass something there? what? should I ask a colleague?”  Whereas it’s much easier (essentially trivial) to “forget” to decide to prefix a signed message with something, especially if you’re not a crypto-geek and never heard that you were supposed to.  TLS won’t use contexts, and that’s fine, bit TLS isn’t the relevant “customer” here.  The “customer” is all the possible users of Ed25519 that are *not* nearly so widely-analyzed as TLS.

Yes, key-separation practices are good too, but do not substitute for the domain-separation that contexts can provide, because relying on key-separation exposes message-confusion risks at much higher levels of the “protocol stack” where key management occurs.  If an IETF protocol or proprietary application protocol is designed to use of a context, then any properly-functioning software implementing that protocol will enforce that domain-separation independently of how well or badly users or administrators might manage their keys.  Contexts provide a way for the protocol and software developer to enforce domain separation, whereas key-separation in many environments is something users and administrators have to do.  As others have stated, it’s about redundancy: no one is saying key-separation is bad, but encouraging the use of both reduces the chance of something going critically wrong at *both* levels (protocol design/implementation and key management).

In terms of how exactly to specify a backward-compatible context mechanism for Ed25519, I would certainly support DKG’s specific proposal where context may be empty) as offering a reasonable balance between simplicity and domain-separation goals.  But just to explore a couple slightly different variants with slightly different tradeoffs:

1. DKG’s proposal (baseline): mainly just change H(x) in Table 1 to H(context || x), where context may be empty for backward-compatibility.

2. Change the H(x) line in Table 1 to:

   |    H(x)   | SHA-512(x) [RFC4634] if ctx is empty               |
   |    H(x    | SHA-512(len(ctx) || ctx || x) if ctx is nonempty   |

Advantage: stronger domain separation, ensuring any use that specifies a context is domain-separated from any use that does not.
Downside: slightly more complex specification and code (one ‘if’ statement), though this bit of complexity is hidden from callers of the Ed25519 API.

3. Change the H(x) line in Table 1 to:

   |    H(x)   | SHA-512(len(context)^len(context) || context || x) [RFC4634]    |
…that is, the prefix is L consecutive bytes having value L, where L is the length of the context string, followed by the context and x.  So:

- empty context: H(x) is SHA-512(x)
- context = “foo”: H(x) is SHA-512(“\3\3\3foo” || x)
- context = “blah”: H(x) is SHA-512(“\4\4\4\4blah” || x)

Advantage: eliminates the need for a special-case (the ‘if’ statement) for backward compatibility, while providing the same stronger domain-separation of alternative #2 above.
Downside: doubles the effective size of the context-prefix to process.  But I can’t imagine this mattering in any practical scenario, especially since contexts are expected to be short strings.