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