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
