Re: A New Triple-DES Key Wrap Algorithm

[Russ Housley <[e-mail]>]

Bob:

>You are correct, of course.  The question, then, is whether
>we should just go to the OAEP-type wrapping and not have
>to worry about changing IV's and how to convey them.
>That would be my recommendation.

I think that OAEP has the same issue.  Each time a key is wrapped, a
different random number must be used.  This is the same a generating a new
IV for the first encryption.


>On a slightly different issue, several times I have strongly urged
>that in order to avoid the problem of having N-squared algorithm
>IDs for all of the various combinations of CEK and KEK algorithms,
>key lengths, and other miscellaneous data, that we first wrap
>the CEK in a descriptive ASN.1 structure that describes the 
>the CEK algorithm/key, and then do the wrapping operation.
>
>However, although I've raised this issue several times and indicated
>our strong desire to solve the key wrapping issue once and for all,
>you have neither incorporated the idea or argued against it,
>so I don't know where you stand.

I think I was clear on this point in an earlier posting.  My first priority
is to finish S/MIME v3.  If the general key wrapping problem is solved at
the same time, fine.  The S/MIME v3 structure includes an
AlgorithmIdentifier for the key wrapping algorithm, so if a secure solution
is included in the documents today, it can be aougmented with a general
solution when it is fully vetted.


>Obviously anyone who is processing certificates is going to have to 
>have an ASN.1 decoder, and Dr. Acar, who wrote ours, assures 
>me that the performance implications would be negligible compared to
>almost any encryption operation.
>
>Assuming that is the case, the only reason I could see for not doing 
>it would be concern about the increase in wrapped key size,
>or some lingering not-invented-here bias against ISO/ITU/X.500
>mechanisms.  I certainly hope it isn't the later.

In general, ASN.1 is a good tool.  However, Burt Kaliski's attack against
the original key wrap algorithm was due to known structure in the
plaintext.  ASN.1 intruduces significant structure.  While ASN.1 or some
other encoding might be part of the general key wrap solution, I am will
avoid it in the near term.


>Is there anything in the existing protocol that is rigidly sensitive to 
>the size of the wrapped key?  If so, then that is a problem that 
>probably ought to be addressed.

No.  However, every user is concerned with overhead.  Since the
content-encryption key is wrapped once for each recipient, I am sensitive
to the multiplier.


Russ