Jim Schaad (Exchange) wrote:
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.
As I understand it the poll is only for the case of RC2 because there is
some ambiguity. It would be hoped that a new algorithm would not have
such ambiguity and would either define the keysize in terms of the
effective length or better still have an AlgortighmIdentifier which
allows all the parameters to be explicitly stated.
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.
Well I wouldn't say completely irrelevant. There is the issue of using
DH and RSA together.
This is all associated with whether the poll should (or needs to) apply
to the MEK as well as the KEK which is itself connected with the
suggested key wrapping modifications.
If the MEK is to be affected then this implies that already existing
code will need to be modified. In that case it could be argued that
whatever is the more common current practice should be adopted.
I don't to agree with that because the key wrapping standard is also
"new" it should be modified to allow the length of the MEK to be
determined rather than existing code.
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?
I assume we are talking about the same thing here (block padding as in
CMS 6.3 or therabouts). Is there any specific attack you are referring
to? There are lots of ways to substitute garbage for the MEK that will
only be noticed when the message is decrypted, e.g. copy from another
message.
IMHO the wrapping spec should allow the keylength to be determined for
the reasons mentioned above. PKCS padding was only a simple suggestion
that would involve miminal modification. There are lots of alternatives,
such as including a length argument in either the wrapped structure or
the outer ASN1 or use an ASN1 structure to wrap the key and checksums in
the first place.
Steve.
--
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant.
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: shenson(_at_)drh-consultancy(_dot_)demon(_dot_)co(_dot_)uk
PGP key: via homepage.