Re: [Cfrg] Side inputs to signature systems, take 2

Daniel Kahn Gillmor <> Sat, 23 April 2016 20:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 34E3A12D558 for <>; Sat, 23 Apr 2016 13:19:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bZ_hC2aAEK3V for <>; Sat, 23 Apr 2016 13:19:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 52EBA12D554 for <>; Sat, 23 Apr 2016 13:19:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id 70749F991; Sat, 23 Apr 2016 16:19:07 -0400 (EDT)
Received: by (Postfix, from userid 1000) id 5599C200E4; Sat, 23 Apr 2016 16:19:07 -0400 (EDT)
From: Daniel Kahn Gillmor <>
To: "D. J. Bernstein" <>,
In-Reply-To: <>
References: <>
User-Agent: Notmuch/0.21+128~g620f892 ( Emacs/24.5.1 (x86_64-pc-linux-gnu)
Date: Sat, 23 Apr 2016 16:19:03 -0400
Message-ID: <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <>
Subject: Re: [Cfrg] Side inputs to signature systems, take 2
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, 23 Apr 2016 20:19:09 -0000

Hi Dan--

On Sat 2016-04-23 08:59:54 -0400, D. J. Bernstein wrote:
>    * The security analysis is almost entirely missing. It's easy to come
>      up with examples where the idea seems to work, but slightly more
>      thought shows many more examples where the idea fails, because it's
>      not directly aimed at the core cross-protocol issue.

This seems to be saying that because domain separation by context labels
doesn't solve all conceivable cross-protocol issues (i agree it does
not) that we should not use it to address those issues that it does

Your PGP example is definitely correct.  The PGP signature would not
prevent collisions of multiple PGP messages with different
interpretations.  However, it *would* prevent a PGP signature from being
replayed as a signature on a TLS certificate verify message from the
same secret key (or a PKINIT message in krb5, etc)

>    * The syntax/layering/API analysis is entirely missing. In every case
>      where the idea is effective, the same benefit is also achieved by a
>      much more traditional fix that _doesn't_ change the signature API,
>      and this traditional fix is much easier from a systems perspective.

i'm assuming that the "traditional fix" is just "incorporate a sane
context-specific bytestring into the message being signed".  And I
agree, it would be great if people did that.  But calling it a
"traditional fix" implies that there is a tradition of doing the right
thing here, and that's been inconsistent at best.

Do you have a better suggestion of how to formalize this practice than
giving protocol designers a place to put a distinct context?  I'd be
happy with other proposals that try to address the same issue.

Thanks for the thoughtful discussion,