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.