La préférence d’un algorithme symétrique est une liste ordonnée d’algorithmes acceptés par le propriétaire de clé. Puisqu’elle est fournie avec une auto-signature, il est possible pour un propriétaire de clé de posséder différentes préférences. Par exemple, Alice peut avoir le TripleDES spécifié seulement pour « alice@work.com » mais le CAST5, le BlowFish et le TripleDES de spécifiés pour << alice@home.org >>.
Noter qu’il est aussi possible que des préférences de se situent dans la signature liante d’une sous-clé.
Puisque le TripleDES est l’algorithme devant être implémenter obligatoirement, si celui-ci n’est pas explicitement situé dans la liste, il y sera ajouté à la fin de manière implicite. Noter aussi qu’une implémentation qui n’implémentent pas la notion de préférence implémentera uniquement le TripleDES de manière implicite.
Une implémentation NE DOIT PAS utiliser un algorithme symétrique n’étant pas dans la liste de préférence du destinataire. Lors d’un chiffrage pour plus d’un destinataire, l’implémentation fournira un algorithme adéquat en prenant l’intersection des préférences de ces destinataires. Noter que l’algorithme devant être implémenté obligatoirement, TripleDES , assure une intersection non nulle. L’implémentation peut utiliser n’importe quel mécanisme pour choisir un algorithme dans l’intersection.
Si une implémentation peut décrypter un message que le propriétaire de clé ne possède pas dans ses préférences, il serait souhaitable que l’implémentation décrypte tout de même le message, mais elle DEVRA alors OBLIGATOIREMENT avertir le propriétaire que le protocole a été violé. (Par exemple, supposons qu’Alice, mentionné plus haut, possède un logiciel implémentant tous les algorithmes de cette description. Néanmoins, elle préfère des sous-ensembles correspondants à son travail ou à sa résidence. Si elle reçoit un message chiffré par IDEA, qui n’est pas dans ses préférences, le logiciel l’avertira que quelqu’un lui a envoyé un message crypté par IDEA, mais dans l’idéal, il le décrypterait.)
Une implémentation s’efforçant de respecter la compatibilité descendante pourra considérer une clé V3 avec une auto-signature V3 comme une préférence implicite pour l’ IDEA, sans aucune compétence pour faire du TripleDES. Cela ne respecte pas les règles techniquement mais une implémentation PEUT violer la règle précédente dans cet unique cas et utiliser IDEA pour crypter le message, à condition que le créateur du message soit prévenu. Pourtant, dans l’idéal, l’implémentation suivrait la règle en générant en fait deux messages, car il est possible que l’implémentation de l’utilisateur d’OpenPGP ne possède pas IDEA et qu’il ne puisse ainsi pas lire le message. Par conséquent, une implémentation PEUT, même si ce n’est pas souhaitable, utiliser IDEA dans un conflit d’algorithme avec une clé V3.