Re: [jose] Use of AES-HMAC algorithm - Consensus Request
Dick Hardt <dick.hardt@gmail.com> Mon, 08 April 2013 04:47 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 441AD21F9128 for <jose@ietfa.amsl.com>; Sun, 7 Apr 2013 21:47:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.07
X-Spam-Level:
X-Spam-Status: No, score=-1.07 tagged_above=-999 required=5 tests=[AWL=-1.118, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.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 CmcvDLIgD4cs for <jose@ietfa.amsl.com>; Sun, 7 Apr 2013 21:47:06 -0700 (PDT)
Received: from mail-da0-x230.google.com (mail-da0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 57E7D21F9123 for <jose@ietf.org>; Sun, 7 Apr 2013 21:47:06 -0700 (PDT)
Received: by mail-da0-f48.google.com with SMTP id p8so2447930dan.21 for <jose@ietf.org>; Sun, 07 Apr 2013 21:47:06 -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=KRNbhr7ijThhSwbYhymfGXpS/Ap7KRU491sdOnc+QTc=; b=0zlqSvVrG2BKq2t8Ee24lhYJ5ZxUoctmhDO2xJFo9S/jUyXYR9onc0rgSS2YsCJdnw sf4WfytwUZQLYeqg9k3sY0FkW34OGEAxEUlwpSTA5ftAZ4IYMolzfthXZwJClBJDG/9s nlO1L5wmb4rq6kD2O3jUuQJDwURxJUbdRt96sI3J8pZJn7GZllqO9vsZnTLAxH/3jXNS gf8utrtMxSCWgRGl6mWWx0p9wqxoxsB2fAL6SKq0bAXw9NMPsGaIXp4EQVb+yCioyPX/ 9w3h62Kmrgi3r6TH0bYp9XMTWNKc3SQt/1OEmDVhkqJLKWR/FkOQfA9D+xhldemKVGNy c91A==
X-Received: by 10.66.122.39 with SMTP id lp7mr9332469pab.116.1365396425766; Sun, 07 Apr 2013 21:47:05 -0700 (PDT)
Received: from [10.0.0.58] (c-98-210-193-30.hsd1.ca.comcast.net. [98.210.193.30]) by mx.google.com with ESMTPS id ky10sm35938082pab.23.2013.04.07.21.47.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 07 Apr 2013 21:47:04 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Dick Hardt <dick.hardt@gmail.com>
In-Reply-To: <8B4C063947CD794BB6FF90C78BAE9B321EFFF14C@IMCMBX04.MITRE.ORG>
Date: Sun, 07 Apr 2013 21:47:10 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <CDF230A7-15ED-4722-BDFC-364D8A1975B8@gmail.com>
References: <017a01ce318f$482d8470$d8888d50$@augustcellars.com> <8B4C063947CD794BB6FF90C78BAE9B321EFFF14C@IMCMBX04.MITRE.ORG>
To: "Peck, Michael A" <mpeck@mitre.org>
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 - Consensus Request
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: Mon, 08 Apr 2013 04:47:08 -0000
FWIW: I'd strongly prefer a longer key than a different KDF scheme. On Apr 7, 2013, at 12:32 PM, "Peck, Michael A" <mpeck@mitre.org> wrote: > I prefer using a KDF, as I think the approach of using a long key over-complicates key management by requiring generation and transport of a longer key than necessary, and it may also provide a false sense of the overall security level. > > As previously discussed, the Concat KDF is not appropriate, but there are other NIST KDFs that seem acceptable for this key expansion purpose. > For instance, the "KDF in Counter Mode" in NIST SP 800-108 Section 5.1, with the PRF algorithm set to the same HMAC algorithm used in the corresponding AEAD algorithm. (i.e. use HMAC-SHA-256 as PRF with AES-128 + HMAC-SHA-256, and use HMAC-SHA-512 as PRF with AES-256 + HMAC-SHA-512). > > For example, for AES-128 + HMAC-SHA-256, where "key" is an inputted 128-bit "master" key: > Expanded key = HMAC-SHA-256(key, 0x00 0x00 0x00 0x01 | "A128CBC+HS256" | 0x00 | 0x00 0x00 0x01 0x00) > AES key = first 128 bits of expanded key > HMAC key = second 128 bits of expanded key > > If JOSE chooses to use draft-mcgrew-aead-aes-cbc-hmac-sha2, I think it would be worth discussing with the draft authors whether they are interested in performing the KDF in the AEAD algorithm itself (for example, input a 128-bit key into their AEAD_AES_128_CBC_HMAC_SHA_256 and have it be responsible for deriving the 128-bit AES key and 128-bit HMAC key). > > Mike > >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of >> Jim Schaad >> Sent: Thursday, April 04, 2013 7:51 PM >> To: jose@ietf.org >> Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request >> >> <chair> >> >> At the request of the editors, this is a formal consensus call on the first >> item in the list below. If there are objects to use a single long key >> rather than a KDF function for the AES-CBC/HMAC algorithm please speak up >> now. To date nobody has said that I was wrong to assume the consensus on >> that item. >> >> Call ends in one week. >> >> Jim >> >> >>> -----Original Message----- >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of >> Jim >>> Schaad >>> Sent: Wednesday, March 27, 2013 3:21 PM >>> To: jose@ietf.org >>> Subject: [jose] Use of AES-HMAC algorithm >>> >>> <chair> >>> After spending time looking at and thinking about how to resolve this >> issue >>> since I was unable to do so at the last F2F meeting. I have come up with >> the >>> following set of issues that might need to be addressed as part of >> resolving >>> this issue. >>> >>> 1. Do we change from using KDC to having a double size key for the >>> algorithm? I think that there is probably a consensus that this should be >> done. >>> >>> 2. Should IVs be prepended to the encrypted body as part of the encoding >>> steps? If so then this change should be universal. >>> >>> Doing so would eliminate one field from all of the encoding formats which >>> should be considered a plus. >>> Doing so would force code writers to understand how large the IV is for >> all >>> algorithms as the IV would no longer be a separate item. >>> >>> 3. Should Authentication Tags be appended to the encrypted body as part of >>> the encoding steps? >>> >>> Doing so would eliminate one field from all of the encoding formats which >>> should be considered a plus. >>> Doing so would force code writers to understand how large the IV is for >> all >>> algorithms as the IV would no longer be a separate item. >>> Doing so would force a re-organization for the multiple recipient case as >>> either all recipient specific data would need to be excluded from the >>> authentication step or all of the recipient data would need to be included >> for >>> by all recipients. >>> Changing how the recipient info is process is going to give a performance >>> benefit for sending encrypted items for multiple recipients. >>> The current strategy of a single IV and key pair with AES-GCM and >> different >>> authentication data needs to have CFRG look at it. I am worried that it >> might >>> be a serious security flaw. >>> >>> 4. Should we reference the McGrew draft and provide text on how things >> are >>> changed or should we "copy" the draft into our text? >>> >>> 5. If we allow for the use of AES-GCM or AES-HMAC for doing key wrapping, >>> does this change how we think about any of the above questions? >>> >>> Allowing for AES-GCM for key wrapping has a benefit for hardware >> situations >>> as only the encrypt and not the decrypt functions need to be placed in >>> hardware. However allowing for this key wrapping give a problem as there >> is >>> no way to encode the three fields into the encrypted value unless with use >>> either a JSON structure in this location or we do use the single appended >>> binary output stream. The first approach leads to an expansion of the >> field by >>> double base64 encoding which is highly undesirable. >>> >>> Jim >>> >>> >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose
- Re: [jose] Use of AES-HMAC algorithm - Consensus … Jim Schaad
- Re: [jose] Use of AES-HMAC algorithm - Consensus … Dick Hardt
- Re: [jose] Use of AES-HMAC algorithm - Consensus … Mike Jones
- Re: [jose] Use of AES-HMAC algorithm - Consensus … John Bradley
- Re: [jose] Use of AES-HMAC algorithm - Consensus … Vladimir Dzhuvinov / NimbusDS
- Re: [jose] Use of AES-HMAC algorithm - Consensus … Russ Housley
- Re: [jose] Use of AES-HMAC algorithm - Consensus … Peck, Michael A
- Re: [jose] Use of AES-HMAC algorithm - Consensus … Dick Hardt
- Re: [jose] Use of AES-HMAC algorithm - Consensus … Matt Miller (mamille2)
- Re: [jose] Use of AES-HMAC algorithm - Consensus … Nat Sakimura
- Re: [jose] Use of AES-HMAC algorithm - Consensus … Edmund Jay
- Re: [jose] Use of AES-HMAC algorithm - Consensus … John Bradley