Re: Early Draft Algorithms Section

XML Encryption Algorithms DraftThere are several problems with this as
proposed. My comments are inline to keep things somewhat simpler.
----- Original Message -----
From: Donald Eastlake 3rd
> No stream encryption algorithms are sepcified.
"sepcified" should be "specified".
Also stream algorithms should be specified. In fact this entire list is
entirely too US centric.

[snip algorithm list]
By specifying things in this way (e.g. 3DES with SHA-1) we immediately build
an exponential increase in the parsing design as more authenticity and
encryption algorithms are added. It would be much better to specify the two
seperately, resulting in linear growth. The combinations are not very well
matched, 3DES does not match SHA-1 (3DES is stronger), and Rijndael (the
FIPS specifying AES is not finalized, calling it AES is incorrect) does not
match SHA-256. Rijndael is fast, SHA-256 is slow. Additionally SHA-256 only
matches Rijndael-128, for Rijndael 192/256 requires SHA-384/512
respectively, however those are even slower. Beyond this the SHA-256/384/512
hashes are not of the highest caliber, they are designed for high security,
but they are completely lacking in speed, their should not be used until
they are a final FIPS either. Additionally the actual specification for 3DES
is NOT an ANSI anything, it is a FIPS 46-3. You have also completely missed
the fact that there are 4 different 3DES specs available, EEE, EDE, 2key,
3key. NIST allows for all of these.

RSA-OAEP with AES is completely non-standardized. OAEP requires the use of a
hash function (in fact it is parameterized by it), specifying it only AES
does not make sense. You have to specify which hash function is to be used
with it (because the key size is not the 160-bit standard).

The Diffie-Hellman specification needs to be completed, but it cannot
because it needs to be parameterized by the size of the secret to be
negotiated (it's weaker to simply use the nth bit of the secret than to hash
the secret and use the nth bit).

CMS Key Checksum. Quite frankly this should never have been designed. It is
horrendous in design, making use of the worst features of SHA-1, and
continuing to eliminate the best features. Since we are not overly concerned
about space, remove this and use SHA-1.

CMS Triple DES Key Wrap. This is also designed very poorly. By adding a
parity bit to thbe bottom of each byte you actually remove entropy from the
encryption, this is a WORSE idea than clipping SHA-1. It is vastly better to
pad the final bits with randomness. Even better than that is to build a
proper construct for the stroring of keys (I have several close at hand if
they are needed).

Ditto for what will be the RC2 Key Wrap and the AES KeyWrap.

RSA version 1.5 needs to be removed completely, it is not as secure as it
needs to be, it is overly compute intensive, it is utterly and completely
worthless from a realistic standpoint. Instead move to OAEP, since we're
transporting a 3DES key, use SHA-1, and fix the last 8 bits of the 3rd key
to 0. This will not reduce security since it only takes 2^90 work to break a
3DES key, and knowledge of portions of the 3rd key makes no difference
(provided that it is no more than 48-bits that are revealed).

I think that's about it. I believe that the entire specification of ciphers
is highly misguided, with decisions ranging from acceptable, to abysmal,
including some that are completely inapproriate, 1 that is simply impossible
notation-wise, 2 that are grossly mismatched within themselves, and a
perfect breaking of the specification that will be AES (making 192/256 bit
keys optional). There is also a very distinct lacking of listing of chaining
modes. the chaining mode is as important as the cipher choice. The
authenticity modes are completely inadequate, a hash function is not
suitable for most situations, a MAC is needed, quite often encrypted is
desirable making the reference to the external XML sig document
inappropriate.
                                    Joe

Received on Monday, 14 May 2001 15:09:50 UTC