[Cfrg] comments on AES Key Wrap with Pad

[David McGrew <mcgrew at cisco.com>]

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 at irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg