RE: Early Draft Algorithms Section

## Hi, See comments preceded by ##

-----Original Message-----
From: Joseph Ashwood [mailto:jashwood@arcot.com]
Sent: Monday, May 14, 2001 2:40 PM
To: Donald Eastlake 3rd; xml-encryption@w3.org
Subject: 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.

## Sorry, I didn't run this through a spell checker this time.

## I don't think we need a stream cipher just to have a stream cipher
## but if you would like to propose some particular one and its level
## of implementation (mandatory, recommended, or optional), the group
## could discuss it.

[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.

## Some people like orthogonally specifying the different sub-algorithms
## that go together to make up a suite and some think that opens holes
## and gives opportunities for improper use.  In XML DSIG, we ended up
## with a consensus for unified algorithm URIs, which bundled
## together the hash, padding, and public key algorithm in a single
## signature algorithm identifier.

## I'd be happy to specify SHA-256 as the optional integrity hash function
## for 3DES if people want that.  I suppose it should be about 224 bits of
## strong hash, more than SHA-1 and less than SHA-256.  But in XMLDSIG
## there was a lot of fulminating against providing a truncation option for
## SHA-256.

## The XML Encryption Algorithms section was meant to specify only
## AES-128 and so it does, I believe, match SHA-256.
## If people would like me to add AES-196
## & 256, I'm certainly willing to do so, with appropriately sized optional
## hashes for integrity, which is why I made this a parenthetical question
## in the draft.

## You don't seem to like most of the SHA hashes, but frankly I don't think
## you are going to get anywhere on changing to something else unless you
## propose specific alternatives.

## Triple DES, which I refer to as 3DES and FIPS 46-3 refers to as TDES,
## is specified by ANSI X9.52.  The FIPS document just references the ANSI
## specification.  While no doubt you are infinitely more brilliant and
## learned than I am in these matters, I actually was aware that there
## are different modes for using 3DES.  I had thought that where I specify
## 168 bits of key, people could figure out I was talking about 3
## independent keys.  I had intended to simply invoke the 3DES CBC mode
## from the ANSI document, which I believe is EDE.  On searching FIPS 46-3
## I am unable to find a reference to EDE or EEE.

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).

## I explicitly disclaim completeness for that description and am aware that
## it requires a hash.

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).

## The intent is to specify an algorithm similar to that in RFC 2631.

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.

## I'm certainly willing to change this stuff if the consensus of the
## working group is to do so.  But it is my impression that the WG,
## in many cases wants to do THE SAME CRYPTO people are currently
## do for S/MIME which is based on CMS (RFC 2630 and replacement drafts
## in progress).

CMS Triple DES Key Wrap. This is also designed very poorly. By adding a
parity bit to the 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.

## See above comment re using CMS/S/MIME crypto.

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.

## Well, perhaps your arguments will persuade people to change and
## perhaps not.  The lack of choice of chaining modes is quite
## deliberate, with the intent in the current draft of restricting
## to only one.

## If the threat is tampering with the CipherData or the
## use of the wrong decryption key, why doesn't a hash
## appended to the plain text before encryption, whose presence and
## validity are required by the recipient, and which is sufficiently
## strong, provide integrity protection?  If data is being
## signed/MACed, you can certainly do that, with the authentication
## being over either the plain or cipher text or both and the
## signature/MAC construct being either encrypted or plain text.
## These have different advantages and disadvantages and you can do
## them in various combinations, but it you do, then you would,
## I think, typically not need the optional cheap integrity check
## specified.

                                    Joe

## Thanks,
## Donald

Received on Monday, 14 May 2001 17:05:51 UTC