Re: W3C Encryption Support for DES, RC2, and RC4 Symmetric Encry ptio n Algorithms

RE: W3C Encryption Support for DES, RC2, and RC4 Symmetric Encryptio n
Algorithms----- Original Message -----
From: Ahmed, Zahid

> Hi Don,
> I agree that we should any new encryption URIs in the
> draft-eastlake-xmldsig-uri-02.txt document.
> Specifically, we should seriously consider adding:
> 1) URI for "DES/CBC/XMLENCPadding" i.e, 56-bit DES encryption;
>    e.g., <some-base-URI>/xmlenc#des-cbc

I don't think that DES should even be offered as an endorsed algorithm. If
there was a significant quantity of legacy applications that were already
using DES with XML-encryption, then there would be a solid argument for
keeping it is a future generation of the standard. However, there are no
such applications, this is a version 1 specification and adding algorithms
that are already known to be broken would seem to be a somewhat backwards
step in terms of security. I hold the same opinion about all ciphers that
have a key size under 80 bits (and some that are over).

> Furthermore, it is not clear if RC4 and RC2 URIs
> are standardized for XML encryption enabled applications.

There has actually been quite some discussion regarding stream ciphers and
RC4 in particular. IIRC the primary argument for adding a stream cipher was
to show how one would go about doing it. RC4 was the selected candidate for
this, but because of security issues, it was dropped, primarily because
making it secure requires significant additional overhead above and beyond
that required for block ciphers.

> If not already standardized, I recommend that we
> also add them:
> 2) URI for RC4 56-bit and 128-bit encryption;
>    e.g., <some-base-URI>/xmlenc#rc4-56
>            <some-base-URI>/xmlenc#rc4-128

The biggest question is, how do you add an IV into it? If you do it through
concatenation it is subject to attack, specifically it is attacked like WEP.
If you perform extra processing to eliminate that attack, there are methods
of distinguishing RC4 from random that are feasible
(http://www.ciphergoth.org/crypto/rc4/). This makes RC4 with any length key
at least questionable in terms of security. It falls into a grey area
because it is desirable to have at least one stream cipher to show how it
could be reasonably added, but it fails in the security requirements.

> 3) URI for RC2 56-bit and 128-bit encryption;
>    e.g., <some-base-URI>/xmlenc#rc2-56
>            <some-base-URI>/xmlenc#rc2-128

What would be the point? The only reason I can see for adding RC2 is that it
is widely used in S/MIME (although it's rarely if ever used anywhere else),
but it is horribly slow (slower than 3DES), is less examined than 3DES, is
less trusted than 3DES, and is less used than 3DES. I can see no problem
with putting it in an additional source for URIs, since I cannot immediately
find mention of a successful attack against it, but only for the 128-bit
version. If we're going to start adding every conceivable algorithm to the
URI space for this, there's a sizable list of algorithms of various types at
http://www.eskimo.com/~weidai/benchmarks.html , most of which are not
supported, and most of which there is little reason to support.
                    Joe

Received on Wednesday, 19 June 2002 20:24:25 UTC