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

[David McGrew <[e-mail]>]

Hi Russ,

On Apr 1, 2009, at 1:41 PM, Russ Housley wrote:

> 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 take your point, but I still think guidance is a good idea, because  
some people don't have a clear idea of where keywrap is appropriate  
and where it is not.  What I'm concerned about is setting the right  
expectations for future protocol selection and design.

>
>
> 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.
>

I was thinking of the situation in which an attacker has access to a  
chosen-ciphertext keywrap decryption oracle.   Probably the AIV check  
would raise this limit a lot higher than 2^64, as you suggest.  I  
haven't done the analysis, so I don't know the details.

David

> 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
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg