diff options
Diffstat (limited to 'doc/fr/DETAILS')
| -rw-r--r-- | doc/fr/DETAILS | 945 |
1 files changed, 945 insertions, 0 deletions
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 <[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. |