gnupg/doc/fr/FAQ

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.