Changing preferences

[David Shaw]

On Thu, Sep 18, 2008 at 02:30:29PM -0400, Mark H. Wood wrote:
> On Thu, Sep 18, 2008 at 01:07:39PM -0400, David Shaw wrote:
> > On Thu, Sep 18, 2008 at 08:23:21AM -0500, Kevin Hilton wrote:
> > > I think the problem is with the word preferences.  The use of this
> > > word in the setpref command and in the
> > > personal-cipher/hash-preferences really doesn't convey what
> > > preferences are preferred over each other.  The sender's preferences
> > > always trump the recipient's preferences.
> > 
> > This is not true.  GPG will never use a cipher that the recipient does
> > not prefer.  It may not use the recipient's #1 choice, but it will
> > always use something from the recipient's list.
> 
> True, not true -- it's not *clear*.
> 
> It sounds like GPG will find the intersection of the sender's and
> recipient's cipher lists and then take the sender's "preference" from
> that list -- that is, the first member of his list which is in the
> intersection.

No.  GPG finds the intersection of all of the recipient cipher lists,
and then picks one from that intersection.  That's it.  It may not be
clear because people keep thinking the sender is somehow involved in
this.

> > It's not always simple to calculate what cipher should be used.  For
> > example:
> > 
> > Alice:   AES256 TWOFISH
> > Baker:   TWOFISH AES256
> > 
> > Who wins?
> 
> Good point.  If Alice sent the message then I would expect AES256 to
> be selected; if Baker, then TWOFISH.  An exchange will alternate
> ciphers.  Correct?

I wasn't clear enough.  I was imagining the message was sent by
Charlie, and both Alice and Baker are only recipients.  There is
nothing to pick a "winner" here.

> Who *should* win?  That question, if it must be answered, sounds like
> it belongs to the OpenPGP WG.

It was answered in 4880:

  When encrypting to more than one recipient, the implementation finds
  a suitable algorithm by taking the intersection of the preferences
  of the recipients.  Note that the MUST-implement algorithm,
  TripleDES, ensures that the intersection is not null.  The
  implementation may use any mechanism to pick an algorithm in the
  intersection.

Note what that says and what it doesn't say.  Firstly, it says nothing
about the sender.  That is appropriate, as the sender (unless they are
also a recipient) is not really relevant here.  Note also that the
"implementation may use any mechanism to pick an algorithm in the
intersection".  In other words, in the Alice/Baker example above,
AES256, TWOFISH, and 3DES are equally valid.

GPG, in an effort to give senders a bit more control, has the
personal-*-preferences lists.  This is legal because of the "any
mechanism" language above.  It basically lets the sender pick from
within the list that the recipients generate, and not incidentally
"ban" certain ciphers from use by not mentioning them.

> But how much do we care?  Two parties who can communicate at all (that
> is, have at least one "preferred" cipher in common) will always do so
> using one of the ciphers they are both willing to use.  Is that good
> enough?

I think it is.  The point is to communicate and agree on *any* common
cipher (even if it ends up being 3DES), and the preferences system
ensures that can happen.

For those people who really care that they only use certain ciphers,
that's what personal-*-preferences is for.

Sure, it would be possible to implement a weighting scheme so that in
cases like:

  Alice:   AES TWOFISH CAST5
  Baker:   TWOFISH AES CAST5
  Charlie: CAST5 AES TWOFISH

...we'd pick AES, because it was the most "popular" cipher.  Does this
really buy us very much?  By listing those three ciphers, Alice,
Baker, and Charlie have already indicated their willingness to receive
traffic encrypted by *any* of the three.  If they didn't want to get
traffic with (for example) TWOFISH, they shouldn't have listed it in
their preferences.

> There seems to be confusion over whether to treat cipher preferences
> as lists or sets.

OpenPGP doesn't care either way.  The "any mechanism" wording ensures
that.

David