[Cfrg] comments on AES Key Wrap with Pad
David McGrew <mcgrew@cisco.com> Wed, 01 April 2009 16:39 UTC
Return-Path: <mcgrew@cisco.com>
X-Original-To: cfrg@core3.amsl.com
Delivered-To: cfrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8E513A6DAF for <cfrg@core3.amsl.com>; Wed, 1 Apr 2009 09:39:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.928
X-Spam-Level:
X-Spam-Status: No, score=-5.928 tagged_above=-999 required=5 tests=[AWL=0.671, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqQA1jC3tQhV for <cfrg@core3.amsl.com>; Wed, 1 Apr 2009 09:39:47 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 12E2F3A6DB7 for <cfrg@irtf.org>; Wed, 1 Apr 2009 09:39:30 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.39,307,1235952000"; d="scan'208";a="278208030"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 01 Apr 2009 16:40:18 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n31GeIRE003306; Wed, 1 Apr 2009 09:40:18 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n31GeIQQ009197; Wed, 1 Apr 2009 16:40:18 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Apr 2009 09:40:18 -0700
Received: from stealth-10-32-254-213.cisco.com ([10.32.254.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Apr 2009 09:40:17 -0700
Message-Id: <B52B2A30-DEB6-41F7-ABB9-55BBC670B5F5@cisco.com>
From: David McGrew <mcgrew@cisco.com>
To: Russ Housley <housley@vigilsec.com>
In-Reply-To: <20090328172818.1F6759A47B3@odin.smetech.net>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Wed, 01 Apr 2009 09:40:16 -0700
References: <20090328172818.1F6759A47B3@odin.smetech.net>
X-Mailer: Apple Mail (2.930.3)
X-OriginalArrivalTime: 01 Apr 2009 16:40:17.0792 (UTC) FILETIME=[8A390800:01C9B2E8]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2811; t=1238604018; x=1239468018; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mcgrew@cisco.com; z=From:=20David=20McGrew=20<mcgrew@cisco.com> |Subject:=20comments=20on=20AES=20Key=20Wrap=20with=20Pad |Sender:=20; bh=k87TIes/VvqhqzWKSimMGixQYT7mEZYFRTuuryB6ARY=; b=mMZJ18K+5Gx8S1atSFHbOkr3+0kF6ICX8GyEUTcaVBAD/LRw2DqyQYLkhy eV3ltDUhmdGJsj9LFIEp85MOMZ77N1B+n3tFtfiENqOeII2j8GayXE7IcQix HRyd2ofOzY;
Authentication-Results: sj-dkim-3; header.From=mcgrew@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; );
Cc: Morris Dworkin <dworkin@nist.gov>, cfrg@irtf.org
Subject: [Cfrg] comments on AES Key Wrap with Pad
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/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, 01 Apr 2009 16:39:48 -0000
Hi Russ, this draft makes it possible to use the keywrap algorithm in more applications, by removing length restrictions on its inputs, but it doesn't provide any guidance on where or how the keywrap algorithm should be used. I suggest that some guidance be added on this subject. The biggest question is: given that the keywrap algorithm provides encryption and integrity protection, in what cases should it be used instead of an authenticated encryption algorithm, or an AEAD algorithm, as in RFC 5116? I will take a guess at the answer in the hope of being constructive: <guidance> If it is not possible or desirable to meet the requirements on nonce generation in RFC 5116, Section 3.1., then the keywrap algorithm should be used. If there is additional data associated with the key, which should be authenticated but not encrypted, then an AEAD algorithm should be used. This type of data could include information on how the encrypted data is to be processed; this data needs to be unencrypted in order to allow the system to function. If high data rates need to be supported, then an AEAD algorithm should be used. </guidance> It is important that the key-wrap document doesn't inadvertently create an expectation that every protocol in which key material gets transported needs to be re-designed to incorporate a key-wrap algorithm. My preference would be to have a statement like this: If a protocol is already encrypting and authenticating data using strong algorithms, it is not necessary to use key-wrap to provide an additional layer of encryption and authentication/integrity-protection. My understanding of the motivation for the keywrap algorithm (which I will admit has been incomplete) is that it provides a way to encrypt AES-256 keys using AES-256, and thus provides functionality similar to that of using AES-128-ECB to encrypt an AES-128 key. If that's right, would it be worthwhile to add this example usage? I suggest adding guidance on key usage. I would assume that the KEK would need to be generated uniformly at random, or by a process that it indistinguishable from a random process, and that each KEK should be used to encrypt no more than 2^64 distinct key-data inputs (though perhaps a lower bound would be more sensible) and decrypt no more than the same number of ciphertexts. best regards, David On Mar 28, 2009, at 10:28 AM, Russ Housley wrote: > http://www.ietf.org/internet-drafts/draft-housley-aes-key-wrap-with-pad-02.txt > > I want to make sure that the CFRG is aware of this document. > > Russ > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg
- Re: [Cfrg] comments on AES Key Wrap with Pad David McGrew
- [Cfrg] comments on AES Key Wrap with Pad David McGrew
- Re: [Cfrg] comments on AES Key Wrap with Pad Dan Harkins
- Re: [Cfrg] comments on AES Key Wrap with Pad David McGrew
- Re: [Cfrg] comments on AES Key Wrap with Pad Russ Housley
- Re: [Cfrg] comments on AES Key Wrap with Pad Russ Housley
- Re: [Cfrg] comments on AES Key Wrap with Pad Dan Harkins