Re: [Cfrg] AES Key Wrap with Pad

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

  Hi Russ,

  I understand the desire to wrap things that are not a multiple of
64 bits (the inability to do that is a serious shortcoming of AES Key
Wrap). I'd probably expect people to also be interested in having
the ability to bind associated data to the wrapped key. And I'll bet
people would be interested in a provably secure key wrapping algorithm.

   SIV has a security proof behind it-- see "Deterministic Authenticated
Encryption, A Provable-Security Treatment of the Key-Wrap Problem" by
Rogaway and Shrimpton; to my knowledge, AES Key Wrap, with or without
padding, does not. SIV provides for the binding of associated data to
the wrapped key; AES Key Wrap does not.

  The fact that the modifications you're proposing to AES Key Wrap
can be done by someone whose coding skills are a bit rusty does not
change the fact that it is a new code point. This particular wrapping
will have to be distinguished from RFC 3394 and protocol designers are
going to have to go through the trouble of adding another negotiated key
wrapping to their protocol.

  So given the choice of "wraps keys of arbitrary length, binds associated
data to wrapped keys, provably secure" or "wraps keys of arbitrary length"
why would you not want to go with the former?

  regards,

  Dan.

On Sat, March 28, 2009 1:31 pm, Russ Housley wrote:
> Some people are interested in using AES Key Wrap when the inputs are
> not a multiple of 64 bits.  This was previously addressed in RFC 3537
> in a way that does not scale to all key types that one might want to
> wrap.  This one does the job with very little code modification.  I
> did the code the generate the test vectors in a few hours, including
> checking against code from someone else, and I have not written code
> as a primary aspect of my job in a very long time.
>
> Russ
>
> At 02:50 PM 3/28/2009, Dan Harkins wrote:
>
>>   Hi Russ,
>>
>>   This draft addresses a shortcoming in AES Key Wrap (RFC 3394) but I
>>still have to ask "why?"
>>
>>   Using this new version of AES Key Wrap will require a new code point
>>and if that's the case why not just use AES-SIV (RFC 5297)? It allows
>>for wrapping of arbitrarily-sized keys (which is the enhancement your
>>new I-D adds to AES Key Wrap) but also has the ability to accept
>>associated data.
>>
>>   A key wrapping algorithm that accepts associated data is valuable to
>>protocols which need to distribute wrapped keys. They can bind the
>>message containing the key to the wrapping and/or include shared state
>>to prevent against cut-and-paste attacks. And itt obviates the need to
>>do an additional HMAC-foo over the entire message.
>>
>>   While this I-D provides an improvement on AES Key Wrap, it seems to
>>me that it's putting a turbo-charger on a Volkswagon Bug when you could
>>drive a Ferrari instead.
>>
>>   regards,
>>
>>   Dan.
>>
>>On Sat, March 28, 2009 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
>> >
>
>