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

From: David McGrew <[email-masked]>
Date: Wed, 1 Apr 2009 09:40:16 -0700

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
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 1 Apr 2009 10:56:10 -0700 (PDT)

Hi David,

On Wed, April 1, 2009 9:40 am, David McGrew wrote:
[snip]
> generation in RFC 5116, Section 3.1., then the keywrap algorithm

  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.

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

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

> the same number of ciphertexts.

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

  regards,

  Dan.

---

From: David McGrew <[email-masked]>
Date: Wed, 1 Apr 2009 11:20:51 -0700

Hi Dan,

thanks for your comments.

On Apr 1, 2009, at 10:56 AM, Dan Harkins wrote:

> "key data" throughout but it can't hurt to add this requirement.\

That's a good suggestion.

> useful to send wrapped data through that connection.

You're right, I was too brief in what I wrote, which only applies when  
there are only two parties involved.

David

---

From: Russ Housley <[email-masked]>
Date: Wed, 01 Apr 2009 16:41:31 -0400

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

---

From: David McGrew <[email-masked]>
Date: Wed, 1 Apr 2009 14:39:24 -0700

Hi Russ,

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

> RFC containing an update to a key-wrap AES mode would cause anyone  
> to update a protocol specification, much less all protocol  

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.

> 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

---

From: Russ Housley <[email-masked]>
Date: Mon, 06 Apr 2009 14:04:04 -0400

Dan & Dave:

You have suggested things that should be added to the security 
considerations.  I'd prefer to back up a few hundred feet and see if 
some more general statements would be satisfactory.

Key Criteria:  I'd rather use the guidance that already appears in 
NIST description for the AES Key Wrap.  That is:

    The KEK must be at least as good as the keying material it is protecting.

AEAD: I'd rather explain why an algorithm dedicated to key wrapping 
is desirable.  That is:

    In the design of some high assurance cryptographic modules, it is
    desirable to segregate cryptographic keying material from other data.
    The use of a specific cryptographic mechanism solely for the
    protection of cryptographic keying material can assist in this goal.
    The AES Key Wrap and the AES Key Wrap with Pad are such mechanisms.
    System designers should not be tempted to use these algorithms to
    encrypt anything other than cryptographic keying material.

Russ

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 6 Apr 2009 12:29:41 -0700 (PDT)

Hi Russ,

  This looks good. I suggest s/should not be tempted to/MUST NOT/
in the warning but it's probably fine as is.

  Thanks for addressing my comments,

  Dan.