Re: Early Draft Algorithms Section

I did not intend any post of mine to be a personal attack. I appologize if
it is interpretted that way.

----- Original Message -----
From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com>
> ## Hi, See comments preceded by ##

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

Well there are some desirable properties to stream ciphers under some
circumstances. (please not I will only be talking about common stream
ciphers, so I will drop the use of the word common) Normally this is reduced
to speed, but stream ciphers also give us the ability to precompute the
stream, and in some cases proofs of security (e.g. BBS). Sometimes these
will outweight any contribution that could be supplied by the known block
ciphers. To this end I propose the addition of 4 algorithms that fall into
the category of stream ciphers:
OTP with XOR as a combiner (required)
ARCFOUR/ARC4/RC4 with XOR as a combiner (recommended)
BBS with XOR as a combiner (optional)
ISAAC with XOR as a combiner (optional)

The logic behind requiring OTP is that each of the others can be reduced to
it with some extra prework. In particular by precomputing the stream, and
treating it as a OTP. The others being optional stems from this, and that it
remains very easy to seperate the stream generator from the
encryption/decryption process. Because of notation issues with OTP, I would
certainly consider it acceptable to drop it, and not require any stream
cipher.

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

With the large selection of ciphers that is available, I don't think having
a unified list is appropriate. Just as a beginning Crypto++ has 39 symmetric
key algorihms, most of which will almost certainly be used with XML Enc in
some form. There are also 14 hash functions. Using a unified selection gives
546 (39*14) entries just in the selection process, without even counting the
unkeyed MAC functions. Going with a 2 phase setup, one for authenticator,
one for encryptor results in 53 entries (again without MAC functions), a
savings of over 90% in space.

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

Actually 3DES only offers 2^90 work making it fit with a 180-bit hash.

> ## But in XMLDSIG
> ## there was a lot of fulminating against providing a truncation option
for
> ## SHA-256.

I agree with that, there's no reason to do work, and then discard it.

>
> ## The XML Encryption Algorithms section was meant to specify only
> ## AES-128 and so it does, I believe, match SHA-256.

The problem is that AES is to be specified as requiring the implementation
of 192 and 256-bit versions. By specifying only the 128-bit version we
precisely and completely break the specification.

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

I'd skip the SHA-384 usage for the same reason that I wouldn't want SHA-256
truncated to 224 bits. SHA-384 is SHA-512 with the last bits removed. In
spite of this I would very much support the addition of 192 and 256-bit
Rijndael (soon to be called AES) to the standard. I would also support the
addition of Serpent, Twofish, MARS, RC6, RC5, SKIPJACK and several others as
optional (I'd actually rather see Twofish and Serpent as recommended)

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

I'd suggest Panama, Tiger, RIPEMD, HAVAL instead. It's not that I don't like
them, it's that reliance on algorithms that have been submitted for public
review before being standardized is not the most reasonable thing to do. The
extended SHA series is relatively new, and relatively unstudied so it should
not be trusted for anything critical, by binding encryption algorithms to
hash functions we restrict ourselves even further in this direction.

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

Regardless the FIPS is the authoritative document. The DES name (and all
derivitives) is the property of the US Government, and they have documents
specifying them, as such those are the authoritative documents. Their
decision to reference an external document does not remove the
authoritativeness of the FIPS.

> ## On searching FIPS 46-3
> ## I am unable to find a reference to EDE or EEE.

EEE refers to the model of Encrypt, Encrypt, Encrypt. EDE is Encrypt,
Decrypt, Encrypt. The primary mode is EDE, and apparently (I just downloaded
a new copy since mine was a prepress) the fips standard only specifies EDE
mode, and only with 3 keys.

> The Diffie-Hellman specification needs to be completed, but it cannot
> ## The intent is to specify an algorithm similar to that in RFC 2631.

I'd personally rather see it parameterized by the distillation function to
be appplied afterward (this will commonly be a hash function), and to make
it's implementation with SHA-1 and SHA-256 required.

>
> 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).
[snip my comment about CMS ...]
> ## See above comment re using CMS/S/MIME crypto.

I'd rather see something secure. The crypto people didn't do CMC, it was
published without our input, and suffers several rather severe flaws, many
of which have been ignored to this day. I'd personally rather see this group
come up with something secure from the beginning.

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

Restricting the chaining modes is pure folly. While CBC is the chain du
jour, it has significant problems. There needs to be different options. For
example IBM has two proposals to the AES modes operation that offer almost
free authentication, and strong chaining. PCBC offers advantages over CBC in
every category except speed. I have personally chosen ECB for some things
because it would be the strongest mode (the data was already inherently
random so any other chaining mode could only have induced problems). Counter
mode is almost guarenteed to be the most desired mode for AES. Feedback
modes offer vast lists of advantages in certain environments. The list goes
on for a long time, CBC is not the end all, and neither is any other
chaining mode.

Received on Monday, 14 May 2001 18:49:50 UTC