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

      Joseph:

      The major reason IMHO why anyone would want to use some of these
algorithms which are 64 bits or less would be that no stronger algorithm is
available in both the encryptor's environment and the decryptor's.  The
legacy that matters in this case consists of legacy crypto libraries since
obviously there's no legacy of XML-encrypted documents.  DES is also faster
than 3DES, of course, but that's not a very strong reason.
      My own point had to do with PBE because of its key exchange and
storage characteristics.  I don't think we should try to add every PBE
variant in PKCS#5 and PKCS#12, let alone all others which have ever been
defined.

            Tom Gindin


"Joseph Ashwood" <ashwood@msn.com>@w3.org on 06/19/2002 08:20:04 PM

Sent by:    xml-encryption-request@w3.org


To:    <xml-encryption@w3.org>
cc:
Subject:    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 Thursday, 20 June 2002 07:53:41 UTC