[jose] AESWrap vs ECB key wrap

"Manger, James H" <James.H.Manger@team.telstra.com> Thu, 02 August 2012 07:16 UTC

Return-Path: <James.H.Manger@team.telstra.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD3C21F87FF for <jose@ietfa.amsl.com>; Thu, 2 Aug 2012 00:16:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.165
X-Spam-Level:
X-Spam-Status: No, score=-1.165 tagged_above=-999 required=5 tests=[AWL=-0.264, 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 EAJnYjTyRBO2 for <jose@ietfa.amsl.com>; Thu, 2 Aug 2012 00:16:34 -0700 (PDT)
Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id DB05C21F8CAD for <jose@ietf.org>; Thu, 2 Aug 2012 00:16:33 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.77,699,1336312800"; d="scan'208";a="83497712"
Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipobni.tcif.telstra.com.au with ESMTP; 02 Aug 2012 17:16:32 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,6790"; a="80519940"
Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipccni.tcif.telstra.com.au with ESMTP; 02 Aug 2012 17:16:31 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Thu, 2 Aug 2012 17:16:31 +1000
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: "jose@ietf.org" <jose@ietf.org>
Date: Thu, 02 Aug 2012 17:16:30 +1000
Thread-Topic: AESWrap vs ECB key wrap
Thread-Index: Ac1wfrzy/T+dm17hTSCmvrFUCKSwfg==
Message-ID: <255B9BB34FB7D647A506DC292726F6E114FA1E3F93@WSMSG3153V.srv.dir.telstra.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: [jose] AESWrap vs ECB key wrap
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Aug 2012 07:16:35 -0000

I noticed an "ECB key wrap" option was discussed at the IETF meeting, as an alternative to AESWrap [RFC 3394].

I hadn't looked closely at AESWrap before. Its important features seem to be:
1. Only defined for content keys that are a multiple of 64-bits
2. Adds an overhead of 64 bits (= 8 bytes = 12 B64 chars)
3. Offers a 64-bit integrity check (from the overhead)
4. Performs 12 AES operations for each 64-bits of the content key

I assume an ECB key wrap, in contrast, would avoid the 64-bit overhead by dropping the integrity check and only use 1/24th of the AES operations. Would it also use, say, ciphertext stealing so there is no size overhead for any content key size?

If a 12 byte overhead (when base64url-encoded) is too small to worry about (and an extra, say, 46 AES operations is immaterial), then JOSE should keep AESWrap as the only choice. It still need to define how to use AESWrap for content keys that are not a multiple of 64-bits. Perhaps one byte of the integrity check is changed to indicate the content key length?

If size is going to be absolutely crucial for some use cases, then an ECB key wrap could help. Such a size-constrained situation would probably need other changes as well, such as the choice of a shorted IV and integrity tag for AES-GCM (than the 128-bits and 96-bits picked in JWA).

--
James Manger