Re: [Cfrg] OCB test vectors reusing nonces

"Manger, James" <James.H.Manger@team.telstra.com> Wed, 29 January 2014 01:06 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 (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D59A61A044C for <cfrg@ietfa.amsl.com>; Tue, 28 Jan 2014 17:06:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.202
X-Spam-Level:
X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] 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 XnaLYckxpsRH for <cfrg@ietfa.amsl.com>; Tue, 28 Jan 2014 17:06:25 -0800 (PST)
Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 39C941A02C1 for <cfrg@irtf.org>; Tue, 28 Jan 2014 17:06:24 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.95,739,1384261200"; d="scan'208";a="190890418"
Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipobvi.tcif.telstra.com.au with ESMTP; 29 Jan 2014 12:06:10 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,7332"; a="190471435"
Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipccvi.tcif.telstra.com.au with ESMTP; 29 Jan 2014 12:06:10 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Wed, 29 Jan 2014 12:06:09 +1100
From: "Manger, James" <James.H.Manger@team.telstra.com>
To: Matt Caswell <frodo@baggins.org>
Date: Wed, 29 Jan 2014 12:06:07 +1100
Thread-Topic: [Cfrg] OCB test vectors reusing nonces
Thread-Index: Ac8cfHvJRx8EyEDvTyCkLuz5t2GVbwACl2DQ
Message-ID: <255B9BB34FB7D647A506DC292726F6E1153876A898@WSMSG3153V.srv.dir.telstra.com>
References: <255B9BB34FB7D647A506DC292726F6E1153850CDA3@WSMSG3153V.srv.dir.telstra.com> <6232F83F-A6F5-41C7-8EAD-B60EF8B11165@krovetz.net> <255B9BB34FB7D647A506DC292726F6E11538595640@WSMSG3153V.srv.dir.telstra.com> <5E4A161D-6631-4026-A432-F7C0DC200079@krovetz.net> <255B9BB34FB7D647A506DC292726F6E115386DFD48@WSMSG3153V.srv.dir.telstra.com> <CAMoSCWbdhwgrOLoCZ4PZu4xOz0D_hAS9UXiO+a=JPwiLEzn+uA@mail.gmail.com>
In-Reply-To: <CAMoSCWbdhwgrOLoCZ4PZu4xOz0D_hAS9UXiO+a=JPwiLEzn+uA@mail.gmail.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
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] OCB test vectors reusing nonces
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
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 Jan 2014 01:06:27 -0000

Matt,

> On 28 January 2014 05:21, Manger, James
> <James.H.Manger@team.telstra.com> wrote:
> > Ted,
> >
> > Attached is my version of the updated test vectors for appendix A of
> draft-irtf-cfrg-ocb.
> >
> > The first 16 {N,A,P,C} tuples use incrementing nonces.
> >
> > I added one example with a 96-bit tag and a separate key (since we
> recommend using a single tag length with any given key). It uses the
> same nonce as the 128-bit tag example with the same A and P.
> >
> > The final examples use incrementing nonces.
> >
> > I made minor changes to the text.

> I have successfully managed to verify all of these proposed test
> vectors with my implementation of OCB.

Great!

> However, I understood that one of your objectives for proposing a
> change to the test vectors was to not reuse the same key and nonce
> within the tests. This objective has not been achieved in the final
> set of 9 more complex tests. Whilst you have incremented the nonce
> between each encryption within a test, each test starts with an all
> zero nonce and a fixed key.

True, the final 9 more complex tests don't quite meet the security recommendations. Nonces do get reused, though only with different tag lengths (or different keys). I'm sure that isn't a security problem as the tag length and nonce are combined into a 128-bit "internal nonce" (which is not repeated for the same key), but I guess it isn't ideal.
The same key is used with 3 different tag lengths. That does go against a security recommendation.

One solution is to change the key for each tag length, giving 9 distinct keys for the 9 cases.

   K = num2str(TAGLEN, KEYLEN)    // eg 00..0040 when TAGLEN == 64

I then get:

   AEAD_AES_128_OCB_TAGLEN128 Output: 67E944D23256C5E0B6C61FA22FDF1EA2
   AEAD_AES_192_OCB_TAGLEN128 Output: F673F2C3E7174AAE7BAE986CA9F29E17
   AEAD_AES_256_OCB_TAGLEN128 Output: D90EB8E9C977C88B79DD793D7FFA161C
   AEAD_AES_128_OCB_TAGLEN96 Output : 77A3D8E73589158D25D01209
   AEAD_AES_192_OCB_TAGLEN96 Output : 05D56EAD2752C86BE6932C5E
   AEAD_AES_256_OCB_TAGLEN96 Output : 5458359AC23B0CBA9E6330DD
   AEAD_AES_128_OCB_TAGLEN64 Output : 192C9B7BD90BA06A
   AEAD_AES_192_OCB_TAGLEN64 Output : 0066BC6E0EF34E24
   AEAD_AES_256_OCB_TAGLEN64 Output : 7D4EA5D445501CBE

> Also - a more minor nit - your notation for incrementing the nonce
> seems odd to me. The nonce is defined as a string of bytes - whereas
> in your notation it is treated as an integer which can be incremented.
> 
> Matt

I think "N = N + 1" is more obvious than "N = num2str(3*i + 1, 96)", even if it does mix byte strings and arithmetic.

--
James Manger