Re: 2nd try at Algorithms Section

----- Original Message -----
From: "Jim Schaad" <jimsch5@home.com>

> > There are reasons for tossing the silly parity bits. Their presence
> > leads to additional complexity in generating them and sometimes in the
> > harmful checking of them. (Note the famous case of the secure telnet
> > implementation which generated DES keys with all zero parity bits but
> > then called crypto routines which ignored the key if the parity was
> > wrong and just encrypted with a zero DES key. This meant that 255 out
> > of 256 times, you wre encrypting with a constant known key. Of course
> > the data looked random and this implementation interoperated fine with
> > itself,which was how it was normally used. It was in use for years
> > before anyone noticed.) However, if it is really that inconvenient for
> > many people to eliminate the parity bits due to the crypto library
> > they are using or whatever, I'll change it.
> >
> > I see no harm in the one sentence which tell you what's going on with
> > EDE. This document has some limited details on algorithms so someone
> > generally familiar with modern crytography can tell what's going on,
> > rather than a terse "algorihm X as defined in document Y".
>
> Implementers please comment on this.  I know that it would lead to
potential
> problems when used with the Microsoft CryptoAPI as the existing code used
> with CMS does not operate in this manner.

All the implementations I commonly deal with (4 of them)  offer the option
of using a 168-bit key, I would be happy with a 168-bit key, or even a
112-bit. I have actually already written the strip the parity bits out code
so I can use "proper" 3DES keys with one of them. I would be very happy with
a 168-bit key.

> > >6. Section 5.3.1:  I firmly believe that changing the
> > chaining mode changes
> > >the algorithm and a new URI should be assigned.  I also would like
> > >information such as the chaining mode to be included in the
> > URI so I prefer
> > >the text "xmlenc#3des-ede-cbc" for the name.
> >
> > This is a spectrum. After all, why stop with 3des-ede-cbc? What about
> > the padding? What about the type of CBC? As I recall, there are really
> > four different ways to do CBC.  I really can't see any reason anyone
> > would bother with other that EDE so I'm not willing to stick that in
> > unless there is a clear consensus to do so.  I suppose we could add
> > "-cbc" but I'm inclined to have it be the default and add a suffix
> > if/when a different chaining mode algorithm is ever defined.
>
> Honestly, I have no problems with specifing the padding mode as well.  I
can
> agree with omitting the -ede but would prefer to see the ECB as the
omitted
> chaining mode if there was one.  I can live with omitting the -cbc but do
> not care for it.

Ok so we've got 3 people that like keeping the -cbc (I appreciate it also).
The type of padding to use is a continual discussion in cryptography,
ranging from truncation, to PKCS, to cipher-text stealing, to . . . . Any of
them is actually acceptable, and for some chaining modes it's completely
unnecessary (counter mode is one example), just pick one, ciphertext
stealing is the chain du hour.
                        Joe

Received on Wednesday, 6 June 2001 14:54:57 UTC