Changing preferences

[David Shaw]

On Sep 18, 2008, at 6:30 PM, Robert J. Hansen wrote:

> David Shaw wrote:
>> The preferences on the keys are used by people encrypting a message
>> *to* those keys.  It indicates that algorithms the keyholders prefer.
>
> If AES256 is listed first in personal-cipher-preferences, it doesn't
> matter if AES256 is listed first in the recipient's keyprefs or last;
> AES256 is what will be chosen.

Correct.  The sender is king here, and what the sender prefers is more  
important than what the recipient prefers.  Note, though, that the  
sender cannot prefer a cipher that a recipient does not prefer.  The  
recipient must be at least willing to accept the cipher or the sender  
cannot prefer it.

> Since the ordering of the recipient's keyprefs have absolutely no  
> effect
> on the ultimate selection of the algorithm, it seems pretty clear to  
> me
> we're talking about a capability set as opposed to a preference list.
> Preferences are ranked lists; in the absence of that ranking, all  
> we're
> talking about is an unranked set of acceptable algorithms.
>
> Unless, of course, I have completely misunderstood how GnuPG selects
> algorithms.  Which is always a possibility.

4880 says "The symmetric algorithm preference is an ordered list of  
algorithms that the keyholder accepts." so the spec is an ordered  
list.  The spec gives implementations a fair bit of leeway in  
interpreting this ordered list, and so anything from scoring each  
algorithm and choosing the one with the best score to arbitrarily  
picking the 3rd item every time is valid, in terms of the standard.

GnuPG in particular works like this:

1) Take the intersection of all recipients preference lists.  This  
rules out any algorithms that would be unusable by someone.
2) Elect a "decider".  The decider is the one person whose ordered  
list we will honor the rankings for.  If the user has specified a  
personal-*-prefs list, then the user is the decider.  If the user has  
not specified a list, then the last recipient key is used.
3) Walk the decider preference list from highest ranked to lowest  
ranked - as soon as we hit an algorithm that is part of the  
intersection from step #1, stop.

For example:
  Alice has AES CAST5 TWOFISH
  Baker has CAST5 AES BLOWFISH
  Charlie has BLOWFISH AES CAST5
  Donald has CAMELLIA TWOFISH BLOWFISH

Assuming that there is no personal-*-prefs list set), here's how it  
falls out:

   Alice Baker Charlie == AES
   Baker Alice Charlie == AES
   Charlie Alice Baker == CAST5
   Charlie Alice Baker Donald = 3DES

David