Re: [jose] Use of AES-HMAC algorithm

Dick Hardt <dick.hardt@gmail.com> Thu, 28 March 2013 00:30 UTC

Return-Path: <dick.hardt@gmail.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 AB3E221F919D for <jose@ietfa.amsl.com>; Wed, 27 Mar 2013 17:30:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.341
X-Spam-Level:
X-Spam-Status: No, score=-3.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 lkTj3zSeW0+d for <jose@ietfa.amsl.com>; Wed, 27 Mar 2013 17:30:12 -0700 (PDT)
Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by ietfa.amsl.com (Postfix) with ESMTP id BF6BF21F9195 for <jose@ietf.org>; Wed, 27 Mar 2013 17:30:07 -0700 (PDT)
Received: by mail-pb0-f46.google.com with SMTP id uo1so1652944pbc.5 for <jose@ietf.org>; Wed, 27 Mar 2013 17:30:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=SodbF/h5p+YEO3dgY69s4X5Y2Nkv4uDq4obIwtECBh8=; b=oWWqBII6UjXzUfyVAOxbYzHQa3ePSd8lmV1sSVba8obQ8k5e7tweENev7GnfbS8R9r jXQPuI2UdYIANhhx4YYpuZhgF9UvkeeVCDKdufrQvZ45RuJ0kDmVDSNvudE26fNbatqX fbcQgxCeWfba/i3eCxE9oAKXeWnIEJcX3zpWqjNACzd+BeOU0n2uF0jFxHx2G+RKutw0 tthb19MPjXC/wzvv8eNJMN0HIdmkBBdP4rkNeMc2TtyO8OaIG5FBK39wODrC8FsyXXPk NJu5hOho/erLvixrDOGH3P4pyj6JkS3U6IYHts1QuRZLWRwtXmOOM+OXBTzqwBI9kUai A0Iw==
X-Received: by 10.66.160.106 with SMTP id xj10mr2659609pab.139.1364430607492; Wed, 27 Mar 2013 17:30:07 -0700 (PDT)
Received: from [10.0.0.89] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id yp2sm12862892pab.10.2013.03.27.17.30.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Mar 2013 17:30:05 -0700 (PDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Dick Hardt <dick.hardt@gmail.com>
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367590C2F@TK5EX14MBXC283.redmond.corp.microsoft.com>
Date: Wed, 27 Mar 2013 17:30:03 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <1D2E2774-4A20-43AE-A2D6-30FF797DAAAF@gmail.com>
References: <006801ce2b39$52595700$f70c0500$@augustcellars.com> <4E1F6AAD24975D4BA5B168042967394367590C2F@TK5EX14MBXC283.redmond.corp.microsoft.com>
To: Mike Jones <Michael.Jones@microsoft.com>
X-Mailer: Apple Mail (2.1503)
Cc: Jim Schaad <ietf@augustcellars.com>, "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] Use of AES-HMAC algorithm
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, 28 Mar 2013 00:30:12 -0000

On Mar 27, 2013, at 5:21 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

> Per your point 1, I don't think anyone was advocating doubling the key size.  The proposal in John's slides for issue #3 (http://trac.tools.ietf.org/wg/jose/trac/ticket/3) was to use a CMK that is the concatenation of the AES-CBC and HMAC-SHA-2 keys, as draft-mcgrew-aead-aes-hmac-sha2 does.  For instance, when using A128CBC with HS256, the key size would be 384 bits and when using A256CBC with HS512, the key size would be 768 bits.  This would multiply the current key sizes by 1.5, with the compensating benefit being the elimination of the use of the KDF.

Was this because people thought KDF was hard? I managed to implement it in JavaScript, can't be that hard! ;-) … or was there a security reason?

This is a breaking change to my implementation. 

FWIW: I cache the results of the KDF so that I only incur the calculation the first time I see a key.