diff options
Diffstat (limited to 'doc/fr/FAQ')
| -rw-r--r-- | doc/fr/FAQ | 1111 |
1 files changed, 1111 insertions, 0 deletions
diff --git a/doc/fr/FAQ b/doc/fr/FAQ new file mode 100644 index 000000000..48c28ae76 --- /dev/null +++ b/doc/fr/FAQ @@ -0,0 +1,1111 @@ + +GNUPG : FOIRE AUX QUESTIONS + +Version : 1.2 +Dernière modification : 10 septembre 2001 +Maintenu par : Nils Ellmenreich <nils 'at' gnupg.org> +Traduction : Gilbert Fernandes <gilbertf 'at' posse-press.com> + +Ce document est la FAQ de GnuPG. La dernière version HTML est +disponble ici : <http://www.gnupg.org/faq.html> + +L'index est produit automatiquement. Des erreurs peuvent donc +s'y trouver. Toutes les questions ne seront pas situées dans leurs +sections afférentes. Les suggestions quand à l'amélioration de cette +FAQ seront les bienvenues. + +Veuilez envoyer vos additions et corrections au mainteneur de la FAQ. +Il serait plus pratique si vous pouviez fournir une réponse à inclure +directement dans la FAQ. Toute aide sera fortement appréciée. + +Veuillez ne pas nous envoyer de message du type : "Ceci devrait +être une FAQ, quelle est la réponse ?". Si la réponse ne se trouve +pas dans la FAQ c'est que la question n'a pas été considérée. +Dans ce cas, recherchez dans les archives de la liste de +distribution par email. + + + + + 1. GENERAL + 1.1) Qu'est-ce que GnuPG ? + 1.2) GnuPG est-il compatible avec PGP ? + + 2. SOURCES D'INFORMATION + 2.1) Où puis-je trouver plus d'informations ? + 2.2) Où puis-je obtenir GnuPG ? + + 3. INSTALLATION + 3.1) Sur quels systèmes fonctionne GnuPG ? + 3.2) Quel collecteur d'entropie dois-je utiliser ? + 3.3) Comment puis-je inclure le support du RSA et de l'IDEA ? + + 4. UTILISATION + 4.1) Quelle est la taille de clef recommandée ? + 4.2) Pourquoi la création de clefs est-elle aussi longue ? + 4.3) Pourquoi tout est si lent quand je travaille sur un système distant ? + 4.4) Quelle est la différence entre options et commandes ? + 4.5) Je ne peux pas effacer un userid car il a déjà été effacé dans mon + trousseau de clefs publiques ? + 4.6) Que sont la confiance, la validité et l'ownertrust ? + 4.7) Comment puis-je signer un fichier de patch ? + 4.8) Où se trouve l'option "encrypt-to-self" ? + 4.9) Comment puis-je me débarasser de la version et du champ de commentaire + dans la version "armor" des messages ? + 4.10) Que signifie le message "You are using the xxxx character set" ? + 4.11) Comment puis-je obtenir la liste des keyid ayant servi à + chiffrer un message ? + 4.12) Je ne peux plus déchiffrer mon message chiffré symétriquement (-c) avec la nouvelle +version de GnuPG ? + 4.13) Comment puis-je utiliser GnuPG en environnement automatisé ? + 4.14) Quel client email puis-je utiliser avec GnuPG ? + 4.15) On ne peut pas avoir une librairie gpg ? + 4.16) J'ai produit avec succès un certificat de révocation, mais comment dois-je + le transmettre aux serveurs de clefs ? + + 5. QUESTIONS SUR LA COMPATIBILITE + 5.1) Comment puis-je chiffrer un message avec GnuPG pour que PGP soit capable de le déchiffrer ? + 5.2) Comment migrer de PGP 2.x vers GnuPG ? + 5.3) (supprimé) + 5.4) Pourquoi PGP 5.x n'est pas capable de déchiffrer les messages pour certaines clefs ? + 5.5) Pourquoi PGP 5.x ne peut vérifier mes messages ? + 5.6) Comment puis-je transférer mes valeurs de confiance de PGP vers GnuPG ? + 5.7) PGP n'aime pas ma clef privée. + + 6. PROBLEMES ET MESSAGES D'ERREUR + 6.1) Pourquoi GnupG me dit sans cesse "Warning : using insecure memory!" ? + 6.2) Le support des fichiers de grande taille ne fonctionne pas .. + 6.3) Dans le menu d'édition les valeurs de confiance ne sont pas affichées + correctement après la signature des uid : pourquoi ? + 6.4) Que signifie "skipping pubkey 1: already loaded" ? + 6.5) GnuPG 1.0.4 ne tient pas compte de ~/.gnupg ... + 6.6) Une signature ElGamal ne vérifie plus rien depuis la 1.0.2 .. + 6.7) Les anciennes versions de GnuPG ne vérifient pas les anciennes + signatures ElGamal + 6.8) Lorsque j'utilise --clearsign le texte en clair comporte parfois des + tirets supplémentaires : pourquoi ? + 6.9) Que signifie "can't handle multiple signatures" ? + 6.10) Si je soumet une clef au serveur de clefs, rien ne survient ! + 6.11) J'obtiens un "gpg: waiting for lock ..." + 6.12) Les anciennes versions de GnuPG (e.g. 1.0) ont des problèmes + avec les clefs de GnuPG récents .. + 6.13) Avec GnuPG 1.0.4 j'obtiens un "this cipher algorithm is deprecated ..." + 6.14) Les dates sont affichées par ????-??-??, pourquoi ? + 6.15) J'ai encore un problème, dois-je produire un message de bogue ? + 6.16) Pourquoi GnuPG ne supporte pas les certificats X.509 ? + + 7. SUJETS AVANCES + 7.1) Comment tout cela fonctionne-t-il ? + 7.2) Pourquoi certaines signatures avec une clef ELG-E sont valides ? + 7.3) Comment tout le système de confiance fonctionne au juste ? + 7.4) Quel est ce genre de sortie : "key C26EE891.298, uid 09FB: ...."? + 7.5) Comment interpréter certaines sorties informatives ? + 7.6) Les lignes d'en-tête des messages font-elles parties des éléments signés ? + 7.7) Quelle est la liste des algorithmes préférés ? + 7.8) Comment puis-je changer la liste des algorithmes préférés ? + + 8. REMERCIEMENTS + + + +1. GENERAL + +1.1) Qu'est-ce que GnuPG ? + +GnuPG signifie GNU Privacy Guard et <http://www.gnupg.org> est +l'outil GNU destiné aux communications protégées par chiffrement, +ainsi que le stockage protégé d'informations. Ce programme peut +être utilisé pour chiffrer des données et produire des signatures +numériques. Il comprend une gestion avancée des clefs et respecte +le standard Internet proposé OpenPGP comme décrit dans le +RFC 2440 : <http://www.gnupg.org/rfc2440.html> et il se destine +à une parfaite compatibilité avec le PGP produit par NAI Inc. + +1.2) GnuPG est-il compatible avec PGP ? + +En règle générale, oui. GnuPG et les distributions récentes de PGP +devraient respecter le standard OpenPGP et fonctionner de concert. +Il existe toutefois quelques problèmes d'interopérabilité. Consultez +les questions 5.1ff pour plus de détails. + +2. SOURCES D'INFORMATION + +2.1) Où puis-je trouver plus d'informations ? + +Voici une liste de ressources en ligne : + +<http://www.gnupg.org/docs.html> + +Cette page regroupe la page de documentation GnuPG. Vous pouvez consulter +les HOWTO ainsi que le manuel de GnuPG : le GNU Privacy Handbook +actuellement disponible en anglais, espagnol et russe. Ce dernier offre par +ailleurs une présentation étendue de GnuPG. Vous trouverez aussi des +documentations expliquant la conversion de PGP 2.x vers GnuPG. + +<http://lists.gnupg.org> + +Vous trouverez ici une archive en ligne des listes de distribution par +courrier électronique de GnuPG. La liste la plus intéressante sera +probablement gnupg-users où toutes les questions en rapport avec +l'utilisation de GnuPG se trouvent rassemblées. Si le développement +vous intéresse vous consulterez avec joie la liste gnupg-devel et +vous pourrez également prendre contact avec les développeurs. + +S'IL-VOUS-PLAIT ! + +Avant de poster sur une liste, veuillez lire avec attention la FAQ et +toutes les documentations disponibles. D'autre part, vous devez ensuite +consulter les archives afin de découvrir si votre question n'a pas été +déjà posée et résolue. Vous épargnerez des pertes de temps et la +liste pourra se concentrer sur les problèmes qui n'ont pas encore +été résolus. + +La distribution des sources de GnuPG comprend également un +sous-répertoire /doc qui contient des documentations supplémentaires +et ces informations seront précieuses aux hackers (pas beaucoup aux +utilisateurs habituels, sauf les plus curieux). + +2.2) Où puis-je obtenir GnuPG ? + +Vous pouvez télécharger GNU Privacy Guard depuis son FTP primaire : + +<ftp.gnupg.org> + +Ou depuis l'un des mirroirs : + +<http://www.gnupg.org/mirror.html> + +La version actuelle est la version 1.0.6 et nous vous encourageons à migrer +vers cette version rapidement : elle corrige des bogues et améliore le +fonctionnement du programme, ainsi que votre sécurité de fait. + + +3. INSTALLATION + +3.1) Sur quels systèmes fonctionne GnuPG ? + +GnuPG devrait fonctionner sur tous les Unices ainsi que Windows (95, 98..) et les variantes +NT. Une liste de systèmes d'exploitation fonctionnels se trouve à : + +<http://www.gnupg.org/gnupg.html#supsys> + +3.2) Quel collecteur d'entropie dois-je utiliser ? + +Les "bons" générateurs de nombres aléatoires sont cruciaux pour la sécurité de vos +chiffrements. Les différents systèmes d'exploitation proposent des valeurs +aléatoires de qualité variable. Linux et les systèmes *BSD produisent généralement +de bonnes valeurs grâce au /dev/random et cette méthode devrait rester la +méthode de choix pour ces systèmes. Les utilisateurs de Solaris devraient opter +pour pe paquetage SUNWski afin de disposer d'un /dev/random. Dans ces cas, +vous devriez utiliser l'option --enable-static-rnd=linux. D'autre part, il existe également +un dispositif au niveau kernel pour la production de valeurs aléatoires développé +par Andi Maier : + +< http://www.cosy.sbg.ac.at/~andi> + +Ce logiciel est au stade de beta : vous ne l'utilisez que sous votre seule +responsabilité ! + +Sur les autres systèmes, l'utilisation de l'EGC ou "Entropy Gathering Daemon" +se montre un bon choix. C'est un daemon écrit en Perl qui surveille l'activité du +système et produit des hachages permettant d'obtenir des valeurs aléatoires. +Vous devriez en consulter la page de téléchargement depuis : + +<http://www.gnupg.org/download.html> + +Pour l'utiliser vous devrez utiliser l'option --enable-static-rnd=egd + +Si les options ci-dessus ne fonctionne pas, vous pourrez utiliser le producteur +d'entropie "unix". Il est *TRES* lent et il devrait être évité lorsque possible. +Sa qualité d'entropie laisse vraiment à désirer et vous ne devrez jamais +l'utiliser dans la protection de données sensibles. + +3.3) Comment puis-je inclure le support du RSA et de l'IDEA ? + +RSA se trouve inclus dans GnuPG depuis la version 1.0.3 et supérieures. + +La distribution officielle de GnuPG ne comprend pas l'IDEA à cause +d'une restriction par brevêt. Le brevêt devrait expirer en 2007 et nous +attendons cette date pour l'inclure dans GnuPG. + +Toutefois, il existe des modules officieux qui permettent de l'inclure +même dans les versions de GnuPG avant cette date. Ces modules +sont disponibles depuis : + +<ftp://ftp.gnupg.org/pub/gcrypt/contrib/> + +Recherchez 'idea.c' + +Les directives de compilation se trouvent dans les fichiers "headers" de +ces fichiers. Vous pourrez ensuite ajouter la ligne suivante à votre +fichier ~/.gnupg/options : + + load-extension idea + +4. USAGE + +4.1) Quelle est la taille de clef recommandée ? + +Nous vous recommandons un minimum de 1024 bits pour les clefs de type +DSA et également pour les signatures simples de type ElGamal. La taille +du hachage est probablement le lien le plus faible si la taille de la clef +augmente à plus de 1024 bits. Les clefs de chiffrement peuvent avoir +des tailles supérieures, mais vous devriez alors vérifier le fingerprint +de la clef de cette manière : + +gpg --fingerprint --fingerprint <user ID> + +Comme pour les algorithmes de clef, vous devriez vous en tenir aux +valeurs par défaut (i.e. les chiffrements ElGamal avec signature +DSA). Une clef de signature ElGamal comporte les désavantages +suivants : si la signature est grosse, il est difficile de créer une +clef correspondante utile pour les signatures et capable de résister +aux attaques réelles, et vous n'obtiendrez pas de sécurité +supplémentaire face au DSA. Il pourrait y avoir des problèmes +de compatibilité avec certaines versions de PGP. Il n'aura été +introduit que parce à l'époque, il n'était pas clair de savoir si +un brevêt s'appliquait ou non au DSA. + +4.2) Pourquoi la création de clefs est-elle aussi longue ? + +Le problème est ici que nous avons besoin d'une grande quantité d'octets aléatoires et que +nous devons pour ce faire collecter une certaine quantité d'entropie depuis, sous Linux, +le /dev/random. Il n'est pas vraiment facile de remplir l'entropie de Linux ; nous en avons +discuté avec Ted Ts'o et il a expliqué que la meilleure méthode pour remplir le buffer +n'est autre que de jouer avec votre clavier. Une bonne sécurité implique un coût. +Vous pouvez utiliser les touches Shift, Control, Alt en appuyant dessus de manière aléatoire, +d'autant que ces touches ne produisent aucune sortie à l'écran et vous pourrez accélérer +la production des clefs. + +Un autre programme pourrait également consommer une partie de l'entropie du système +dont vous avez besoin (jettez un oeil à vos daemons actifs). + +4.3) Pourquoi tout est si lent quand je travaille sur un système distant ? + +Vous ne devez SURTOUT pas faire cela ! Vous ne devez jamais créer de +clef GnuPG sur un système distant car vous n'aurez alors aucun contrôle +physique sur votre clef privée, ni même votre trousseau de clefs privées. +Ces clefs seront alors suspectibles de subir une attaque par dictionnaire. +Nous vous encourageons vivement à ne produire vos clefs que sur une +machine personnelle (un portable déconnecté de toute alimentation +et connexion réseau est le meilleur choix) et si vous devez conserver +votre clef privée sur une machine fixe, assurez-vous qu'une phrase +passe solide en protège le contenu et que vous pouvez faire confiance +à votre administrateur système. + +Lorsque nous devons utiliser GnuPG à distance c'est au-travers de SSH +et nous rencontrons le même problème. Il faut *beaucoup* de temps +pour produire des clefs de toute manière. Il ne faut pas créer de clefs +à distance. Si vous avez juste besoin de clefs à fins de tests, vous +pouvez utiliser l'optoin --quick-random pour produire rapidement des +clefs *faibles* qui permettent de vérifier quelques tests. + +4.4) Quelle est la différence entre options et commandes ? + +Si vous tapez 'gpg --help' vous obtiendrez deux listes séparées. La première +liste vous répertorie les commandes. La seconde liste regroupe elle les +options. A chaque fois que vous utiliserez GnuPG vous devrez utiliser +*UNE* commande (avec une exception, voir ci-dessous) et vous pourrez +utiliser une ou *plusieurs* options en combinaison avec la commande. + +Par convention, la commande doit se trouver à la fin de la liste d'arguments +après toutes les options. Si la commande requiert un nom de fichier, +ce dernier sera donné à GnuPG en *dernier* sur la ligne de commande. + +L'usage basique de GnuPG est donc : + + gpg [--option something] [--option2] [--option3 something] --command file + +Certaines options demandent des arguments. Par exemple, l'option +--output (que l'on peut raccourcir par -o) requiert un nom de fichier +en argument. L'argument de l'option doit suivre celle-ci immédiatement ! +GnuPG ne sera sinon pas capable de différencier le nom de fichier comme +option. Comme option, --output et son nom de fichier doivent se trouver +avant la commande donnée à GnuPG. L'option --recipient (ou -r) demande +un nom ou un keyID pour chiffrer le message et ces informations devront +imméditamenet suivre l'option --recipient/-r. La commande --encrypt ou +-e sera fournie après ces options, avec en final le nom du fichier à +chiffrer. En voici un exemple : + + gpg -r alice -o secret.txt -e test.txt + +Mais l'utilisation des options sous leur forme longue permet de simplifier +la compréhension des lignes de commande : + + gpg --recipient alice --output secret.txt --encrypt test.txt + +Si vous sauvez dans un fichier nommé ".txt" alors vous devriez probablement +utiliser l'option ARMOR en ajoutant l'option --armor ou -a qui ne prend aucun +argument : + + gpg --armor --recipient alice --output secret.txt --encrypt test.txt + +Si nous plaçons des crochets autour des parties optionnelles, les choses +deviennent plus claires : + + gpg [--armor] [--recipient alice] [--output secret.txt] --encrypt test.txt + +Les parties entre crochets peuvent être placées dans l'ordre de votre +choix : + + gpg --output secret.txt --recipient alice --armor --encrypt test.txt + +Si votre nom de fichier commence par un tiret, GnuPG risque de penser +qu'il s'agit d'un paramètre et pour éviter cette situation vous pouvez +soit utiliser un "./-a.txt" soit utiliser un double-tiret comme ceci : + +-- -a.txt + +* L'exception concerne le chiffrement ET la signature au même moment. +On utilise alors gpg [--options] --sign --encrypt foo.txt + +4.5) Je ne peux pas effacer un userid car il a déjà été effacé dans mon + trousseau de clefs publiques ? + +Comme vous ne pouvez sélectionner que depuis le trousseau de clefs +publiques, vous ne pouvez pas directement effacer le userid. Toutefois, +ce n'est pas très compliqué à faire. Vous devez créer un nouvel +utilisateur, disposant du même userid ce qui vous permet d'obtenir deux +utilisateurs identiques avec un seul disposant d'une correspondance +dans la clef privée. Vous pouvez désormais sélectionner cet utilisateur +et l'effacer. Les deux identifiants seront affacés du trousseau de clefs +privées. + +4.6) Que sont la confiance, la validité et l'ownertrust ? + +Le terme "ownertrust" est utilisé en remplacement de "trust" lorsqu'il +s'agit de la valeur que vous avez attribuée à une clef en fonction +du degré de confiance que vous accordez à son propriétaire, et si +vous l'autorisez à introduire de nouvelles clefs avec votre signature +jointe. La "validité" est un terme de confiance calculée, une valeur +numérique calculée par GnuPG en fonction des paramètres de +confiance des clefs et vous donne une idée de la confiance que +GnuPG attribue ou n'attribue pas à une clef et s'il estime que la clef +est valide pour un usage de chiffrement. Pour plus de détails consultez +le chapître "The web of trust" + +4.7) Comment puis-je signer un fichier de patch ? + +Vous pouvez utiliser : + +gpg --clearsign --not-dash-espaced ... + +Le problème avec --clearsign c'est que toutes les lignes qui +commençent par un tiret sont "quotées" avec "- " et comme diff +produit beaucoup de lignes de ce type, le patch risque d'être +détruit par la signature. Pour utiliser un fichier patch en le signant +et sans perdre la signature claire, l'option spéciale : + +--not-dash-escaped + +Permet de supprimer la production de ces séquences d'échappement. +Vous ne devriez pas transmettre par courrier électronique un patch +de ce type car les espaces et les fins de ligne font également +partie de la signature et un logiciel de messagerie risque de modifier +l'espacement et/ou les tailles de lignes, invalidant la signature. Si vous +souhaitez transmettre le fichier, le plus simple reste de le signer à l'aide +de votre MUA. + +4.8) Où se trouve l'option "encrypt-to-self" ? + +Utilisez l'option : + +--encrypt-to <votre_keyID> + +Vous pouvez utiliser une combinaison de cette option pour spécifier +plus d'un keyID. Pour désactiver temporairement l'utilisation de clefs +additionnelles, vous pouvez utiliser l'option : --no-encrypt-to. + +4.9) Comment puis-je me débarasser de la version et du champ de commentaire + dans la version "armor" des messages ? + +Utilisez l'option --no-version --comment "" + +Veuillez noter que la ligne vide laissée en place est *requise* par le format +et le protocole. + +4.10) Que signifie le message "You are using the xxxx character set" ? + +Cette note est affichée lorsque une conversion UTF-8 a été réalisée. +Veuillez vous assurer que le jeu de caractères utilisé pour l'affichage +correspond bien à celui du système. Le plus utilisé reste "iso-8859-1" et +c'est le jeu de caractères par défaut. Vous pouvez modifier ce jeu +de caractères à l'aide de l'option "--charset". Il faut que le jeu de +caractères utilisé corresponde à celui de votre affichage ou des +caractères pourraient ne plus correspondre dans le message une +fois transmis. Sinon, n'utilisez que de l'ASCII 7 bits pour qu'aucune +conversion ne puisse survenir. + +4.11) Comment puis-je obtenir la liste des keyid ayant servi à + chiffrer un message ? + + gpg --batch --decrypt --list-only --status-fd 1 2>/dev/null | \ + awk '/^\[GNUPG:\] ENC_TO / { print $3 }' + +4.12) Je ne peux plus déchiffrer mon message chiffré symétriquement + (-c) avec la nouvelle version de GnuPG ? + +Il existait un bogue dans les versions 1.0.1 et antérieures de GnuPG +qui surveniait lorsque 3DES ou Twofish avaient été utilisé pour des +chiffrements symétriques (ce qui n'a jamais été le cas par défaut). +Ce bogue a été corrigé afin de permettre le déchiffrement des anciens +messages, en utilisant l'option : + +---emulate-3des-s2k-bug + +Vous devriez déchiffrer puis rechiffrer (correctement) le ou les +messages concernés. Cette option sera retirée dans la version 1.1 +de GnuPG : n'attendez pas pour convertir vos messages ! + +4.13) Comment puis-je utiliser GnuPG en environnement automatisé ? + +Vous devriez utiliser l'option --batch et ne pas utiliser de phrase +passe car il n'existe alors aucun moyen de conserver cette +information de manière plus secrète que le trousseau de clefs +lui-même. Nous vous suggérons de créer vos clefs, en environnement +automatisé, de la manière suivante : + +Sur une machine protégée : + +Créez une sous-clef de signature pour votre clef, en utilisant le menu +edit et en utilisant l'option "addkeu" puis DSA. Vous devez ensuite +vous assurer que vous utilisez une phrase passe (requise par +l'implémentation actuelle) puis utiliser : + +gpg --export-secret-subkeys --no-comment foo + >secring.auto + +Copiez secring.auto et le trousseau de clefs publiques dans un +répertoire test. Entrez dans le répertoire, puis : + +gpg --homedir . --edit foo + +Et utilisez "passwd" pour retirer la phrase passe des sous-clefs. +Vous devriez également retirer toutes les sous-clefs qui ne sont +pas utilisées et copier secring.auto sur une disquette et la +porter jusqu'à la machine cible. + +Sur celle-ci, installez secring.auto comme trousseau de clefs +secrètes. Vous pouvez maintenant faire démarrer votre +nouveau service. C'est aussi une bonne idée que d'installer +un système de détection d'intrusions afin de pouvoir repérer +les intrusions ce qui vous permettra alors de révoquer toutes +les sous-clefs installées sur cette machine et de procéder à une +nouvelle installation de sous-clefs. + +4.14) Quel client email puis-je utiliser avec GnuPG ? + +Utiliser GnuPG pour le chiffrement de courrier électronique est +probablement l'usage le plus répandu. De nombreux logiciels de +messagerie (les "MUA") supportent GnuPG à divers degrés. Pour simplifier, +il existe deux moyens de chiffrer les emails avec GnuPG : l'ancien style +qui repose sur l'utilisation de l'ASCII Armor (un chiffrement classique +suivi par une conversion selon le RFC2015) ce qu'on appellait le +PGP/MIME et qui s'appelle désormais l'OpenPGP. Ce dernier supporte +d'autre part le MIME. Certains MUA ne supportent qu'un seul de ces +formats et vous devrez utiliser ce qui correspond aux capacités +de votre client de messagerie. + +La liste suivante n'est probablement pas exhaustive : + + OpenPGP: Mutt (Unix), Emacs/Mew, Becky2 (Windows avec plugin), + TkRat (Unix). Il y a un effort pour disposer d'un plug-in + Mozilla et Emacs/GNUS dispose d'un support en CVS. + + ASCII: Emacs/{VM,GNUS}/MailCrypt, Mutt(Unix), Pine(Unix), et + probablement beaucoup d'autres. + +Un bon aperçu du support de PGP se trouve à l'adresse : + +http://cryptorights.org/pgp-users/pgp-mail-clients.html + +Le support direct de GnuPG n'est pas indiqué, toutefois dans certains +cas il doit être possible d'utiliser un "wrapper". + +4.15) On ne peut pas avoir une librairie gpg ? + +Cette question aura souvent été posée. Toutefois, le point de vue +actuel est que GnuPG en tant que librairie risque de conduire à des +problèmes de sécurité. Dans un futur proche, GnuPG ne sera pas +implémenté sous forme de librairie. Toutefois, pour quelques domaines +d'application le programme gpgme doit pouvoir assurer ces questions. +Vous pouvez obtenir ce programme depuis : + +ftp://ftp.guug.de/pub/gcrypt/alpha/gpgme + + +4.16) J'ai produit avec succès un certificat de révocation, mais comment + dois-je le transmettre aux serveurs de clefs ? + +La plupart des serveurs de clefs n'accepteront pas une simple et "dure" +révocation. Vous devez d'abord importer le certificat dans GnuPG : + + gpg --import my-revocation.asc + +Puis transmettre la révocation au serveurs de clefs : + + gpg --keyserver certserver.pgp.com --send-keys mykeyid + +5. COMPATIBILITY ISSUES + +5.1) Comment puis-je chiffrer un message avec GnuPG pour que PGP + soit capable de le déchiffrer ? + +Tout ceci dépend de la version de PGP. + + PGP 2.x + +Vous ne pourrez pas dans ce cas, car PGP 2.x utilise l'IDEA qui n'est +pas un algorithme supporté par GnuPG à cause de son brevêt (voir +la section 3.3) mais si vous disposez d'une version modifiée de PGP +vous pouvez essayer ceci : + + gpg --rfc1991 --cipher-algo 3des ... + +Attention ! N'utlisez pas de pipe des données à chiffrer vers gpg, +mais donnez à gpg un nom de fichier sinon PGP 2 ne sera pas +capable de le prendre en charge. + +Quand à ce qui concerne le chiffrement conventionnel, vous ne +pouvez l'obtenir avec PGP 2. + + + PGP 5.x et ultérieurs + +Vous devrez utiliser deux options additionnelles : + + --compress-algo 1 --cipher-algo cast5 + +Vous devrez parfois utiliser "3des" au lieu de "cast5". PGP 5 ne +supporte pas l'algorithme "blowfish". Vous devrez aussi insérer +un "compress-algo 1" au sein de votre fichier ~/.gnupg/options +et ceci n'affectera pas le fonctionnement général de GnuPG. + +Ceci s'applique également au chiffrement conventionnel. + +5.2) Comment migrer de PGP 2.x vers GnuPG ? + +PGP 2 utilise les algorithmes RSA et IDEA pour le chiffrement. Depuis que le +brevêt sur le RSA a expiré GnuPG incorpore ce dernier, depuis la version +1.0.3 et ultérieures. L'algorithme IDEA reste sous brevêt jusqu'en 2007. +Sous certaines conditions vous pouvez utiliser l'IDEA, même aujourd'hui. +Dans ce cas, vous devriez consulter la réponse à la question 3.3 qui +explique l'ajout du support de l'IDEA à GnuPG et également lire ce +document : + +http://www.gnupg.org/gph/en/pgp2x.html + +Pour procéder à la migration. + +5.3) (supprimé) + + (vide) + +5.4) Pourquoi PGP 5.x n'est pas capable de déchiffrer les messages + pour certaines clefs ? + +PGP Inc refuse d'accepter les clefs ElGamal de type 20 même pour +le chiffrement. Ils ne supportent que le type 16 (qui est identifique en tout +cas en ce qui concerne le déchiffrement). Pour être plus inter-opérable, +GnuPG (depuis la version 0.3.3) utilise également le type 16 pour la sous- +clef ElGamal qui est créée par l'algorithme par défaut. Vous pouvez +aussi ajouter une clef de type 16 à votre trousseau de clefs publiques +tout en assurant que vos signatures sont valides. + +5.5) Pourquoi PGP 5.x ne peut vérifier mes messages ? + +PGP 5.x n'accepte pas les signatures en version 4 pour les données +mais OpenPGP demande la production de clefs V4 pour tous les types +de données et c'est pourquoi GnuPG les utilise... Vous devrez utiliser +l'option --force-v3-sigs pour produir'e des signatures V3 sur les +données. + +5.6) Comment puis-je transférer mes valeurs de confiance de + PGP vers GnuPG ? + +Il existe un script au sein du répertoire tools qui pourra vous aider. Après +avoir importé le trousseau de clefs publiques PGP vous pouvez utiliser +cette commande : + + $ lspgpot pgpkeyring | gpg --import-ownertrust + +où "pgpkeyring" est le trousseau de clefs originels et NON celui de GnuPG +que vous avez produit à la première étape. + +5.7) PGP n'aime pas ma clef privée. + +Les anciens PGP échouent parfois au traitement des commentaires privés +sur les paquets utilisés par GnuPG. Ces paquets sont en *totale* conformité +avec OpenPGP mais vous l'aurez compris, PGP n'est pas vraiment soucieux +d'OpenPGP. Pour contourner ce problème il faut exporter les clefs privées +à l'aide de cette commande : + + $ gpg --export-secret-keys --no-comment -a your-key-id + +Une autre possibilité : par défaut, GnuPG chiffre votre clef privée à l'aide +de l'algorithme symétrique Blowfish. Les anciennes versions de PGP +ne peuvent comprendre que le 3DES, CAST5 ou l'IDEA sous leurs formes +symétriques. L'utilisation de la méthode suivante permet de rechiffrer +vos clefs privées à l'aide d'un algorithme différent : + + $ gpg --s2k-cipher-algo=CAST5 --s2k-digest-algo=SHA1 \ + --compress-algo=1 --edit-key <username> + +Vous utiliserez alors l'option passwd pour modifier le mot de passe ; il suffit +de choisir la même phrase passe mais cette fois la clef sera chiffrée +symétriquement par du CAST5. + +Vous pouvez maintenant exporter la clef et PGP devrait pouvoir la gérer. + +Pour PGP 6.x les options suivantes permettent d'exporter une clef : + + $ gpg --s2k-cipher-algo 3des --compress-algo 1 --rfc1991 \ + --export-secret-keys <Key-ID> + +6. PROBLEMS and ERROR MESSAGES + +6.1) Pourquoi GnupG me dit sans cesse "Warning : using insecure memory!" ? + +Sur beaucoup de systèmes, ce programme doit être installé en tant que +setuid(root). Ceci est requis afin de pouvoir produire un blocage en mémoire +des pages utilisées (et d'éviter tout transfert en swap ou sur disque). Ce "lock" +permet de verrouiller dans la pratique les informations sensibles en RAM +afin de conserver ces données comme secrètes. Si vous n'obtenez aucun +message d'erreur c'est que votre système supporte le verrouillage de pages +mémoire depuis l'accès root (le programme s'exécute en tant que root grâce +à son setuid). Le programme quitte le mode d'exécution "root" dès que les +pages sont verrouillées en mémoire qui plus est. + +Sur Unixware 2.x et 7.x vous devriez installer GnuPG avec le privilège +"plock" pour obtenir le même effet : + + filepriv -f plock /path/to/gpg + +Si vous ne pouvez pas installer GnuPG en tant que setuid(root) ou si vous +ne voulez pas, vous pouvez utiliser l'option : + +--no-secmem-warning + +Ou bien le placer en tant qu'option (sans les deux tirets) dans votre +fichier ~/.gnupg/options ce qui permet de désactiver le warning. + +Sur quelques systèmes (e.g; Windows) GnuPG ne verrouille pas les +pages en mémoire (ce n'est pas toujours possible selon les systèmes) +et les anciennes versions de GnuPG (1.0.4 et antérieures) produisent +sur ces systèmes le message d'erreur suivant : + + gpg: Please note that you don't have secure memory + +Cet avertissement ne peut être désactivé en utilisant l'option décrite +ci-dessus car nous considérons que cet avertissement forme une +faille de sécurité importante. Toutefois, comme il provoquait une trop +forte confusion auprès des utilisateurs de ces systèmes, le message +d'avertissement a été retiré. + +6.2) Le support des fichiers de grande taille ne fonctionne pas .. + +Le LFS fonctionne correctement depuis les versions 1.0.4 et ultérieures. +Si le configure ne le détecte pas correctement, essayez un autre +compilateur : egcs 1.1.2 fonctionne parfaitement mais d'autres +versions semblent poser problème. D'autre part, certains problèmes +de compilation rencontrés dans GnuPG 1.0.3 et 1.0.4 sur HP-UX et +Solaris étaient provoqués par un support "cassé" du LFS dans les +sources ... + +6.3) Dans le menu d'édition les valeurs de confiance ne sont pas affichées + correctement après la signature des uid : pourquoi ? + +Ceci survient car certaines informations sont stockées immédiatement +dans la TrustDB, mais le calcul ne se réalisé qu'au moment de la +sauvegarde effective. Ce n'est pas un bogue vraiment facile à corriger +mais nous pensons régler ce problème dans une future version. + +6.4) Que signifie "skipping pubkey 1: already loaded" ? + +Depuis la version 1.0.3 de GnuPG l'algorithme RSA est inclus. Si vous +avez toujours l'option : + +load-extension rsa + +Dans votre fichier .options le message en question apparaîtra. +Il vous suffira de retirer la commande qui n'est plus requise +du fichier .options pour que le message cesse. + +6.5) GnuPG 1.0.4 ne tient pas compte de ~/.gnupg ... + +Ce bogue est connu et il a été corrigé dans les versions ultérieures. + +6.6) Une signature ElGamal ne vérifie plus rien depuis la 1.0.2 .. + +Utilisez l'option : + +--emulate-md-encode-bug + + Use the option --emulate-md-encode-bug. + +6.7) Les anciennes versions de GnuPG ne vérifient pas les anciennes + signatures ElGamal + +Veuillez migrer vers la version 1.0.2 au minimum, et de préférence +une version ultérieure (1.0.6 par exemple). + +6.8) Lorsque j'utilise --clearsign le texte en clair comporte parfois des + tirets supplémentaires : pourquoi ? + +Ceci s'appelle le "dash-escaped" et il est requis par le format +OpenPGP. A chaque fois qu'une ligne commence par un tiret, ceci +risque de survenir. Cela permet aux programmes de retrouver +sans difficulté les lignes de marquage du format, comme : + +-----BEGIN PGP SIGNATURE----- + +Seules ces lignes doivent pouvoir commencer par deux tirets. Si vous +utilisez GnuPG pour traiter ces messages, les tirets supplémentaires +seront retirés et les clients de messagerie "corrects" devraient +également retirer ces tirets lorsqu'ils affichent le message. + +6.9) Que signifie "can't handle multiple signatures" ? + +A cause des différents formats de messages, GnuPG n'est pas toujours +capable de découper un fichier contenant des signatures multiples. +Ce message d'erreur vous informe que les données en entrée +comportent un problème. Le seul moyen pour disposer correctement +de signatures multiples revient à utiliser le standard : le format +OpenPGP avec les paquets "one-pass-signature" qui sont utilisés +par défaut par GnuPG ou bien de recourir au format de texte en clair. + +6.10) Si je soumet une clef au serveur de clefs, rien ne survient ! + +Vous utilisez probablement GnuPG sur Windows en version 1.0.2 ou +antérieure. Cette fonctionnalité n'était alors pas encore disponible, +et il ne s'agit pas d'un bogue. Vous devriez adopter une version +plus récente, qui dispose de toutes les fonctionnalités :-) + +6.11) J'obtiens un "gpg: waiting for lock ..." + +Les anciennes versions de GnuPG ne quittaient pas correctement +et laissaient un fichier "lock". Allez dans le répertoire ~/.gnupg et +effacez les fichiers *.lock qui s'y trouvent pour continuer. + +6.12) Les anciennes versions de GnuPG (e.g. 1.0) ont des problèmes + avec les clefs de GnuPG récents .. + +Depuis la version 1.0.3 les clefs produites par GnuPG sont créées avec +une préférence pour Twofish (et l'AES depuis la version 1.0.4 à savoir, +l'algorithme Rijndael) et ceci signifie également qu'elles disposent de la +capacité d'utilisation de la nouvelle méthode de chiffrement MDC. Ceci +sera disponible dans OpenPGP très rapidement et sera supporté en +tout logique par PGP 7. Cette nouvelle méthode de chiffrement permet +de se protéger votre des attaques (des anciennes attaques en fait) +contre les systèmes de chiffrement du courrier électronique. + +Ceci signifie également que les versions 1.0.3 et antérieures de GnuPG +auront des problèmes avec les clefs plus récentes. A cause des +correctifs de sécurité, vous devriez conserver votre installation +de GnuPG à jour de toute manière. Comme manière de régler le +problème vous devriez demander à GnuPG de n'utiliser que l'ancien +algorithme de chiffrement en utilisant la ligne : + +cipher-algo cast5 + +dans votre fichiers d'options. + +6.13) Avec GnuPG 1.0.4 j'obtiens un "this cipher algorithm is deprecated ..." + +Si vous venez de produire une nouvelle clef et que vous obtenez ce message +pendant un chiffrement, il s'agit d'un bogue de la version 1.0.4 ; le nouvel +algorithme AES Rijndael est utilisé mais il n'est pas enregistré sous le bon +numéro d'algorithme ce qui produit ce message d'erreur "deprecated". +Vous pouvez ignorer cet avertissement et les versions plus récentes +de GnuPG sont corrigées sur ce point. + +6.14) Les dates sont affichées par ????-??-??, pourquoi ? + +A cause de contraintes dans la plupart des implémentations de la libc, +les dates au-delà de 2038-01-19 ne seront pas affichées correctement. +Les systèmes 64-bit ne sont pas affectés par ce problème. Pour éviter +d'afficher les dates de manière incorrecte, GnuPG utilise des signes +"?" au lieu des chiffres. Pour obtenir la valeur correcte vous devrez +utiliser l'option : + +--with-colons --fixed-list-mode + +6.15) J'ai encore un problème, dois-je produire un message de bogue ? + +Si vous êtes sûr(e) que le problème n'est mentionné nulle part, ni dans +cette FAQ ni dans aucune liste de distribution GnuPG, commencez +par consulter la liste de bogues qui sont en cours de traitement (la page +de documentation dispose d'un lien vers la page de bogues). Si vous +ne savez pas trop s'il s'agit d'un bogue, envoyez un courrier +électronique à la liste : gnupg-devel. Sinon, vous pouvez utiliser +le système de suivi de bogues GUUG à l'adresse : + +http://bugs.guug.de/Reporting.html. + +6.16) Pourquoi GnuPG ne supporte pas les certificats X.509 ? + +GnuPG est avant tout une implémentation du standard OpenPGP, +défini dans le RFC 2440. Ce standard propose une infrastructure +complète et différente du X.509 + +Ces deux systèmes sont des cryptosystèmes à clef publique, mais +la manière dont les clefs sont traitées diffèrent. + +7. SUJETS AVANCES + +7.1) Comment tout cela fonctionne-t-il ? + +Pour produire une paire de clefs publique/privée, utilisez la commande + +gpg --gen-key + +Puis répondez aux questions en adoptant de préférence les valeurs +par défaut. + +Les données qui sont chiffrées par une clef publique ne peuvent être +déchiffrées que par la clef privée correspondante. La clef secrète +est d'autre part protégée par une phrase-passe ce qui n'est pas le cas +de la clef publique, librement distribuable. + +Pour transmettre à vos amis un message, il vous suffit de le chiffrer +à l'aide de leurs clefs publiques. Seules leurs clefs privées seront +capables de déchiffrer le message. + +GnuPG est pratique pour signer de manière numérique les choses. +Les éléments qui sont chiffrés à l'aide de la clef publique ne peuvent +être déchiffrés que par la clef publique, ce qui permet de signer +des documents. On commence par produire un hachage, une sorte +d'empreinte à taille fixe d'un document (de taille variable). Ensuite, +votre clef privée est utilisée pour chiffrer ce hachage. Par la suite, +toute personne disposant de votre clef publique et du document +peut vérifier si le hachage du document correspond bien au +déchiffrement du hachage, obtenu par votre clef publique dont +disposent vos destinataires. + +Un trousseau de clefs n'est qu'un gros fichier (selon le nombre de +clefs qu'il contient). Vous avez un trousseau de clefs publiques +qui contient vos clefs publiques et celles de vos amis. Vous avez +également un trousseau de clefs privées qui ne contient que vos +clefs privées (chiffrées et protégées par votre phrase-passe). Vous +devez faire très *attention* à ce fichier. Personne ne devra jamais +y avoir accès et la phrase-passe qui le protège devra être +complexe, et longue afin de bien protéger le secret. + +Vous pouvez aussi chiffrer des données de manière conventionnelle, +en utilisant l'option "-c" de GnuPG. Dans ce cas, la phrase-passe +utilisée servira de clef pour protéger le message. Aucun usage +de clef publique ou de clef privée ici : il s'agit d'un chiffrement +classique où il n'existe qu'une seule clef, utilisée pour chiffrer et +déchiffrer les données. Généralement, on utilise cette méthode +pour chiffrer ses propres documents à l'aide d'une phrase-passe +secrète qui vous est propre. Cette méthode de chiffrement ne +doit être utilisée pour des communications que si vous avez +physiquement rencontré vos destinataires et que vous partagez +dans le plus grand secret la phrase-passe (votre propre époux ou +épouse, ou un ami de confiance). L'avantage est que vous pouvez +changer de temps en temps la phrase-passe et en réduire le +risque afin qu'en cas de découverte de la phrase-passe toutes +vos données ne soient pas lisibles ;-) + +Vous pouvez ajouter et copier des clefs depuis votre trousseau +de clefs publiques à l'aide des commandes "gpg --import" et +"gpg --export". Vous pouvez également (ATTENTION !!) exporter +vos clefs privées à l'aide de la commande : "gpg --export-secret-keys" +mais ce n'est généralement pas utile sauf si vous devez déplacer +vos clefs privées d'une machine à l'autre. + +Les clefs peuvent être signées à l'aide de l'option "gpg --edit-key". Lorsque +vous signez une clef, vous certifiez que la clef appartient selon vous +à la personne dont l'identité se trouve mentionnée dans la clef. Vous +devez absolument être sûr(e) que la clef appartient bien à cette +personne, sans le moindre doute. Vous devez vérifier son fingerprint +à l'aide de la commande : + +gpg --fingerprint userid + +Et recevoir le même finger par téléphone ou de visu par la personne +concernée. Généralement, on procède à des "fêtes" où chaque personne +amène sa pièce d'identité, une carte de visite comprenant le fingerprint +et l'on procède à un échange des fingerprint, ou directement des clefs. + +Vous pouvez également utiliser l'option "-o filename" pour forcer +la sortie vers le fichier "filename". Pour forcer une sortie en console +par défaut on utilise un tiret. La commande "-r" permet de spécifier +le destinataire (avec quelle clef publique vous allez chiffrer) en ligne +de commande au lieu d'avoir à taper le nom du destinataire dans +le mode interactif. + +Autre chose d'importance. Par défaut, TOUTES les données sont chiffrées +dans un format binaire particulier; Si vous souhaitez transmettre les données +par courrier électronique (par exemple) vous devez les protéger dans +un format d'amure qu'on appelle ASCII ARMOR. Ce format sera obtenu +en utilisant l'option "-a" mais la méthode préférée reste d'utiliser +un client de messagerie respectueux du format MIME comme Mutt, Pine +et bien d'autres. + +Enfin, il existe une petite faille de sécurité dans OpenPGP (et donc dans PGP) +et vous devriez TOUJOURS chiffrer PUIS signer un message. Il ne faut +pas seulement chiffrer afin d'être totalement protégé. N'oubliez jamais. + +7.2) Pourquoi certaines signatures avec une clef ELG-E sont valides ? + +Ces clefs ElGamal furent produites par GnuPG en version 3 de paquets +(selon le RFC 1991). Le brouillon OpenPGP a été modifié par la suite +afin de modifier l'identifiant d'algorithme pour les clefs ElGamal qui est +utilisable pour les signatures et le chiffrement des modes 16 à 20. +GnuPG utilise le mode 20 quand il produit ses nouvelles clefs ElGamal +mais il accepte toujours les clefs de type 16 qui selon le standard +OpenPGP ne peuvent servir qu'au chiffrement, si la clef se trouve +dans un paquet en version 3 du format. GnuPG est le seul programme +ayant jamais utilisé les clefs au sein de paquets v3 - vous ne risquez +donc pas grand chose. + +7.3) Comment tout le système de confiance fonctionne au juste ? + +Il fonctionne d'une manière proche de PGP. La différence c'est que +la confiance est calculée uniquement lorsqu'elle est requise. C'est +pourquoi la TrustDB contient une liste des signatures de clefs +valides. Si vous ne fonctionnez pas en mode batch, vous devrez +assigner un paramètre de confiance aux clefs (un ownertrust). + +Vous pouvez consulter la validité (la valeur de confiance +calculée) en utilisant cette commande : + + gpg --list-keys --with-colons + +Si le premier champ est "pub" ou "uid" le second champ vous +indiquera le niveau de confiance : + +o = Inconnu (cette clef est nouvelle au système) +i = La clef est invalide (eg. il manque sa propre signature) +d = La clef a été désactivée +r = La clef a été révoquée +e = La clef a expiré +q = Non-défini (pas de valeur attribuée) +n = Ne jamais faire confiance à cette clef +m = Cette clef dispose d'une confiance marginale +f = Cette clef dispose d'une confiance totale +u = Cette clef dispose d'une confiance ultime. Cette valeur + n'est utilisée que pour les clefs où la clef secrète est + également disponibles. + +La valeur dans l'enregistrement "pub" est la meilleure valeur +obtenue depuis les enregistrements "uid". + +Vous pouvez obtenir la liste des valeurs de confiance attribuées ; +i.e. la confiance que vous accordez aux autres lorsqu'il s'agit +de signer la clef d'un autre individu) : + + gpg --list-ownertrust + +Le premier champ est le fingerprint de la clef primaire, le second +champ est la valeur assignée : + +_ = Aucune valeur d'ownertrust assignée +n = Ne jamais faire confiance au propriétaire de cette clef + lorsqu'il s'agit de vérifier d'autres signatures. +m = Une confiance marginale est accordée au détenteur de cette clef + lorsqu'il s'agit de signer d'autres clefs. +f = Assumer que le détenteur de cette clef est une personne de confiance + lorsqu'il s'agit de signer des clefs. +u = Nous n'avons pas besoin de nous faire confiance à nous-même puisque + nous détenons notre propre clef privée. + +Vous devez conserver ces valeurs confidentielles, car elles représentent +la confiance que vous accordez ou non à d'autres individus. PGP stocke +cette information au sein de trousseau de clefs et le publier n'est PAS +une bonne idée. Vous devez utiliser la commande d'exportation pour +transmettre des clefs. Quoi qu'il en soit, GnuPG +évite ces problèmes en ne conservant ces valeurs qu'aun sein de sa +TrustDB donc vous pouvez copier un trousseau de clefs publiques +si vous utilisez GnuPG (et nous disposons aussi de la commande +d'exportation). + +7.4) Quel est ce genre de sortie : "key C26EE891.298, uid 09FB: ...."? + +Cette sortie est la représentation interne d'un userid au sein +de la TrustDB. Le keyid est "C26EE891" et le "298" est le keyid local, +un simple numéro d'enregistrement dans la TrustDB. Enfin, le "09FB" +sont les deux derniers octets d'un ripe-md-160 de l'identifiant de +l'utilisateur pour cette clef. + +7.5) Comment interpréter certaines sorties informatives ? + +Lorsque vous vérifiez la validité d'une clef, GnuPG affiche +parfois une information préfixée par l'information en rapport +avec le sujet vérifié. Par exemple : "key 12345678.3456" indique +que la clef disposant de l'ID 12345678, et du numéro interne 3456 +est considérée au sein de la TrustDB au sein de ce qu'on +appelle un enregistrement "directory". Un "uid 12345678.3456/ACDE" +indique quel est l'identifiant d'utilisateur qui correspond +à cette clef. Il s'agit d'une information sur la signature de la +clef 9A8B7C6D disposant de cet ID et s'il s'agit d'une signature +directe sur la clef, la partie User ID sera vide : + +(..//..) + +7.6) Les lignes d'en-tête des messages font-elles parties des + éléments signés ? + +Non. Par exemple, vous pouvez retirer les lignes "Comment:" +Elles n'ont pas vraiment d'objet comme les lignes "header" des +courriers électroniques. Toutefois, une ligne qui débute par +"Hash: ..." est requise par les signatures OpenPGP afin de permettre +au parser de déterminer quel algorithme de hachage utiliser. + +7.7) Quelle est la liste des algorithmes préférés ? + +La liste des algorithmes préférés est une liste d'algorithmes +de chiffrement, de hachage et de compression stockés dans +la signature propre de la clef durant sa production. Lorsque +vous chiffrez un document, GnuPG utilise cette liste (elle fait +partie de la clef publique) pour déterminer quels algorithmes +doivent être utilisés. De manière basique, ces indications +expliquent aux autres utilisateurs quels algorithmes vous +acceptez en entrée avec un ordre de préférence. + +7.8) Comment puis-je changer la liste des algorithmes préférés ? + +Actuellement la liste et les préférences sont directement intégrées +dans les codes sources de GnuPG. Vous devrez modifier le fichier +g10/keygen afin de modifier cette liste et procéder à une +nouvelle compilation. La fonction que vous devrez modifier est +keygen_add_std_prefs. Le code est d'ailleurs assez simple à +comprendre. Les constantes utilisées pour différencier les +algorithmes sont définies au sein du fichier include/cipher.h + +Après avoir modifié ces fichiers, générez une nouvelle paire +de clefs (ou une nouvelle sous-clef de chiffrement) avec +la version modifiée de l'exécutable. La nouvelle clef disposera +des nouvelles préférences et pourra être utilisée depuis des +exécutables non modifiés. + +Pour modifier les préférénces d'une clef existante, vous devrez +utiliser un exécutable modifié (voir ci-dessus) afin de modifier +la date d'expiration puis sauvegardez les changements. Les +préférences seront automatiquement modifiées lors de la +sauvegarde et vous pouvez désormais utiliser la clef modifiée +avec tout exécutable, modifié ou non. + +La modification de la liste de préférences à l'aide d'une +version non-modifiée de GnuPG (probablement depuis le menu +d'édition) fait partie de la liste TODO (A FAIRE) prévue +pour les prochaines versions de GnuPG. + + +8. REMERCIEMENTS + +Nous souhaitons remercier Werker Kosh pour la rédaction de la +première FAQ originelle et pour tous les participants aux listes +de discussion gnupg-users et gnupg-devel. La quasi-totalité +des réponses de ce document proviennent de leurs efforts. + +Nous souhaitons également remercier Casper Dik pour nous +avoir fourni le script permettant de générer cette FAQ, +qu'il utilise d'autre part pour son excellente FAQ Solaris2 ;-) + +Copyright (C) 2000 Free Software Foundation, Inc. , +59 Temple Place - Suite 330, Boston, MA 02111, USA + +Verbatim copying and distribution of this entire article is permitted in +any medium, provided this notice is preserved. |