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


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Reply via email to