Re: [Cfrg] Help with the use of contexts

Dan Brown <> Tue, 17 January 2017 17:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1A8301294AC for <>; Tue, 17 Jan 2017 09:24:31 -0800 (PST)
X-Quarantine-ID: <vg8JLG4lMa4T>
X-Virus-Scanned: amavisd-new at
X-Amavis-Alert: BANNED, message contains text/plain,.exe
X-Spam-Flag: NO
X-Spam-Score: -5.8
X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vg8JLG4lMa4T for <>; Tue, 17 Jan 2017 09:24:29 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1E9DD127077 for <>; Tue, 17 Jan 2017 09:24:28 -0800 (PST)
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Jan 2017 12:24:28 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 17 Jan 2017 12:24:27 -0500
Received: from ([fe80::45d:f4fe:6277:5d1b]) by ([fe80::459a:3e96:7706:5ba1%12]) with mapi id 14.03.0319.002; Tue, 17 Jan 2017 12:24:27 -0500
From: Dan Brown <>
To: "D. J. Bernstein" <>, "" <>
Thread-Topic: [Cfrg] Help with the use of contexts
Date: Tue, 17 Jan 2017 17:24:26 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US, en-CA
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Cfrg] Help with the use of contexts
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: Tue, 17 Jan 2017 17:24:31 -0000

I agree with Dan Bernstein's suggestion and reasoning below against CFRG's currently contextualization of signature schemes, though I would also understand if CFRG does not want to reverse its decisions.

Further points:

Protocol designers should be responsible to enforce uniqueness of protocol messages (within and between honest protocols), not just for digital signatures but for all forms of authentication.  How much is this to ask? Isn't that kind of reliability their bread-and-butter?  If there hadn't been non-uniqueness, then cross-protocol attacks would have failed, right?

Adding a context to signatures is a complexity that is (1) not guaranteed to help (no formal security definition, no security proof? And no, I do not volunteer), (2) potentially collides with non-contextualized signatures (must signers now also track whether each non-context signature corresponds to some contextual signature?), (3) blames crypto for too much ;)

-----Original Message-----
From: Cfrg [] On Behalf Of D. J. Bernstein
Sent: Monday, January 16, 2017 3:10 PM
Subject: Re: [Cfrg] Help with the use of contexts

Adam Langley writes:
> The way that this is constructed (due to me) is generic for any 
> signature scheme. (Basically just have the context string be 
> NUL-terminated at the beginning of the signed message.)

In other words, there's still a simple sign-a-message layer that uses the standard signature API, that works with all signature systems, and that minimizes costs for implementors and auditors. On top of this there's a universal

   def sign_a_context_and_data(c,d):
     if '\0' in c: raise Exception('NUL not allowed in contexts')
     return sign(c + '\0' + d)

layer used by the protocol (and by any other protocols that want it).
Everyone can see how this works from a spec perspective and from a software-engineering perspective.

For comparison, trying to modify the interface and specification of every sign() function creates a transition nightmare, with nobody able to answer basic questions about how this approach is actually supposed to work. What's the advantage supposed to be?

I would really like to see this unnecessary complexity eliminated from CFRG's signature specifications. Please see

for further comments.


Cfrg mailing list