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

David Jacobson <> Sat, 23 April 2016 22:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A0CB712D105 for <>; Sat, 23 Apr 2016 15:28:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 rBH8OHkpN1zR for <>; Sat, 23 Apr 2016 15:28:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2BFFD12D0A1 for <>; Sat, 23 Apr 2016 15:28:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s2048; t=1461450500; bh=dKqM74j2CMrlNfVrdjw9CGqCTDiXCKK9TKVjbJuh7nQ=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=jDEKbn6gaR92cGj/aRqcB6iWnCRjasOwkNqerIUWtALb8pPc/CBpJKYpuoSlDZFjqg3y2y5Ms2gs0AFWU9et823GNOCETrgI/iR3bVvIuzORlaoGCyCqKuDKfubpXluZLw274UH/sLLEyYIMA02zv92gQORlMoLtogU1ay1GVSwcsqsXBlMiQiyXywXIOoG0q3MVT3xB+juCQKy93Yqe/2Rqo/b3/9LHkcfevnjpRXpPoFqxtLaMWqdTk0BKjAYpStOvh3bmsdiL1RjjQGaqPJx8LsHAWS+Y2NWsE5ShHnID7sRgQl5nnEhYM8zXrw7LIAn2AdB2Y/iCnLsniAGtHQ==
Received: from [] by with NNFMP; 23 Apr 2016 22:28:20 -0000
Received: from [] by with NNFMP; 23 Apr 2016 22:28:20 -0000
Received: from [] by with NNFMP; 23 Apr 2016 22:28:20 -0000
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: 4QAtD5gVM1ngoFjCJyZu5vZy65A8n5YdJBgI7ZFzQ1S6jn6 MGSTNlbQLvbjL5KwHT062nqe7zMyhVVlNPhU8hjeDGRZAl9rhSnhR9KneipG 7A2yohgvX2SvLrgv1nBWZqKSBul9EODRR_xq8Jt_EOAi0ldMx.Kz94Lj3OYn 3wpo0RVQ7gJ2wa.fBagnuyqZutuCN_jy_DKG.WBq1U12WAufHpSGDF8QsYdZ XrlXy2.dMd48bN8v2dz02MmXkqkTY7nfoLwhoiXDqvTMeWuUm_LPeCMkxiMT uEugyilNmZGHNZkGfDKwoYY1ot_I9uWIudcEpr3lO8OcwvPE5bqGH3g64kSO cDrwW28NX_Gt0EFTJVhXaMkuO.VTncDzdnn6rCzMRr4CPCrzZ.poD8R.lgvQ IYKDwHBZu11Y_Qw1.bp.HnUEg8wm1hnGrDdXFmdhkPGrRkEeF2GF8I4VFeH7 OoJe583bpdXeJPgPV9lwUb3Cswz9qR9pFM8xEX60mCu7.JeBESvEULADWskI PQJEVSijHxdyr3u0BVjkV5AfFhjs3m.zPTDbuoZyNwWSQ8px6USAC4A6Y
X-Yahoo-SMTP: nOrmCa6swBAE50FabWnlVFUpgFVJ9Gbi__8U5mpvhtQq7tTV1g--
To: Daniel Kahn Gillmor <>, "D. J. Bernstein" <>,
References: <> <>
From: David Jacobson <>
Message-ID: <>
Date: Sat, 23 Apr 2016 15:28:17 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------090802050806020507060702"
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 22:28:22 -0000

On 4/23/16 1:19 PM, Daniel Kahn Gillmor wrote:
> 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
> solve.
> 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.

A second traditional fix is "never use the same key for two different 
purposes".  And if the "general" in DBJ's story can't deal with many 
keys, then use a KDF to derive a key for each purpose from the general's 
key.  You can even have multi-level use of KDFs.  Once can be each 
semantic domain the general uses, and a second level can be for 
protocols (e.g. "PGP"), etc., as deep as you need to go.

This keeps the issue of domain separation independent of encryption APIs 
and algorithms.

     --David Jacobson

> 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,
>       --dkg
> _______________________________________________
> Cfrg mailing list