diff options
Diffstat (limited to 'doc/fr')
| -rw-r--r-- | doc/fr/ChangeLog | 17 | ||||
| -rw-r--r-- | doc/fr/DETAILS | 945 | ||||
| -rw-r--r-- | doc/fr/FAQ | 1111 | ||||
| -rw-r--r-- | doc/fr/README.fr | 10 |
4 files changed, 0 insertions, 2083 deletions
diff --git a/doc/fr/ChangeLog b/doc/fr/ChangeLog deleted file mode 100644 index 167093dcc..000000000 --- a/doc/fr/ChangeLog +++ /dev/null @@ -1,17 +0,0 @@ -2001-09-10 Gilbert Fernandes <[email protected]> - - * 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 deleted file mode 100644 index 5c7246c9d..000000000 --- a/doc/fr/DETAILS +++ /dev/null @@ -1,945 +0,0 @@ - -Format des listings "---with-colons" -==================================== - -sec::1024:17:6C7EE1B8621CC013:1998-07-07:0:::Werner Koch <[email protected]>: -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 - "#<local-id>" 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 <long keyid> <username> - 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 <long keyid> <username> - La signature keyid n'a pas été vérifiée correctement. - - ERRSIG <long keyid> <pubkey_algo> <hash_algo> \ - <sig_class> <timestamp> <rc> - 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 <fingerprint in hex> <sig_creation_date> <sig-timestamp> - 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 <radix64_string> <sig_creation_date> <sig-timestamp> - 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 <long keyid> <keytype> <keylength> - 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 <what> - 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 <what> - 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 <long main keyid> <long keyid> <keytype> <keylength> - 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 <cipher_algo> <s2k_mode> <s2k_hash> - 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 <long keyid> - 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 <long keyid> - NO_SECKEY <long keyid> - La clef n'est pas utilisable. - - IMPORTED <long keyid> <username> - Le keyid et la signature ont été importés. - - IMPORTED_RES <count> <no_user_id> <imported> <imported_rsa> <unchanged> - <n_uids> <n_subk> <n_sigs> <n_revoc> <sec_read> <sec_imported> <sec_dups> - Statistiques finales sur le processus d'importation (cette ligne est longue!) - - FILE_START <what> <filename> - Début de traitement du fichier <filename>. <what> 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 <type> <pubkey algo> <hash algo> <class> <timestamp> <key fpr> - 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 <type> - Une clef a été créée - type: 'B' = primaire et sous-clef - 'P' = primaire - 'S' = sous-clef - - SESSION_KEY <algo>:<hexdigits> - 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 <name> - NOTATION_DATA <string> - 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 <long main keyid> <string> - Donne un indice sur l'ID utilisateur pour un keyID donné. - - POLICY_URL <string> - 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 <texte> - Affiche <texte> - - %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 <filename> - %secring <filename> - Ne renvoie pas la clef vers le sortie par défaut ou dans le keyring - indiqué en ligne de commande, mais vers le fichier <filename>. 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: <algo-number>|<algo-string> - 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: <length-in-bits> - Indique la taille de la clef, en bits. La valeur par défaut est - 1024. - - Subkey-Type: <algo-number>|<algo-string> - Permet de produire une clef secondaire. Actuellement, seule une - sous-clef peut être gérée. - - Subkey-Length: <length-in-bits> - Taille de la sous-clef en bits. La valeur par défaut est - 1024. - - Passphrase: <string> - 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: <string> - Name-Comment: <string> - Name-Email: <string> - 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: <iso-date>|(<number>[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 <<EOF - %echo Génération d'une clef standard - Key-Type: DSA - Key-Length: 1024 - Subkey-Type: ELG-E - Subkey-Length: 1024 - Name-Real: Joe le testeur - Name-Comment: ma phrase passe est stupide - Name-Email: [email protected] - Expire-Date: 0 - Passphrase: abc - %pubring foo.pub - %secring foo.sec - # Un commit est requis ici, pour pouvoir afficher un "done" :-) - %commit - %echo done -EOF -$ gpg --batch --gen-key -a foo - [...] -$ gpg --no-default-keyring --secret-keyring foo.sec \ - --keyring foo.pub --list-secret-keys -/home/wk/work/gnupg-stable/scratch/foo.sec ------------------------------------------- -sec 1024D/915A878D 2000-03-09 Joe le testeur (ma phrase passe est stupide) <[email protected]> -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 à : <A3 01 .. .. > 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') -<detached_signature> -"@t" - Le texte signé suit. - Ceci émet le paquet de contrôle (2, 'B') -<signed_text> -"@." - 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 <user-name> -PUT -DELETE <user-name> - - -Le format de réponse utilisé est : - -====== -"GNUPG/1.0" status-code status-text -"Content-length:" digits -CRLF -============ - -suivi par <digits> 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=<stringlist>. 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/<gnupg_formatierte_user_id>?op=<operation> - -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 deleted file mode 100644 index 48c28ae76..000000000 --- a/doc/fr/FAQ +++ /dev/null @@ -1,1111 +0,0 @@ - -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. diff --git a/doc/fr/README.fr b/doc/fr/README.fr deleted file mode 100644 index 3a5d8485e..000000000 --- a/doc/fr/README.fr +++ /dev/null @@ -1,10 +0,0 @@ -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. - - - - |