A question about Camellia

[David Shaw]

On Jan 23, 2009, at 6:49 PM, Robert J. Hansen wrote:

> David Shaw wrote:
>> This has nothing to do with your preference list.  GPG will happily
>> decrypt messages to any cipher, whether it is in your preference list
>> or not, as per the spec:
>
> Yes, which sort of demonstrates the point that the preference  
> mechanism
> is just needless complexity.  It's a recommendation mechanism without
> either enforcement mechanism or standardized semantics.  Should the  
> key
> preference list be Borda-counted with the sender's preferences?   
> Should
> the sender use the first sender preference that's in the recipient's
> preferences?  The last?

The spec is very clear on which preference must be used when it  
matters to the protocol, and explicitly disclaims a choice when it  
does not matter to the protocol.  This gives implementers the  
flexibility to do useful things within the hard limits of the  
protocol.  The semantics are extremely clear, including the places  
where the spec dictates that the implementor can follow his desires.

If I allow (say) 3DES, AES, and Camellia, you can't send me anything  
that isn't 3DES, AES, or Camellia.  If you really really really like  
Camellia best, you can send that, even if I like 3DES better.  Why?   
Because it's *your* message.  You're sending it.  It's your choice  
within the boundaries of what I permit.

Standards are not written by the "Everything not forbidden is  
compulsory" ants.  OpenPGP lays down the law where it matters, and  
steps back when it makes no difference to the security of the protocol.

> If I send 3DES to absolutely everyone, then I'm still respecting their
> preferences, even if I never bother to read their preferences.  That
> seems pretty weird to me.

Why weird?  Every OpenPGP program supports 3DES (section 9.2).  3DES  
is in every preference list (section 13.2).  You can pick from any  
cipher in the preference list (also 13.2).  Thus, you can send 3DES to  
everyone without reading the preferences, because you know from the  
protocol that you are participating in that every preference list  
always contains 3DES.  Just in case that wasn't clear, the spec even  
mentions this exact case so there can't be any doubt: "Note also that  
if an implementation does not implement the preference, then it is  
implicitly a TripleDES-only implementation."

>  If I give you a plate of General Tso's
> chicken without even asking you what sorts of food you like, I don't
> think it's reasonable for me to say I've taken your preferences into
> account.

Computers, lucky us, are not people.  Still, if I told you ahead of  
time that I would accept General Tso's chicken, a hamburger, or a  
piece of pizza, and then asked you to choose, I should be quite  
content with General Tso's chicken, even if I really wanted pizza.   
Our "protocol" requires that.

> This should also explain why I care so little about preference  
> lists.  I
> don't care if someone wants to send me AES256, IDEA, 3DES or CAST5
> traffic.  IMO, they're all perfectly defensible choices.  But I care a
> lot about the complexity generated by supporting all those ciphers.

I believe this is shortsighted.  Simple is good, but too simple is  
inflexible.  "Make everything as simple as possible, but not  
simpler."  When MD5 bit the dust, OpenPGP had several algorithms to  
switch to (note that PGP 2.x did not).  When SHA1 was broken, OpenPGP  
could almost shrug that off.  I say 'almost' because of the hard-coded  
fingerprint issues - which also helps prove my point.  If fingerprints  
were not hard-wired to SHA-1, the OpenPGP WG would not now be trying  
to figure out a new fingerprint scheme.

OpenPGP benefits from the flexibility of being able to use multiple  
algorithms.  Note that I'm also not saying which algorithms - like  
you, I don't actually care all that much which are chosen, but I do  
strongly care that the protocol as a whole can support different  
algorithms safely and allow for changes without breaking things.  This  
ability, to me, is necessary complexity.  Take the case of TLS 1.1: it  
has MD5 and SHA-1 hard-wired throughout the design.  Now that it's  
time to move away from those hashes, the TLS 1.2 designers had to do a  
lot of painful hard work (causing much code complexity and  
compatibility problems) to un-wire them.  It may be years before TLS  
1.2 is really widely supported, and in the meantime TLS users are  
going to use MD5 and SHA-1.  (There is interesting thread on this  
right now on the cryptography mailing list, by the way).

> (As
> an example, look at what happened with Elgamal signing keys.  That bug
> would have never been introduced if the GnuPG devs had said "Elgamal
> signing keys are rare, they're not required by the spec, and we're not
> going to support them.")

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.

Once you accept the idea that protocol algorithm flexibility is a good  
thing (if you do), then you realize it doesn't really matter terribly  
much which algorithms are in or out of the protocol, or even how many  
there are.  If you like an algorithm, you use it.  If you don't, you  
don't.  If you want smaller code or simplicity, you simply leave out  
whatever you want to leave out.  4880 helpfully states what is  
required (DSA, Elgamal, and 3DES, basically).  Everything else is  
optional - the protocol does not require any of them.  The main thing  
the protocol requires is that there is a concept of multiple  
algorithms and the tools for dealing with that.

> What I want is simple: a smaller GnuPG codebase and a smaller OpenPGP
> standard.  Changing my preference list will not advance either cause  
> one
> iota, so I don't see the point in changing things.

It does tend to argue against what you desire though: if you are  
advocating that everyone in the community use a smaller algorithm  
list, it does not really help your case when you don't use that  
smaller list yourself, "proving" that it is workable in practice.

We had something close to what you describe though: RFC-1991, the old  
PGP 2.x protocol.  It broke badly when MD5 broke badly (it was already  
pretty broken).  It wasn't flexible enough to adapt.

> If you can think of a way to use the existing mechanisms of RFC4880 to
> achieve my goals, I'd love to hear it.  Maybe there is some way to  
> do it
> yet and I've just been too dumb to see it -- it's been known to  
> happen.

Sure, just remove any algorithm you don't want.  The protocol in 4880  
guarantees that you have the ability to do this:

  ./configure --disable-blowfish --disable-cast5 --disable-(etc)

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. :)

Despite the joke, I'm really not kidding.  I added the --disable-xxx  
flags because while I believe strongly that OpenPGP needs the  
*ability* to handle multiple ciphers, I also believe just as strongly  
that nobody should be forced into an algorithm they don't want used.   
Set those flags, and you have a smaller codebase (the code is actually  
left out of the build altogether) and smaller standard (you can ignore  
any references to those ciphers in the standard).

David