[Cfrg] Side inputs to signature systems
"D. J. Bernstein" <djb@cr.yp.to> Tue, 01 September 2015 15:51 UTC
Return-Path: <djb-dsn2-1406711340.7506@cr.yp.to>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214D51B62AD for <cfrg@ietfa.amsl.com>; Tue, 1 Sep 2015 08:51:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.896
X-Spam-Level: **
X-Spam-Status: No, score=2.896 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_NONE=-0.0001, UNPARSEABLE_RELAY=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id feNBbQpDeYe1 for <cfrg@ietfa.amsl.com>; Tue, 1 Sep 2015 08:51:47 -0700 (PDT)
Received: from calvin.win.tue.nl (calvin.win.tue.nl [131.155.70.11]) by ietfa.amsl.com (Postfix) with SMTP id A5E791B6270 for <cfrg@irtf.org>; Tue, 1 Sep 2015 08:51:46 -0700 (PDT)
Received: (qmail 22886 invoked by uid 1017); 1 Sep 2015 15:52:05 -0000
Received: from unknown (unknown) by unknown with QMTP; 1 Sep 2015 15:52:05 -0000
Received: (qmail 20730 invoked by uid 1000); 1 Sep 2015 15:51:35 -0000
Date: Tue, 01 Sep 2015 15:51:35 -0000
Message-ID: <20150901155135.20728.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: cfrg@irtf.org
Mail-Followup-To: cfrg@irtf.org
In-Reply-To: <87vbbu39jd.fsf@latte.josefsson.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/Y5WCbvgwdaEgNxKGg31ZgQ7XInc>
Subject: [Cfrg] Side inputs to signature systems
X-BeenThere: cfrg@mail.ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.mail.ietf.org>
List-Unsubscribe: <https://mail.ietf.org/mailman/options/cfrg>, <mailto:cfrg-request@mail.ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@mail.ietf.org>
List-Help: <mailto:cfrg-request@mail.ietf.org?subject=help>
List-Subscribe: <https://mail.ietf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@mail.ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Sep 2015 15:51:49 -0000
Simon Josefsson writes: > Do you have a concrete example? I would consider that a protocol flaw. It's certainly a protocol flaw---but sometimes designers of multiple protocols, or multiple protocol components, don't talk to each other: * Protocol A: There are two messages, "Put the troops through a surprise drill" and "Don't put the troops through a surprise drill". For efficiency these messages are compressed to "1" and "0" respectively. For security, make sure to check that the compressed message is signed with the General's PGP key. * Protocol B: There are two messages, "Launch the missiles" and "Don't launch the missiles". For efficiency these messages are compressed to "1" and "0". For security, make sure to check that the compressed message is signed with the General's PGP key. Each protocol is safe by itself, but the two protocols together allow forgeries. Here's a fairly recent example of this type of bug in TLS: https://www.cosic.esat.kuleuven.be/publications/article-2216.pdf The standard fix for this type of problem is to encode more information into the signed messages so that they can't be taken out of context. Of course, to figure out how much information is enough, you have to work at the protocol layer, understanding all the different contexts in all of the high-level protocols that might sign messages under the same key---and the protocol designers need to talk to each other! Any encoding, no matter how verbose, can be ruined by another protocol assigning new meanings to some of the encoded messages. Ilari and Mike have both suggested a different approach, feeding extra side inputs into signatures, where these inputs vary from one protocol to another. I have the same questions about these side inputs that I had about William's suggestion to include certificates: * Are cryptographic libraries supposed to change their signature APIs to allow an extra side input? * What exactly are the format and semantics of this input? For example, how exactly would this side input be used to stop the TLS bug mentioned above? * What happens when someone wants to use more of these inputs? * How should libraries handle all of the signature standards that don't support this input? * More to the point, how is this supposed to be better than having the application sign a more informative message, using the traditional concept of a signature system? As I wrote before: The standard signature concept has been stable for decades. It's shared by theoretical papers, signature specifications, attack papers, and software. From this perspective, having a side input to a signature algorithm per se---rather than having it be part of how the higher-level application decides to use signatures---is a severe layering violation. I've seen cases where there's real justification for rethinking the layers in cryptography, but "this application always needs to verify X,Y,Z so signature systems should have X,Y,Z as separate inputs" is obviously a bad argument. ---Dan
- [Cfrg] EC signature: next steps Alexey Melnikov
- Re: [Cfrg] EC signature: next steps Simon Josefsson
- Re: [Cfrg] EC signature: next steps Watson Ladd
- [Cfrg] EC signature: next steps Dan Brown
- Re: [Cfrg] EC signature: next steps Ilari Liusvaara
- Re: [Cfrg] EC signature: next steps Stephen Farrell
- Re: [Cfrg] EC signature: next steps Dan Brown
- Re: [Cfrg] EC signature: next steps Simon Josefsson
- Re: [Cfrg] EC signature: next steps Ilari Liusvaara
- [Cfrg] Side inputs to signature systems D. J. Bernstein
- Re: [Cfrg] Side inputs to signature systems Natanael
- Re: [Cfrg] EC signature: next steps Simon Josefsson
- Re: [Cfrg] Side inputs to signature systems Michael Hamburg
- Re: [Cfrg] EC signature: next steps Rene Struik
- Re: [Cfrg] EC signature: next steps David Jacobson
- Re: [Cfrg] EC signature: next steps Mike Hamburg
- Re: [Cfrg] EC signature: next steps William Whyte
- Re: [Cfrg] EC signature: next steps Stephen Farrell
- Re: [Cfrg] EC signature: next steps Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] EC signature: next steps Ilari Liusvaara
- Re: [Cfrg] EC signature: next steps Stephen Farrell
- Re: [Cfrg] EC signature: next steps Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] EC signature: next steps Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] EC signature: next steps Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] key as message prefix => multi-key sec… Dan Brown
- [Cfrg] key as message prefix => multi-key security D. J. Bernstein
- Re: [Cfrg] key as message prefix => multi-key sec… D. J. Bernstein
- Re: [Cfrg] key as message prefix => multi-key sec… Paterson, Kenny
- Re: [Cfrg] key as message prefix => multi-key sec… Sven Schäge
- Re: [Cfrg] key as message prefix => multi-key sec… Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] key as message prefix => multi-key sec… William Whyte
- Re: [Cfrg] key as message prefix => multi-key sec… Bill Cox
- Re: [Cfrg] key as message prefix => multi-key sec… Andrey Jivsov
- Re: [Cfrg] key as message prefix => multi-key sec… D. J. Bernstein
- Re: [Cfrg] key as message prefix => multi-key sec… D. J. Bernstein
- Re: [Cfrg] key as message prefix => multi-key sec… D. J. Bernstein
- Re: [Cfrg] key as message prefix => multi-key sec… Eike Kiltz
- Re: [Cfrg] key as message prefix => multi-key sec… D. J. Bernstein
- Re: [Cfrg] key as message prefix => multi-key sec… Simon Josefsson