A question about Camellia

[Robert J. Hansen]

David Shaw wrote:
> OpenPGP benefits from the flexibility of being able to use multiple
> algorithms.

The ability to use multiple algorithms is independent of how many
algorithms are in the spec and in each implementation.  Algorithm
agility is a great idea and I think protocols ought be designed with it
in mind; but at the same time I think protocols ought to focus on a
minimal set of algorithms.

An extension mechanism is a great idea.  I don't think that should be
carte blanche for a spec throwing the kitchen sink into the RFC, though.

> I think this is actually a good example for my point as well (I love an
> example which points out multiple things): Note when the Elgamal signing
> key bug happened, it did not take down the rest of the protocol.  People
> with RSA or DSA signing keys kept right on chugging.

Yes.  We're in total agreement that algorithm agility is a good idea.

> It does tend to argue against what you desire though: if you are
> advocating that everyone in the community use a smaller algorithm list,

Looking over RFC4880, 3DES is the only MUST symmetric cipher, but it
makes mention of Twofish, Blowfish, CAST, IDEA and AES.

Better, in my mind, to reduce this to 3DES (or AES, take your pick,
algorithm agnosticism and all).  Move the others to an appendix.  Note
them for history and interoperability with old versions, but encourage
implementors to not use old algorithms for new traffic unless there is a
compelling reason not to.

I don't see how to use preference lists to argue for that transformation
in how the implementor community views the standard.

> I promise you that if you remove an algorithm, any bugs in those
> algorithms, be they implementation problems or design flaws, will never
> affect you. :)

This is actually what I do.  If someone sends me traffic that's
encrypted with an exotic, well, I'll use my system's GnuPG (as opposed
to the one living in $HOME/bin) to decrypt it.




... I'm motivated, to some degree, by my own frustrations in
implementing RFC2440 for a telco back in '99.  My implementation was
simple: 3DES, SHA1, DSA/ELG, no compression, no MDC, no nothing, but it
was -- as far as I could tell; it's been ten years, please understand my
memory isn't perfect -- standards-conformant.  I could send traffic to
PGP and GnuPG, PGP and GnuPG could, with the proper settings, send
traffic to me.  Success.

It was not enough of a success for Management.  They insisted on
supporting IDEA, CAST, MD5, RIPEMD160, etc. -- when I got knocked down
on a performance review because I hadn't yet implemented double-width
SHA or HAVAL, I knew they were viewing each and every algorithm as a
checkbox. [*]

This is obviously far, far more a failing of management than a failing
of the spec.  That said, I think the spec contributes to this kind of
misreading and misunderstanding.

This bit of work history anecdote should not be read as any kind of
argument for or against anything.  It's just a where-I've-come-from sort
of thing.  That said, if you ever have the chance to write software for
the telephone company, don't.



[*] For people on the list who don't remember the state of the RFC from
the '99-'00 era, double-width SHA and HAVAL were mentioned in RFC2440.
To the best of my knowledge, though, nobody ever actually implemented
them.  (In the case of double-width SHA, I don't know if the algorithm
even existed.)