[Cfrg] Attacker changing tag length in OCB

"Manger, James H" <James.H.Manger@team.telstra.com> Wed, 29 May 2013 00:47 UTC

Return-Path: <James.H.Manger@team.telstra.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 347A511E80DE for <cfrg@ietfa.amsl.com>; Tue, 28 May 2013 17:47:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Level:
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994]
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 0LMedTwalBIq for <cfrg@ietfa.amsl.com>; Tue, 28 May 2013 17:47:20 -0700 (PDT)
Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 183F021F8E49 for <cfrg@ietf.org>; Tue, 28 May 2013 17:47:17 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.87,761,1363093200"; d="scan'208";a="137831739"
Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipoavi.tcif.telstra.com.au with ESMTP; 29 May 2013 10:47:16 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,7089"; a="134697510"
Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcdvi.tcif.telstra.com.au with ESMTP; 29 May 2013 10:47:16 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Wed, 29 May 2013 10:47:16 +1000
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: "cfrg@ietf.org" <cfrg@ietf.org>
Date: Wed, 29 May 2013 10:47:15 +1000
Thread-Topic: Attacker changing tag length in OCB
Thread-Index: Ac5bv5nsd2oIgHIyQaiLIm+rOMVW4QAPJSKg
Message-ID: <255B9BB34FB7D647A506DC292726F6E1151AC7071C@WSMSG3153V.srv.dir.telstra.com>
References: <20130528162226.1401.91015.idtracker@ietfa.amsl.com>
In-Reply-To: <20130528162226.1401.91015.idtracker@ietfa.amsl.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: [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: Wed, 29 May 2013 00:47:29 -0000

> 	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.

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?

Another consequence is that an attacker wanting to change the additional data (eg from saying "TOP SECRET" to "PUBLIC") while keeping the same plaintext only has to defeat the shortest tag a recipient accepts, regardless of the tag applied by the originator.

Is this ok? It doesn’t feel ok.

Of course if a recipient accepts 64-bit tags an attacker can forge messages with a probability of 2^-64. However, that doesn’t seem to be exactly the same as forging a message with the same plaintext as a message originally authenticated with a 128-bit tag.

Would OCB be better if the algorithms with different tag lengths couldn’t affect each other? Perhaps restricting the nonce to <126 bits (instead of <128 bits) and encoding the tag length in 2 bits.

--
James Manger