Re: [Cfrg] Attacker changing tag length in OCB
Dan Brown <dbrown@certicom.com> Mon, 03 June 2013 16:43 UTC
Return-Path: <prvs=9866dff5e1=dbrown@certicom.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEAEE21F9642 for <cfrg@ietfa.amsl.com>; Mon, 3 Jun 2013 09:43:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ur8GiGKouXhG for <cfrg@ietfa.amsl.com>; Mon, 3 Jun 2013 09:43:09 -0700 (PDT)
Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id D352921F9648 for <cfrg@ietf.org>; Mon, 3 Jun 2013 09:43:03 -0700 (PDT)
X-AuditID: 0a412830-b7fa06d00000178b-d1-51acc7844d8f
Received: from XCT106CNC.rim.net (xct106cnc.rim.net [10.65.161.206]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 33.BE.06027.487CCA15; Mon, 3 Jun 2013 11:42:44 -0500 (CDT)
Received: from XCT111CNC.rim.net (10.65.161.211) by XCT106CNC.rim.net (10.65.161.206) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 3 Jun 2013 12:42:43 -0400
Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT111CNC.rim.net ([::1]) with mapi id 14.02.0328.009; Mon, 3 Jun 2013 12:42:43 -0400
From: Dan Brown <dbrown@certicom.com>
To: "'James.H.Manger@team.telstra.com'" <James.H.Manger@team.telstra.com>, "'cfrg@ietf.org'" <cfrg@ietf.org>
Thread-Topic: Attacker changing tag length in OCB
Thread-Index: AQHOXAYhMmzPOt07Aki0uwqUdA76tJkkLCDA
Date: Mon, 03 Jun 2013 16:42:43 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF518ABAC@XMB111CNC.rim.net>
References: <20130528162226.1401.91015.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E1151AC7071C@WSMSG3153V.srv.dir.telstra.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151AC7071C@WSMSG3153V.srv.dir.telstra.com>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.160.250]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_000E_01CE6057.D75CFDA0"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDJsWRmVeSWpSXmKPExsXC5bjwnG7L8TWBBhvmaVkc3dXGYrH1zitG ByaPJUt+MnnM69jAHMAUJW+TlFhSFpyZnqdvZ5OSmpNZllqEzEqQz7jz/DZrwbz4igmXf7M3 MF4O72Lk4JAQMJHYNVGui5ETyBSTuHBvPRuILSTQziTRs8ali5ELyF7BKLHv7QQWCGc2o8SO 5zuZQarYBFQl7h89B2aLCORJ7OpZxwpiCwsYSHz73s0OETeU2LigFarGSOJ87zGwOIuAisTz tW/AbF4BN4nme3+hFvQxSmy7doERJMEpECGxvK0JrJlRQFZi99nrTCA2s4C4xK0n85kgzhaR eHjxNBuELSrx8vE/VghbUeLEshVsIEOZBXoZJTZNWckEsU1Q4uTMJywQfypIXLm+j2UCo9gs JHNnIeuZhaQHokhb4unNp1C2vMT2t3OYIWxbif1XV0LZihJTuh+yQ9imEq+PfmRcwMixilEw N6PYwMwwOS9ZrygzVy8vtWQTIziONQx2ML5/b3GIUYCDUYmH9/zBNYFCrIllxZW5hxhVgGY8 2rD6AqMUS15+XqqSCG/SbqA0b0piZVVqUX58UWlOavEhxs+MwFCdyCzFnZwPTD55JfHGBgbE ckRhHEMjS3NDSzNjM1MTQ7PBI6wkzssXPClQSCA9sSQ1OzW1ILUI5m0mDs5DjBIcXFIixal5 KalFiaUlGfGgzBBfDMwNUg2MJ8oNM8STDOzeFUcyR112cYsvl7rJ2vHoxq/cE1y31y8+O//h vYyn69f2sioVndDcs+fKhl6TuoPn5p57ezHQZ93MNzaZnNwH0m2/1DXMPv3Pft3sWWcUdffZ LLi56rZ506vJStXdiiIbJupNdI55fGby9we/VeK7/qTVFZocX19y5txxO2eTxUosxRmJhlrM RcWJAHSysK/fAwAA
Subject: Re: [Cfrg] Attacker changing tag length in OCB
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Jun 2013 16:43:13 -0000
More nuanced versions of my answers below (which doubtless overlap with others' answers). By the way, I think this is a good question, and generalizes to beyond OCB. > -----Original Message----- > From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of > Manger, James H > Sent: Tuesday, May 28, 2013 8:47 PM > To: cfrg@ietf.org > Subject: [Cfrg] Attacker changing tag length in OCB > > > Title : The OCB Authenticated-Encryption Algorithm > > Filename : draft-irtf-cfrg-ocb-02.txt > > http://tools.ietf.org/html/draft-irtf-cfrg-ocb-02 > > OCB with tag lengths of 64, 96, and 128 bits are defined. 64-bit and > 96-bit tags are simply truncated 128-bit tags. The tag length is not > mixed into the ciphertext. It never affects any input to an AES > operation. [DB] Theorem 1 of http://www.cs.ucdavis.edu/~rogaway/papers/ae.pdf fixes the tag length. I have not found a proof of security with variable tag lengths. The most cautious approach would to be fix the tag length (per key). Variable tag lengths per key may be useful, but it is crucial to state clearly the security characteristics of this mode. If we cannot state them clearly, then users will not be able to use it right. Perhaps countermeasures can added to that will probably avoid any mixups, but it is still much more important to state what the security characteristics are. > > Consequently, given a valid output from the AEAD_AES_128_OCB_TAGLEN128 > algorithm it is trivial to produce a valid output from the > AEAD_AES_128_OCB_TAGLEN64 algorithm -- just drop the last 8 bytes. > > Is this ok? [DB] On the one hand, informally speaking: Alice did actually send the message, so there is no attack, and this is property of OCB is ok. On the other hand, somebody suggested to me, off-list, an interesting example. Suppose that Bob accept both tag lengths, and treats the messages differently according to tag length. If the tag length is 64, then Bob makes the message public (or perhaps just protect the message less, e.g. store in the cloud). In other words, the tag length itself serves as the associated data, and serves as label, as in James' example below, with 64=Public and 128=Top-secret. I think it is reasonable in the example above for Bob to differentiate his response to a message based on tag length. But I think that the set of allowed actions for longer tags should be larger, not smaller. Better authentication means the message is more trustworthy. The example above is wrong in that a shorter tag allowed more actions (i.e. publish the message). In other words, a system using OCB in this way would be reversing the meaning of authenticity. I think the appeal of the example is the confusion between authenticity and privacy: "Shorter tag? Must be less private. Okay to make public!". If a system (a user of OCB) works in this way, then there is nothing an algorithm like OCB can do to secure it. Therefore, it is much more important to state clearly what authenticity and other security services provided by the algorithm mean, to help prevent the system from going awry. The definitions for OCB are probably clear enough for the fixed tag length, but not yet for variable tag length. Personally, I am still quite confused about the conflict between privacy and authentication: to preserve privacy, Bob should restrict his actions on the received plaintext, but authenticity allows him to take more actions (which could leak information about the message).
- [Cfrg] I-D Action: draft-irtf-cfrg-ocb-02.txt internet-drafts
- [Cfrg] Attacker changing tag length in OCB Manger, James H
- Re: [Cfrg] Attacker changing tag length in OCB Ted Krovetz
- Re: [Cfrg] Attacker changing tag length in OCB Blumenthal, Uri - 0558 - MITLL
- Re: [Cfrg] Attacker changing tag length in OCB Richard Barnes
- Re: [Cfrg] Attacker changing tag length in OCB Igoe, Kevin M.
- Re: [Cfrg] Attacker changing tag length in OCB Rene Struik
- Re: [Cfrg] Attacker changing tag length in OCB Blumenthal, Uri - 0558 - MITLL
- Re: [Cfrg] Attacker changing tag length in OCB David McGrew (mcgrew)
- Re: [Cfrg] Attacker changing tag length in OCB Richard Barnes
- Re: [Cfrg] Attacker changing tag length in OCB Rene Struik
- Re: [Cfrg] Attacker changing tag length in OCB Ted Krovetz
- Re: [Cfrg] Attacker changing tag length in OCB Blumenthal, Uri - 0558 - MITLL
- Re: [Cfrg] Attacker changing tag length in OCB Dan Brown
- Re: [Cfrg] Attacker changing tag length in OCB Manger, James H
- Re: [Cfrg] Attacker changing tag length in OCB Dan Brown