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

["Dan Harkins" <dharkins at lounge.org>]

  Hi David,

On Wed, April 1, 2009 9:40 am, David McGrew wrote:
[snip]
> <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.

  I'm afraid that language would imply that AES Key Wrap is a suitable
encrypted authentication scheme for arbitrary data when nonce uniqueness
cannot be guaranteed; it's not. AES Key Wrap is a deterministic
authenticated encryption scheme and is only suitable for use if a
component of the data is generated uniformly at random. If there is no
key to wrap then using a AES Key Wrap would not achieve the equivalent
of semantic security.

  I would like to suggest adding some text to section 1 (where the length
of key data is mentioned) along the lines of "The key data MUST contain a
component of data whose value is unpredictable to an attacker." It says
"key data" throughout but it can't hurt to add this requirement.

  If it is not possible or desirable to meet the requirements on nonce
generation in RFC 5116, Section 3.1 then RFC 5297 should be used. And
this is true whether the data to wrap is a key or not.

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

  Again, if additional data associated with the key needs to be used
then RFC 5297 SHOULD be used as it can specifically be used without a
nonce whereas the AEAD schemes in RFC 5116 cannot.

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

  An algorithm like this is useful even when data in transit is protected
by a strong encryption and authentication. For instance,

  - RADIUS key distribution in the presence of proxies where the key need
    not be disclosed to each proxy along the way from server to client.
  - with a key distribution protocol where Bob receives an opaque (wrapped)
    blob for Alice from a third party to which Bob has a strong, secure
    connection. This blob would be used by Alice to set up a security
    association with Bob and she would have cryptographic assurance that
    the blob came from her trusted third party.
  - it can be used to generate session resumption tickets for stateful
    protocols-- here's a blob that's bound to you that you can't unwrap
    but if you give it back to me at some later time I'll be able to
    unwrap it and use the information inside.

  Even though there's a strong, secure connection in place it can be
useful to send wrapped data through that connection.

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

  Very good point. This guidance belongs in the Security Considerations.

  regards,

  Dan.