Couple of issues to be addressed here:
1. Under seperate mail I sent in my vote but I did want to explain my
reasoning as well. I think we need to work with X/8 bytes of key for two
reasons. First, I don't believe that adding the additional bytes of data
adds any more value to the key size. Secondly, we are seting a precident
for any new algorithms that come along with simliar features. Making this a
fixed size means that all new algorithms would have a fixed size even if
they allow for variable length input, making the data size correspond to the
key size is better in my judgement for all algorithms of this style. The
input for the key should be the same length as the key itself is. There is
no possible "better security" or the argument about how long the key is
needs to be re-defined in terms of the input to the key.
2. I completely agree with Blake that what current products do is
completely irrelavent. This is a new key transport mechisism from what is
currently offered today in any existing product. I do know that the product
Blake works for does generate fixed length RC2 for content encryption while
both Microsoft products use input length == key length for the same purpose.
Additionally both products accept either method for decryption. This means
that both products have the ability to work in EITHER manner.
3. Padding on the key wrapping algorithm. I have a possible worry about
using the RSA #1 padding method. Since all of our data is going to be of a
fixed length (the same padding for all wrapped triple DES keys for example),
is it possible that we are making an attack easier on the key wrapping
algorithm by using the standard RSA #1 padding technique rather than the
originally prosposed random padding?
jim schaad