From 961e45bf15110c74912ff9b19496d9cc08d1f41e Mon Sep 17 00:00:00 2001 From: Werner Koch Date: Thu, 8 Nov 2001 13:30:06 +0000 Subject: [PATCH] *** empty log message *** --- doc/fr/ChangeLog | 17 + doc/fr/DETAILS | 945 +++++++++++++++++++++++++++++++++++++++ doc/fr/FAQ | 1111 ++++++++++++++++++++++++++++++++++++++++++++++ doc/fr/README.fr | 10 + 4 files changed, 2083 insertions(+) create mode 100644 doc/fr/ChangeLog create mode 100644 doc/fr/DETAILS create mode 100644 doc/fr/FAQ create mode 100644 doc/fr/README.fr diff --git a/doc/fr/ChangeLog b/doc/fr/ChangeLog new file mode 100644 index 000000000..167093dcc --- /dev/null +++ b/doc/fr/ChangeLog @@ -0,0 +1,17 @@ +2001-09-10 Gilbert Fernandes + + * Traduction en français des documents doc/* + + +Copyright 2001 Free Software Foundation, Inc. + +Ce fichier est un logiciel libre ; l'auteur vous donne une autorisation +spéciale de copies illimitées et/ou distribution illimitée avec ou sans +modifications attendu que cette notice de copyright et note associée +se trouve conservée dans le document. + +This file is distributed in the hope that it will be useful, but +WITHOUT ANY WARRANTY, to the extent permitted by law; without even the +implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + + diff --git a/doc/fr/DETAILS b/doc/fr/DETAILS new file mode 100644 index 000000000..5c7246c9d --- /dev/null +++ b/doc/fr/DETAILS @@ -0,0 +1,945 @@ + +Format des listings "---with-colons" +==================================== + +sec::1024:17:6C7EE1B8621CC013:1998-07-07:0:::Werner Koch : +ssb::1536:20:5CE086B5B5A18FF4:1998-07-07:0::: + + 1. Champ: Type d'enregistrement + pub = clef publique + sub = sous-clef (clef secondaire) + sec = clef secrète + ssb = sous-clef secrète (clef secondaire) + uid = id d'utilisateur (seul le champ 10 est utilisé) + sig = signature + fpr = fingerprint: (le champ 10 est le fingerprint) + pkd = données publiques de la clef + (champ au format spécial, voir ci-dessous) + + 2. Champ: Une lettre décrivant la confiance calculée. Ce n'est qu'une + seule lettre, mais elle fera peut-être l'objet d'une information + supplémentaire pour les versions futures, comme décrit ici + (ceci ne sera pas utilisé pour les clefs privées) + 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. + 3. Champ: taille de la clef en bits. + 4. Champ: Algorithme utilisé: 1 = RSA + 16 = ElGamal (chiffrement uniquement) + 17 = DSA (parfois appellé DH, signature seulement) + 20 = ElGamal (signe et chiffre) + (pour d'autres is, consultez include/cipher.h) + 5. Champ: ID de clef (KeyID) + 6. Champ: Date de création (en UTC) + 7. Champ: Date d'expiration de la clef, vide si aucune. + 8. Champ: ID local : numéro d'enregistrement du répertoire dans la + trustdb. Cette valeur n'est valide que tant que la + trustdb n'est pas effacée. Vous pouvez utiliser + "#" comme id d'utilisateur lorsque vous spécifiez + la clef. Ceci est requis puisque les id de clef ne sont pas + toujours uniques - un programme peut donc utiliser ce numéro + pour accéder aux clefs ultérieurement. + 9. Champ: Confiance propre (clef publiques primaires uniquement) + C'est une simple lettre, mais une information supplémentaire pourrait + se voir ajoutée dans les versions futures. +10. Champ: ID utilisateur. La valeur est placée entre guillemets comme une + chaîne en C, par exemple : "\x3a". +11. Champ: Classe de signature. C'est un nombre hexadécimal à deux chiffres + suivi par la lettre "x" si la signature peut être exportée ou la + lettre "l" si la signature est uniquement locale. +12. Champ: Capacités de la clef : + e = chiffrement + s = signature + c = certification + Une clef peut disposer de toute combinaison de ces caractéristiques. + La clef primaire dispose, en plus de ces lettres, une version en + majuscule des lettres pour marquer les capacités "d'utilisation" + de la totalité de la clef. + +Toutes les dates sont affichées dans le format : + +yyyy-mm-dd + +Sauf si vous utilisez l'option --fixed-list-mode où dans ce cas précis les +dates sont affichées en secondes depuis Epoch. Plus de champs feront l'objet +d'additions dans les futures versions et les parsers doivent y être préparés. +Lorsque le parser traitera ces données, il devra s'arrêter au premier +caractère non-numérique afin que des informations supplémentaires soient +ajoutées à l'avenir. + +Le champ 1 dispose d'un tag "pkd" dont le listing ressemble à ceci : + +pkd:0:1024:B665B1435F4C2 .... FF26ABB: + ! ! !-- la valeur + ! !------ indicateur du nombre de bits de la valeur + !--------- index (eg. DSA va de 0 à 3 : p,q,g,y) + + + +Format de la sortie "--status-fd" +================================= + +Chaque ligne dispose d'un préfixe : + +"[GNUPG:] " + +Suivie par un mot clef indiquant le type de la ligne de statut, +et quelques arguments selon le type (probablement aucun) ; une application +devrait toujours assumer que des arguments supplémentaires seront +présents dans les versions futures. + + GOODSIG + La signature keyid est valide. + Pour chaque signature seul l'un des trois codes GOODSIG, BADSIG ou + ERRSIG seront produits et ils pourront être utilisés comme + marqueurs pour les nouvelles signatures. + + BADSIG + La signature keyid n'a pas été vérifiée correctement. + + ERRSIG \ + + Il n'a pas été possible de vérifier la signature. Ceci peut provenir + d'une clef publique manquante, ou bien à cause d'un algorithme non- + supporté. Un RC de 4 indique un algorithme inconnu, un 9 indique + une clef publique manquante. Les autres champs donnent plus d'information + sur la signature. sig_class est une valeur hexadécimale de 2 octets. + + VALIDSIG + La signature keyid est valide. C'est ici la même chose que GOODSIG + mais avec le fingerprint comme argument. Les lignes de statut seront + émises pour une bonne signature. + sig-timestamp est la date de création de la signature en secondes + depuis Epoch. + + SIG_ID + N'est émis que pour les signatures de classe 0 ou 1 qui ont été + vérifiées comme valides. Le chaîne est un identifiant d'utilisateur + et peut être utilisée dans les applications pour détecter les + attaques par rejeu de messages signés. Notez que seuls les + algorithmes DLP offrent des identifiants uniques ; les autres peuvent + produire des id dupliqués lorsqu'ils furent créés à la même seconde. + + ENC_TO + Le message est chiffré avec ce keyid. + keytype est une valeur numérique de l'algorithme à clef publique, + keylength est la taille de la clef ou 0 si elle n'est pas connue + (ce qui est toujours le cas). + + NODATA + Aucune donnée n'a été trouvée. Les codes suivants sont utilisés : + 1 - Pas de données sous ARMOR. + 2 - Un paquet attendu n'a pas été trouvé. + 3 - Paquet invalide trouvé ; ceci peut indiquer un message + non-OpenPGP. Vous devez vous attendre à une extension + de ces lignes de statu à l'avenir. + + UNEXPECTED + Des données innatendues ont été rencontrées + 0 - pas de détail supplémentaire + + TRUST_UNDEFINED + TRUST_NEVER + TRUST_MARGINAL + TRUST_FULLY + TRUST_ULTIMATE + Pour les signatures valides, l'une de ces lignes de statut sera produite + pour indiquer le niveau de confiance attribué à la clef. Pas d'arguments + pour l'instant. + + SIGEXPIRED + La clef de signature a expiré. Pas d'arguments pour l'instant. + + KEYREVOKED + L'utilisateur a révoqué sa clef. Pas d'arguments pour l'instant. + + BADARMOR + L'ARMOR ASCII est corrompu. Pas d'arguments pour l'instant. + + RSA_OR_IDEA + Les algorithmes IDEA ont été utilisés sur les données. Un programme + pourra basculer sur un autre programme de traitement si GnuPG échoue. + Ce message de statut sera affiché pour le RSA aussi, mais ceci a été + abandonné puisque le brevêt sur le RSA a expiré. + Toutefois, nous ne pouvons modifier le nom du message. + + SHM_INFO + SHM_GET + SHM_GET_BOOL + SHM_GET_HIDDEN + + GET_BOOL + GET_LINE + GET_HIDDEN + GOT_IT + + NEED_PASSPHRASE + Sera affiché à chaque fois qu'une phrase passe sera requise. + keytype est la valeur numérique de l'algorithme à clef publique + ou bien 0 si cela n'est pas applicable. keylength est la taille de la + clef ou 0 si la taille n'est pas connue (ceci est actuellement + toujours le cas). + + NEED_PASSPHRASE_SYM + Affiché à chaque fois qu'une phrase passe pour un chiffrement + symétrique sera requise. + + MISSING_PASSPHRASE + Aucune phrase passe n'a été fournie. Une application qui rencontre + ce message devrait stopper immédiatement le parsing car le prochain + message sera probablement BAD_PASSPHRASE. Toutefois, si l'application + n'est qu'un wrapper autour de la fonctionnalité d'édition de clefs, + ceci pourrait avoir un autre sens et stopper le parsing pourrait + être incorrect, et il faudra ignorer le BAD_PASSPHRASE. + + BAD_PASSPHRASE + La phrase passe fournie est soit invalide, soit n'a pas été fournie. + Dans le seconde cas vous devriez voir un MISSING_PASSPHRASE. + + GOOD_PASSPHRASE + La phrase passe fournie est valide et le matériel de clefs secrète + est utilisable. + + DECRYPTION_FAILED + La déchiffrement symétrique a échoué. Il s'agit généralement d'une + mauvaise phrase passe ne correspondant pas au message chiffré. + + DECRYPTION_OKAY + Succès du déchiffrement. Ceci signifie que soit la clef secrète + adaptée a été utilisée avec succès, soit que la phrase passe + valide pour un chiffrement symétrique aura conduit au déchiffrement. + Le programme pourait toutefois renvoyer un message d'erreur s'il + n'a pas été possible de vérifier la signature. + + NO_PUBKEY + NO_SECKEY + La clef n'est pas utilisable. + + IMPORTED + Le keyid et la signature ont été importés. + + IMPORTED_RES + + Statistiques finales sur le processus d'importation (cette ligne est longue!) + + FILE_START + Début de traitement du fichier . indique l'opération + réalisée : + 1 - vérifier + + FILE_DONE + Marque la fin de traitement d'un fichier, ayant débuté avec FILE_START. + + BEGIN_DECRYPTION + END_DECRYPTION + Marque le début et la fin du processus de déchiffrement. Ces messages + seront également produits lors de l'utilisation du mode --list-only. + + BEGIN_ENCRYPTION + END_ENCRYPTION + Marque le début et la fin du processus de chiffrement. + + DELETE_PROBLEM reason_code + L'effacement d'une clef a échoué. Un code indique la raison de l'erreur : + 1 - La clef spécifiée n'existe pas + 2 - La clef privée doit être détruite avant ! + + PROGRESS what char cur total + Utilisé par les fonctions primegen et de clef publique pour indiquer + la progression de l'opération. "char" est le caractère affiché sans + --status-fd avec les retours à la ligne marqués par "X". "cur" indique + la quantitité de traitement terminée et "total" indique la valeur + finale à atteindre. Un total de 0 indique que le total n'est pas + connu. 100/100 peut être utilisé pour détecter la fin de l'opération. + + SIG_CREATED + Une signature a été créée à l'aide de ces paramètres. + type: 'D' = détachée + 'C' = en texte clair + 'S' = standard + (seul le premier caractère doit être vérifié) + class: 2 chiffres hexadécimaux avec la classe de signature + + KEY_CREATED + Une clef a été créée + type: 'B' = primaire et sous-clef + 'P' = primaire + 'S' = sous-clef + + SESSION_KEY : + La clef de session utilisée pour déchiffrer le message. Ce message + sera seulement affiché si l'option --show-session est utilisée. + Le format est utilisable pour un passage direct à la fonction + --override-session-key. + + NOTATION_NAME + NOTATION_DATA + Le nom et la chaîne sont "escaped" à l'aide de %XX et les données + peuvent être découpées sur plusieurs lignes notation_data. + + USERID_HINT + Donne un indice sur l'ID utilisateur pour un keyID donné. + + POLICY_URL + La chaîne est "escaped" en %XX + + BEGIN_STREAM + END_STREAM + Produit par pipemode. + + +Génération de clef +================== + +La génération de clef marque sa progression à l'aide de différents caractères, dont +voici la signification : + +"." : les 10 derniers tests Miller-Rabin ont échoué. +"+" : réussite du test Miller-Rabin. +"!" : Rechargement du pool avec des nombres premiers frais. +"^" : Vérification d'une nouvelle valeur pour le générateur. +"<" : La taille d'un facteur a été réduite. +">" : La taille d'un facteur a été augmentée. + +Le nombre premier pour l'ElGamal est généré de la manière suivante : + +1. On crée un nombre premier q de 160, 200 ou 240 bits (selon la taille + de la clef). +2. On sélectionne la taille de l'autre facteur premier, afin qu'elle soit + au moins de la taille de q et on calcule le nombre de facteurs premiers + requis. +3. On crée un pool de nombres premiers, chacun dont la longueur fut déterminée + à l'étape 2. +4. On obtient une nouvelle permutation du pool et nous continuons avec + l'étape 3 une fois toutes les permutations testées. +5. Le premier cancidat est calculé par p = 2 * q * p[1] * ... * p[n] + 1 +6. On vérifie que ce premier dispose de la taille désirée (ceci peut changer + q s'il ne semble pas possible de produire un premier de la taille voulue) +7. On vérifie si ce nombre est premier à l'aide de divisions d'essai et par + le test de Miller-Rabin. +8. On continue à l'étape 4 si on n'a pas trouvé de premier à l'étape 7. +9. On trouve un générateur pour ce premier. + +Cet algorithme se base sur la suggestion de Lim et Lee du Crypto' 97 (p. 260). + +Génération de clef innatendue +============================= + +Cette fonction est actuellement expérimentale et permet la production de +clefs innatendues avec un contrôle depuis un fichier de paramètres. +Cette fonctionnalité n'a pas fait l'objet de tests poussés ! Veuillez ne +PAS vous plaindre si nous décidons d'apporter des modifications importantes +à cette commande. + +Pour utiliser cette fonctionnalité, vous devez utiliser --gen-key en +combinaison avec --batch et fournir les paramètres soit depuis stdin, +soit depuis un fichier dont le nom est fourni en ligne de commande. + +Ce fichier devra utiliser le format suivant : + + o En texte uniquement, chaque ligne étant limitée à environ 1000 caractères. + o Vous devez utiliser un codage UTF-8 pour marquer les caractères non ASCII. + o Les lignes vides seront ignorées. + o Les espaces en début et fin de ligne seront ignorés. + o Un signe "-" en tant que premier caractère "non white space" marque + une ligne de commentaire. + o Les commandes sont marquées par un signe "%" en début de ligne, + suivi par la commande et ses arguments sont séparés par des espaces. + o Les paramètres sont indiqués par un mot clef, suivi par un ":". Les + arguments sont séparés par des espaces. + o Le premier paramètre doit être "Key-Type" et ses contrôles peuvent + être placés à votre discrétion. + o La génération de clef aura lieu soit à la fin du fichier de paramètres, + soit lorsque le premier "Key-Type" est rencontré au sein du fichier, + dans un ensenble de contrôle "%commit". + o Les ensembles de contrôle sont : + %echo + Affiche + + %dry-run + Ne réalise pas la production de clef (pratique pour vérifier la + syntaxe). + + %commit + Réalise la production de clef. Un commit implicite est produit + à chaque rencontre de "Key-Type". + + %pubring + %secring + Ne renvoie pas la clef vers le sortie par défaut ou dans le keyring + indiqué en ligne de commande, mais vers le fichier . Ce + contrôle doit être utilisé avant que le commit ne soit rencontré. + Toute double mention sera ignorée et le dernier nom de fichier + rencontré sera celui utilisé. Le fichier sera utilisé jusqu'à ce + qu'un nouveau fichier soit spécifié (au points de commit) sinon + toutes les clefs seront placées dans le même fichier. Si un nouveau + nom de fichier est indiqué, le fichier sera créé (et tout ancien + fichier sera alors écrasé). Les deux indications doivent être + fournies au contrôle. + + o L'ordre des paramètres n'a pas d'importance, sauf pour "Key-Type" qui + doit être le premier paramètre rencontré. Les paramètres ne sont + destinés qu'au bloc keybloc généré et les paramètres des productions + précédentes de clefs ne seront pas pris en compte. Certaines + vérifications syntaxiques seront mises en place et peuvent être + ou non actives. Les paramètres actuellement définis sont : + + Key-Type: | + Débute un nouveau bloc de paramètres indiquant le type de la clef + primaire à produire. L'algorithme doit être capable de produire + des signatures. Ce paramètre est indispensable ! + + Key-Length: + Indique la taille de la clef, en bits. La valeur par défaut est + 1024. + + Subkey-Type: | + Permet de produire une clef secondaire. Actuellement, seule une + sous-clef peut être gérée. + + Subkey-Length: + Taille de la sous-clef en bits. La valeur par défaut est + 1024. + + Passphrase: + Si vous souhaitez spécifier une phrase passe pour la clef + secrète vous pouvez utiliser cette commande. Par défaut, + aucune phrase passe ne sera associée aux clefs privées. + + Name-Real: + Name-Comment: + Name-Email: + Voici les trois composantes d'une clef. Vous devez ici + n'utiliser que de l'UTF-8. Si vous ne fournissez aucune + de ces indications, aucun ID d'utilisateur ne sera créé. + + Expire-Date: |([d|w|m|y]) + Spécifie la date d'expiration de la clef (et de sa sous-clef) + La date doit être entrée sous la forme d'une date au format + ISO (année-mois-jour) ou bien sous forme d'un nombre de + jours, de semaines, de mois ou d'années. Si vous n'utilisez + pas de lettre pour indiquer la durée, des "jours" sont + assumés par défaut. + +Voici un exemple : +$ cat >foo < +ssb 1024g/8F70E2C0 2000-03-09 + + + +Composition de la TrustDB +========================= + +La TrustDB est construire à partir d'enregistrements à taille fixe, où le premier +octet décrit le type d'enregistrement. Toutes les valeurs numériques sont +conservées dans un réseau d'ordre d'octets. La longueur de chaque enregistrement +est de 40 octets. Le premier enregistrement de la TrustDB est toujours de type 1 +et c'est le seul enregistrement de ce type. + + Record type 0: + -------------- + + Cet enregistrement n'est pas utilisé. Il peut être utilisé + à votre discrétion. + + Record type 1: + -------------- + + Indique la version de la TrustDB. Cet enregistrement doit toujours être + le premier enregistrement de la base de données et c'est le seul + enregistrement de type 1. + + 1 octet valeur : 1 + 3 octets 'gpg' valeur "magic" + 1 octet Version de la TrustDB (2) + 1 octet marginales requises + 1 octet complètes requises + 1 octet max_cert_depth + + Ces trois éléments sont utilisés pour vérifier si la valeur de validité + mise en cache dans l'enregistrement du répertoire peut être utilisée : + + 1 u32 locked flags + 1 u32 datation de la création de la trustdb + 1 u32 datation de la dernière modification + + Cette datation pourrait affecter la validité des clefs dans la base de + données. Cette valeur sera comparée à celle de la datation de validité + des enregistrements dir : + + 1 u32 datation de la dernière validation + + Cette valeur sera utilisée pour stocker le passage du temps, lorsque + cette TrustDB sera comparée au trousseau de clefs publiques : + + 1 u32 numéro de l'enregistrement du keyhashtable + 1 u32 premier enregistrement libre + 1 u32 numéro de l'enregistrement répertoire shadow de la table de hachage + + Cette table ne devrait pas être combinée avec la table de clefs car le + keyid n'est pas dans chaque cas un élément du fingerprint. + + 4 bytes réservés pour l'enregistrement d'extension de version + + + Record type 2: (enregistrement répertoire) + -------------- + + Regroupe les informations sur un certificat de clef publique. + Ces valeur sont statiques et ne sont jamais modifiées sans une + interaction avec l'utilisateur : + + 1 octet valeur : 2 + 1 octet réservé + 1 u32 LID . (numéro d'enregistrement de cet enregistrement) + 1 u32 Liste de key-records (le premier est la clef primaire) + 1 u32 Liste de uid-records + 1 u32 cache record + 1 octet ownertrust + 1 octet dirflag + 1 octet validité maximale de tous les id utilisateurs + 1 u32 datation de la dernière vérification de validité + 1 u32 Vérification requise lorsque cette datation sera atteinte + (0 = pas de vérification requise) + + + Record type 3: (enregistrement de clef) + -------------- + + Regroupe les informations sur une clef publique primaire. + (ces informations sont principalement utilisées pour réaliser les lookup + dans l'enregistrement trust) + + 1 octet valeur : 3 + 1 octet réservé + 1 u32 LID + 1 u32 next - prochain enregistrement + 7 octets réservés + 1 octet keyflags + 1 octet algorithme de la clef publique + 1 octet taille du fingerprint (en octets) + 20 octets fingerprint de la clef publique + (Cette valeur est utilisée pour identifier toute clef) + + Record type 4: (enregistrement uid) + -------------- + + Regroupe les informations sur un id utilisateur (un "uid"). + Nous ne stockons par l'uid mais un hachage de l'uid : cela semble suffire. + + 1 octet valeur : 4 + 1 octet réservé + 1 u32 LID pointe vers l'enregistrement directory + 1 u32 next le userid suivant + 1 u32 pointeur vers l'enregistrement preference + 1 u32 siglist liste de signatures valides + 1 octet uidflags + 1 octet validité de la clef calculée pour cet userid + 20 bytes ripemd160 hachage du nom de l'utilisateur + + + Record type 5: (enregistrement pref) + -------------- + + Regroupe les informations formant les préférences. + + 1 octet valeur : 5 + 1 octet réservé + 1 u32 LID; pointe vers l'enregistrement directory (et PAS vers le uid !!!) + (égal à 0 pour un enregistrement de préférences standard) + 1 u32 suivant + 30 byte données de préférences + + Record type 6 (sigrec) + ------------- + + Cet enregistrement est utilisé pour traquer les signatures de clefs. Les + auto-signatures ne sont pas conservées. Si une clef publique ne se trouve + pas dans la TrustDB, la signature pointe vers un enregistrement dir fantôme, + lequel contient une liste des enregistrements qui seraient intéressés + par cette clef (et l'enregistrement signature en fait partie). + + 1 octet valeur : 6 + 1 octet réservé + 1 u32 LID pointe en retour vers l'enregistrment dir + 1 u32 next prochain sigrec de cet uid ou bien 0 pour indiquer que ce + sigrec est le dernier. + 6 times + 1 u32 Local_id des dir signatures ou de l'enregistrement dir fantôme + 1 octet Flag: Bit 0 = vérifié: Bit 1 est valide (nous avons un + véritable enregistrement directory) + 1 = valide est vrai (mais pourrait être révoqué) + + + + Record type 8: (enregistrement répertoire (dir) fantôme) + -------------- + + Cet enregistrement est utilisé pour réserver un LID pour une clef publique. + Nous avons besoin de cet enregistrement pour créer les enregistrements sigs + des autres clefs, même si nous ne disposons pas d'une signature de la clef + publique. + Cet enregistrement (le numéro d'enregistrement pour être plus précis) + sera réutilisé dans l'enregistrement dir lorsque nous importerons la + véritable clef publique. + + 1 octet valeur : 8 + 1 octet réservé + 1 u32 LID (Ceci est simplement le numéro d'enregistrement de ce record.) + 2 u32 keyid + 1 octet algorithme de la clef publique + 3 octets réservé + 1 u32 hintlist + + hintlist contient la liste des enregistrements qui ont des références qui pointent + vers cette clef. Nous utilisons cet élément pour augmenter la vitesse d'accès + des enregistrements de signature qui ne sont pas encore vérifiés. Notez que ces + données ne sont qu'un indice, une indication ("hint") mais les enregistrements actuels + pourraient ne pas détenir d'enregistrement de signature pour la clef, mais le + code du programme saura prendre soin de tout cela. + + 18 octets réservés + + + + Record Type 10 (table de hachage) + -------------- + + Comme nous utilisons les fingerprint pour accéder aux clefs, nous devons + implémenter un accès rapide en utilisant des méthodes de hachages simples, + afin d'éviter une surcharge de gdbm. La propriété des fingerprint + est qu'ils permettent un usage direct en tant que valeurs hachées (ils + peuvent être considérés comme des nombres aléatoires cryptographiquement + forts). + Nous utilisons une architecture à multiples niveaux dynamique, qui combine + les tables de hachage, les listes d'enregistrements et les listes + chaînées. + + Cet enregistrement est une table de hachages de 256 entrées ; une propriété + spéciale est que tous les enregistrements sont stockés consécutivement + pour produire une grande table. La valeur hachée est simplement le 1er, + 2nd.. octet du fingerprint (selon le niveau d'indirection). + + Lorsque nous les utilisons pour hacher les enregistrements de répertoires + shadow, une différente table est utilisée, et elle se trouve indexée + par le keyid. + + 1 octet valeur : 10 + 1 octet réservé + n u32 recnum; n dépend de la taille de l'enregistrement : + n = (reclen-2)/4 ce qui donne 9 pour la taille actuelle + d'enregistrement de 40 octets. + + Le nombre total de ces enregistrements constituant la table est : + + m = (256+n-1) / n + + ce qui donne 29 pour une taille d'enregistrement de 40. + + Pour rechercher une clef, nous utilisons le premier octet du fingerprint + pour obtenir le recnum de la table de hachage et nous étudions l'enregistrement + adressé : + + o Si cet enregistrement est une autre table de hachage, nous pouvons + utiliser le second octet pour indexer cette table de hachage et continuer. + + o Si cet enregistrement est une liste de hachages, nous pouvons parcourir + toutes les entrées jusqu'à trouver la bonne. + + o Si cet enregistrement est un enregistrement de clef, nous comparons + le fingerprint avec celui recherché et nous déterminons s'il s'agit + de la clef recherchée. + + + + Record type 11 (liste hachée) + -------------- + + Consultez la table hachée pour une explication. + Ceci sera également utilisé à d'autres fins. + + 1 octet valeur : 11 + 1 octet réservé + 1 u32 next enregistrement de liste hachée suivant + n times n = (reclen-5)/5 + 1 u32 recnum + + Pour la taille actuelle utilisée par les enregistrements (taille 40) nous avons n = 7. + + + + + Record type 254 (enregistrement libre) + --------------- + +Tous ces enregistrements forment une liste chaînée d'enregistrements non-utilisés. + + 1 octet valeur 254 + 1 octet réservé (0) + 1 u32 next_free + + + +En-têtes de paquets +=================== + +GnuPG utilise des en-têtes PGP 2 et il est aussi capable de comprendre +les en-têtes de type OpenPGP. C'est une amélioration utilisée sur les anciens +en-têtes de paquets : + +Les CTB bits 10, les "packet-length length bits" ont leurs valeurs listées +dans la table suivante : + + 00 - 1-octet champ packet-length + 01 - 2-octets champ packet-length + 10 - 4-octets champ packet-length + 11 - pas de taille de paquet fournie, taille inconnue + +Comme indiqué dans cette table, selon la taille du packet-length les +octets restants (1, 2, 4 ou 0) du champ de structure de paquets sont +un "champ packet-length". Ce champ est une valeur numérique à part entière. +La valeur du champ packet-length est définie par la valeur de la +totalité du champ numérique. + +La valeur 11 est actuellement utilisée dans un cas : les données +compressées. C''est à dire qu'un bloc de données compressées +ressemble à : où A3 est le binaire "10 1000 11" et +produit ici un paquet de taille non-définie. L'interprétation +correcte en est : "jusqu'à la fin de la structure englobante" +bien qu'en fait la structure englobante soit généralement +le fichier. + ++ Ceci sera modifié dans une future version, où la signification de la ++ valeur 11 (voir ci-dessous) aura aussi sa place. ++ ++ Une valeur de 11 pour d'autres paquets active un codage spécial ++ de la taille, où la taille du paquet suivant ne pourra pas être ++ déterminée avant l'écriture du paquet, en particulier ceci sera ++ utilisé si de grande quantités de données sont à traiter dans ++ un mode filtre. ++ ++ Ceci fonctionne de la manière suivante : après le CTB (qui est un ++ champ de longueur de 11) un champ marqueur sera utilisé, il indiquera ++ alors la taille du bloc de données suivant. C'est un simple champ ++ de deux octets (MSB en premier) contenant la quantité de données qui ++ suivent le champ, sans inclure le champ de taille toutefois. Après ++ ce bloc de données un autre champ de taille suivra, qui donnera la taille ++ du bloc de données suivant. Une valeur de 0 indique une fin de paquet. ++ La taille maximale d'un bloc de données est limitée à 65534, ce qui ++ réserve la valeur 0xffff pour des extensions futures. Ces marqueurs de ++ taille devront être insérés dans le flux de données avant que les ++ données ne soient envoyées en sortie. ++ ++ Ce champ de deux octets est largement suffisant, car l'application ++ doit placer en tampon cette quantité de données pour précéder le ++ marqueur de taille avant de produire une sortie. Les blocs de données ++ d'une taille supérieure à 32 Ko n'ont aucun sens. Notez que ceci pourra ++ également être utilisé pour les flux de données compressées, mais ++ nous devrons alors utiliser une autre version de paquet afin de dire à ++ l'application qu'elle ne peut assumer qu'il s'agit du dernier paquet. + + +Extensions GNU à l'algorithme S2K +================================= + +Le S2K mode 101 est utilisé pour identifier ces extensions. +Après l'algorithme de hachage les trois octets "GNU" sont utilisés +pour indiquer clairement qu'il s'agit d'extensions GNU et les octets +qui suivent donnent le mode de protection GNU utilisé : 1000. Les +modes définis sont : + + 1001 - ne pas conserver du tout de partie secrète + + + +Usage des fichiers gdbm pour les trousseaux de clefs +==================================================== + +La clef utilisé pour stocker le keyblock est son propre fingerprint, +les autres enregistrements sont utilisés pour les clefs secondaires. +Les fingerprint font toujours 20 octets où 16 bits de fingerprint +sont suivis par 0. Le premier octet de chaque clef indique une +information sur le type de clef : + + 1 = la clef est un fingerprint de 20 octets (16 octets fpr "paddés" de 0) + les données sont le keyblock + 2 = la clef est un keyid complet de 8 octets + les données sont une liste de 20 octets fingerprints + 3 = la clef est un keyid court de 4 octets + les données sont une liste de 20 octets fingerprints + 4 = la clef est une adresse email + les données sont une liste de 20 octets fingerprints + + Les données sont pre-appended (précédées) par un octet de type : + + 1 = keyblock + 2 = liste de 20 octets fingerprints "paddés" + 3 = liste de liste de fingerprints ("but how to we key them?") + + + +Pipemode +======== + +Ce mode est utilisé pour réaliser des opérations multiples avec un +unique appel à gpg. C'est assez pratique lorsqu'il faut pouvoir vérifier +un grand nombre de signatures. Actuellement nous n'avons qu'un support +des signatures détachées. Ce mode est une astuce qui permet d'éviter +de faire fonctionner gpg n en daemon mode et d'utiliser les Unix Domain +Sockets pour lui faire passer les données. Il n'existe aucun moyen +pratique de portabilité de ce concept sous Windows, alors nous utilisons +des pipes simples pour faire fonctionner ce mode sous Windows. Comme nous +n'avons aucun moyen de signaler des EOF multiples dans un pipe nous +devons laisser le contrôle s'insérer dans le flux de données lui-même. +Nous réalisons alors une distinction entre les données du flux et un +état de contrôle. A son lancement, le système se trouve dans un état +de données mais n'acceptera aucune donnée. Il attend en fait une +transition vers un mode de contrôle qui s'obtient en envoyant un simple +caractère '@'. Une fois dans le mode de contrôle, des commandes sont +attendues et ces commandes sont à un octet après lequel le système +revient au mode de données (mais cela n'implique pas qu'il acceptera +des données immédiatement). La commande de contrôle la plus simple +est '@' qui permet d'insérer ce caractère dans le flux de données. + +Voici le format que nous utilisons pour les signatures détachées : + +"@<" - Début d'un nouveau flux +"@B" - La signature détachée suit. + Ceci émet le paquet de contrôle (1,'B') + +"@t" - Le texte signé suit. + Ceci émet le paquet de contrôle (2, 'B') + +"@." - Fin de l'opération. Le paquet de contrôle final force la + vérification de la signature. +"@>" - Fin du flux. + + + +Autres notes +============ + +Dans la version* 3 de version de paquet nous calculons les keyid de cette manière : + +RSA : les 64 bits de poids faible de n +ELGAMAL : nous construisons un paquet de clef publique v3 (avec CTB 0x99) + et nous calculons une valeur hachée rmd160 à partir de ce paquet. + Il est utilisé comme fingerprint avec les 64 bits de poids faible + qui produisent le keyid. + +* Les certificats de révocation ne comportent qu'un paquet de signature ; +"import" sait comment traiter ces paquets. L'idée derrière ce principe +est de conserver une petite taille de paquet. + + + +Format des messages Keyserver +============================= + +Le serveur de clef peut être contacté par un Unix Domain Socket ou via TCP. + +Le format des requêtes est : + +==== +command-tag +"Content-length:" digits +CRLF +======= + +Où le command-tag est : + +NOOP +GET +PUT +DELETE + + +Le format de réponse utilisé est : + +====== +"GNUPG/1.0" status-code status-text +"Content-length:" digits +CRLF +============ + +suivi par octets de données. + + +Les codes de statut utilisés sont : + + o 1xx: Information: requête reçue, traitement en cours. + + o 2xx: Succès - L'action a été reçue, comprise et acceptée. + + o 4xx: Erreur client : la requête contient une erreur, mauvaise syntaxe + ou demande irréalisable. + + o 5xx: Erreur serveur - Le serveur n'a pu traiter une demande + qui semble valide. + + +Documentation sur HKP (le protocol de serveurs de clefs http) +============================================================= + +Un serveur HTTP minimal sur port 11371 reconnaît les requêtes GET +pour /pks/lookup. Les paramètres standard encodés URL de la requête +sont toujours ceux-ci : (toujours key=valeur) + +- op=index (comme pgp -kv), op=vindex (comme pgp -kvv) and op=get (comme + pgp -kxa) + +- search=. Nous avons ici une liste de mots qui doivent + apparaître dans la clef. Ces mots sont séparés par des espaces, + points, @, etc. Les délimiteurs ne feront pas partie de la + recherche et l'ordre des mots n'a aucune importance (mais consultez + l'option suivante). + +- exact=on. Ce switch permet d'indiquer au serveur hkp qu'il ne doit + rechercher que les correspondances exactes. Dans ce cas, les + délimiteurs et l'ordre des mots sera considéré. + +- fingerprint=on. Renvoie également les fingerprint, lorsque utilisé + avec 'index' ou 'vindex' + +Les serveurs de clefs savent aussi reconnaître le format http-POST vers /pks/add. +Vous utilisez ceci pour envoyer des clefs au serveur. + +Le mieux pour produire une requête reste : + + /pks/lookup/?op= + +Ceci peut être implémenté en utilisant le mécanisme de traduction Hurd. +Toutefois, nous pensons que les traitements du serveur de clef doivent +faire l'objet d'une refonte. diff --git a/doc/fr/FAQ b/doc/fr/FAQ new file mode 100644 index 000000000..48c28ae76 --- /dev/null +++ b/doc/fr/FAQ @@ -0,0 +1,1111 @@ + +GNUPG : FOIRE AUX QUESTIONS + +Version : 1.2 +Dernière modification : 10 septembre 2001 +Maintenu par : Nils Ellmenreich +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. , +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. diff --git a/doc/fr/README.fr b/doc/fr/README.fr new file mode 100644 index 000000000..3a5d8485e --- /dev/null +++ b/doc/fr/README.fr @@ -0,0 +1,10 @@ +You find here translations to French of some of the documents in +../doc. Those translations are not necessary up-to-date and should +not be used as reference without checking the original English +versions. + +Gilbert Fernandes kindly contributed thses translatons. + + + +