Re: 2nd try at Algorithms Section

I'm replying to this one because it is more convenient to point out where I
disagree, then to explain my entire position again.

----- Original Message -----
From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com>
To: <xml-encryption@w3.org>
Cc: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com>
Sent: Wednesday, May 23, 2001 9:12 AM
Subject: RE: 2nd try at Algorithms Section


> (1) Should a stream cipher be added?

I think one should be added as optional. I have a couple of reasons:
1) If we choose one like RC4, there is a significant boost of speed to be
found that way. A half dozen clocks per byte is not impossible with RC4, but
AES takes > 8 clocks per byte.
2) I think indicating how one needs to be specified could help eliminate
future problems, and is more likely to develop a proliferation of stream
ciphers in the spec.

> ## Blum Blum Shub has interesting security properties but is
> computationally intensive, while the usual idea of stream ciphers
> is to be fast. I've never heard of BBS being supported as a
> normal option in any widely deployed system. I'm against it.

It doesn't have much demand, that much I certainly agree on. It's absurdly
slow, but it is provably secure. To me it clearly should only be added after
RC4, if at all. I suspect not at all.

> ## My conclusion: Adding RC4 as Optional would be OK, though I don't
> feel that strong either way.

I think "ARCFOUR" would be a good idea, it's among the fastest algorithms
known, it's not the most secure, but it's highly trusted. If we don't add it
there will be numerous people that ask why it wasn't added. I think overall
it will make for fewer headaches with other people to just add ARCFOUR.

>
> (2) Should we add a European hash algorithm or algorithms such as
> RIPEMD-160?

I think adding diversity away from just the usual SHA suspects will help
avoid having all the algorithms broken. The entire SHA series has quite a
bit of inner similarity, so if one is broken it's likely that all of them
will be. RIPEMD-160 is sufficiently different from SHA-160 that if one
breaks the other is not likely to.

> (4) On the Symmetric Key Wrap algorithms, I have assumed that the
> consensus is still to follow the CMS algorithms exactly. However,
> especially now that I have written it up, it seems very odd that we have
> RC2 CMS wrap mandatory, which requires the implementation of the RC2
> cipher, when that ciper isn't even optional for data encrytion. Should
> this be made consistent and if so how?
>
> ## The current situation in the spec makes no sense. Requiring
implementation
> of RC2 just for key wrap while not including it for data encryption makes
> no sense from the point of view of limiting the code load on small
devices,
> etc.  Is RC2 encumbered?  If so, I would definitely say to toss it.  If it
> is unencumbered, I could see making BOTH RC2 key wrap and RC2 data
encryption
> Optional.

RC2 is unencumbered (it's published as an RFC), but it's far from the best
available. RC2's main advantage has always been the ease with which you
could change the key size, with no effective export restrictions stopping
us, I can see little reason to support RC2, especially since we already has
3DES, and AES-128 as mandatory, and AES-192/256 as optional. As a
cryptanalyst I can tell you that I believe any of the AES finalists is at
least as secure as RC2.

> (5) Additional Block Ciphers. It has been suggested that all the other
> AES finalists be added as at least optional except possibly RC6 which is
> encumbered.  (I suggested that, since we already have 3DES and AES, we
> add a block cipher that was a composition of them but there seems to be
> no net support for that which was probably a bad idea.)
>
> ## Forget encumbered stuff like RC6. Of the other three (Twofish, MARS,
> and Serpent), I don't see much reason to choose between them and adding
> three is excessive so I suggest we leave it as it is.  (If there had
> been an announced "runner up" or 2nd place AES winner, I'd say we should
> add it as Optional, but there isn't.)

While there was no announced 2nd place, each of them had their position.
Coppersmith came out and said (to paraphrase) "MARS is designed to be
reistant to attacks that the other authors do not even know the existance
of". Inspite of this MARS is basically a kitchen-sink cipher, it's slow it's
ugly, it's not exactly designed elegantly. The concensus among cryptanalysts
was that the only real finalists were Rijndael (which won), Twofish, and
Serpent. Of those Twofish is the most balanced among all hardware types,
it's efficient to implement on pretty much everything. Serpent has a
security margin that is put simply enormous (barring brute force, the best
known attack takes 2^340 time). Each of these (Twofish/Serpent) has, in my
opinion, a rightful claim to being the second best. I think if we want to
add an extreme security cipher Serpent would the most reasonable option, but
also one of the slowest (900+ clocks per block). If we have to choose only
one to complete the scale, I'd choose Serpent.

> (6) Additional chaining modes. It has been suggested that at least
> provision be made for specifying other chaining modes (other than by
> definining new URIs) and/or that a counter mode be added.
>
> ## CBC is clearly the dominant chaining method now. If and when there
> is enough demand for an alternative, it can be added via new URIs.
> I don't think we need any change here.

The problem I have with this is the exponential growth of the list. I will
continue to hold that I believe it should be done a different way, but I
realize that because CBC is the vastly dominant mode, and that there will be
future versions of this specification if the need ever arises to diversify,
or eliminate a cipher, I have no problem with it that I think should hold up
the group.

>
> ## SUMMARY:
> I can see adding ARCFOUR as optional.
I would like to see ARCFOUR as optional.
> I can see adding RIPEMD-160 as optional.
I would like to see RIPEMD-160 as optional.
> We should either drop RC2 key wrap or add RC2 data encryption and
> if we go the add route, I think they should be Optional.
I think we should simply drop RC2 in general.

I don't think any other changes need to be made.
                            Joe

Received on Wednesday, 23 May 2001 14:50:52 UTC