RE: 2nd try at Algorithms Section

Experience of reviewing the 802.11B WEP spec has left me somewhat down on
stream ciphers...

The problem with specifying a stream cipher is that the security of any
stream cipher is critically dependent on the encryption key being unique for
each operation. If XML encryption is to be promoted as a building block for
cryptographic protocols it really needs to address stream ciphers
comprehensively if at all and make sure that people have to work at the
incompetence to fail.

If we leave out stream ciphers completely there is a risk that people will
roll their own leading to incompatible implementations and broken
implementations.

If we address stream ciphers we risk encouraging their use. I really don't
see that the difference between 6 clock cycles and 8 clock cycles is a
sufficient incentive given the history of faulty use of stream ciphers in
protocols.

I guess my preffered outcome would be to describe a secure method of using a
stream cipher but specify that implementations SHOULD NOT use it.

		Phill


Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


> -----Original Message-----
> From: Joseph Ashwood [mailto:jashwood@arcot.com]
> Sent: Wednesday, May 23, 2001 2:50 PM
> To: xml-encryption@w3.org
> Cc: Eastlake III Donald-LDE008
> Subject: 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
>