GNUPG : FOIRE AUX QUESTIONS Version : 1.2 Dernière modification : 10 septembre 2001 Maintenu par : Nils Ellmenreich Traduction : Gilbert Fernandes Ce document est la FAQ de GnuPG. La dernière version HTML est disponble ici : 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 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 : 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 : 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. 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 : Ou depuis l'un des mirroirs : 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 à : 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 : 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 : 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 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 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 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 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. , 51 Franklin Street, Fifth Floor, Boston, MA 02111, USA Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.