Re: [Cfrg] comments on AES Key Wrap with Pad

[Russ Housley <[e-mail]>]

David:

I do not understand the concern that publication of an Informational 
RFC containing an update to a key-wrap AES mode would cause anyone to 
update a protocol specification, much less all protocol 
specifications that might take advantage of the updated mode.

I do think that some guidance is desirable.  However, I do not 
understand your key usage decrypt restriction.  The limits should be 
on the encrypt side.  If the decrypt is used on the same ciphertext 
over and over, this cannot introduce a problem.

Russ


At 12:40 PM 4/1/2009, David McGrew wrote:
>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
>>[e-mail]
>>http://www.irtf.org/mailman/listinfo/cfrg