Re: Early Draft Algorithms Section

----- Original Message -----
From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com>
> && See comments at &&
> -----Original Message-----
> From: Joseph Ashwood [mailto:jashwood@arcot.com]
> ----- Original Message -----
> From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com>

> && Does anyone else in the WG have an opinion on including a stream
cipher?


> && By specifying optional ciphers, we are only biasing what will be used.
> && Anyone can generate their own URI identifier and use whatever algorithm
> && they want.

Right, we will bias people towards having those ciphers available, that was
the entire point of specifying them optional. People can supply their own
URI for whatever, but in general they won't. I think we're going to keep
going round on this, so let's just end this part. We disagree on this, and I
don't think there's enough strength in argument on either side to convince
the other.

> && I guess we have different assessments of these things.  I do not
believe there
> && is any fielded system in which 3DES would be the weakest link and I do
not
> && think that situation will change in the next decade or more.

I believe there are encrypted documents where 3DES is the weakest link, in
fact it's the only link. I don't believe we should simply consider the
temporarily encrypted as the only option, there are cases where documents
are encryped now, the key stored in a very secure manner, that we also need
to consider. I do think that outside of the selection of the algorithms this
is mostly a moot point.


> && Given the WG consensus so far that 3DES and AES should be mandatory to
> && implement and a desire to avoid code bloat, what would you think about
> && defining an algorithm that compounded DES and AES?

Depends on how they were combined. I'd be more in favor of 3AES using the
same E(D(E())) setup as 3DES. I think that would eliminate pretty much any
weakness of Rijndael/AES (barring a few catastrophic failures).

> At the very least
> I would like to see MARS, Twofish, Serpent, and RC6.

> && Of those, Twofish I believe is unrestricted. A number of the others
are,
> && I believe, encumbered technology, which should be avoided.

Only RC6 is restricted.
Serpent is now completely in the public domain, and we impose no
restrictions on its use (http://www.cl.cam.ac.uk/~rja14/serpent.html)
MARS is now available worldwide under a royalty-free license from Tivoli
(http://www.research.ibm.com/security/mars.html)
Twofish is unpatented, and the source code is uncopyrighted and
license-free; it is free for all uses
(http://www.counterpane.com/twofish.html)
Rijndael is free by nature of being chosen for AES (it was free before also)


> > I'd suggest Panama,
>
> I would not recommend the use of the Panama hash, it is broken, I don't
know
> why I put it in the list.
>
> > 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
>
> && I think you mean to say "not submitted".

I meant that they had been submitted to public review, but had not been made
into an official standard.


> If I had to pick just one has to be added I would suggest RIPEMD-256, and
> for a new class the entire RIPEMD series. That would serve two very
> important purposes in my opinion. First and foremost it would introduce
> diversity into the integrity specification. The second function would be
to
> remove the US centricity from the integrity functions, this will make it
> more likely to be adopted in Europe where the RIPEMD series is very
popular.
>
> && It is my understanding that RIPEMD-256 and RIPEMD-320, while they
> && provide more hash bits, are in fact not designed to actually be any
> && stronger than the 128 and 160 bit RIPEMD hashes.

I didn't choose it strictly from a security standpoint, although they are
well designed. I chose that series in particular because it is a favorite
outside the US. If you don't like RIPEMD maybe HAVAL would be more your
style? Mostly i'd just like to see some diversity inserted into the spec for
the hash functions, and I see a real opportunity to make more people
comfortable with the spec not being overly US-centric.

> && I assume what you mean is orthogonally specifying the chaining mode.
> && With our current syntax, I think that would mean an element content
> && of EncryptionMethod.  So you would have something like
> && <EcnryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes">
> && <Chaining>Counter</Chaining>
> && </EncryptionMethod>
> && Seems simpler to just have http://www.w3.org/2001/04/xmlenc#aes-cbc
> && and http://www.w3.org/2001/04/xmlenc#aes-counter URIs. Even if there
> && are 4 or 5 algorithms and 3 or 4 chaining modes, your talking a pretty
> && small table here.

There's not likely to be much demand for anything outside of CBC and
counter, and the chaining mode is rarely a major consideration (if it is
then they are free to define the URI themselves), so that's agreeable to me.
It would also be agreeable to me, to streer them towards a preferred
chaining mode (like CBC) by giving it the URI
http://www.w3.org/2001/04/xmlenc#aes. Since CBC has a proof of security, a
long standing history, etc I don't think anyone will complain too much if
it's the default.
                                    Joe

Received on Thursday, 17 May 2001 14:37:59 UTC