2
Format des listings "---with-colons"
3
====================================
5
sec::1024:17:6C7EE1B8621CC013:1998-07-07:0:::Werner Koch <werner.koch@guug.de>:
6
ssb::1536:20:5CE086B5B5A18FF4:1998-07-07:0:::
8
1. Champ: Type d'enregistrement
10
sub = sous-clef (clef secondaire)
12
ssb = sous-clef secrète (clef secondaire)
13
uid = id d'utilisateur (seul le champ 10 est utilisé)
15
fpr = fingerprint: (le champ 10 est le fingerprint)
16
pkd = données publiques de la clef
17
(champ au format spécial, voir ci-dessous)
19
2. Champ: Une lettre décrivant la confiance calculée. Ce n'est qu'une
20
seule lettre, mais elle fera peut-être l'objet d'une information
21
supplémentaire pour les versions futures, comme décrit ici
22
(ceci ne sera pas utilisé pour les clefs privées)
23
o = Inconnu (cette clef est nouvelle au système)
24
i = La clef est invalide (eg. il manque sa propre signature)
25
d = La clef a été désactivée
26
r = La clef a été révoquée
28
q = Non-défini (pas de valeur attribuée)
29
n = Ne jamais faire confiance à cette clef
30
m = Cette clef dispose d'une confiance marginale
31
f = Cette clef dispose d'une confiance totale
32
u = Cette clef dispose d'une confiance ultime. Cette valeur
33
n'est utilisée que pour les clefs où la clef secrète est
34
également disponibles.
35
3. Champ: taille de la clef en bits.
36
4. Champ: Algorithme utilisé: 1 = RSA
37
16 = ElGamal (chiffrement uniquement)
38
17 = DSA (parfois appellé DH, signature seulement)
39
20 = ElGamal (signe et chiffre)
40
(pour d'autres is, consultez include/cipher.h)
41
5. Champ: ID de clef (KeyID)
42
6. Champ: Date de création (en UTC)
43
7. Champ: Date d'expiration de la clef, vide si aucune.
44
8. Champ: ID local : numéro d'enregistrement du répertoire dans la
45
trustdb. Cette valeur n'est valide que tant que la
46
trustdb n'est pas effacée. Vous pouvez utiliser
47
"#<local-id>" comme id d'utilisateur lorsque vous spécifiez
48
la clef. Ceci est requis puisque les id de clef ne sont pas
49
toujours uniques - un programme peut donc utiliser ce numéro
50
pour accéder aux clefs ultérieurement.
51
9. Champ: Confiance propre (clef publiques primaires uniquement)
52
C'est une simple lettre, mais une information supplémentaire pourrait
53
se voir ajoutée dans les versions futures.
54
10. Champ: ID utilisateur. La valeur est placée entre guillemets comme une
55
chaîne en C, par exemple : "\x3a".
56
11. Champ: Classe de signature. C'est un nombre hexadécimal à deux chiffres
57
suivi par la lettre "x" si la signature peut être exportée ou la
58
lettre "l" si la signature est uniquement locale.
59
12. Champ: Capacités de la clef :
63
Une clef peut disposer de toute combinaison de ces caractéristiques.
64
La clef primaire dispose, en plus de ces lettres, une version en
65
majuscule des lettres pour marquer les capacités "d'utilisation"
66
de la totalité de la clef.
68
Toutes les dates sont affichées dans le format :
72
Sauf si vous utilisez l'option --fixed-list-mode où dans ce cas précis les
73
dates sont affichées en secondes depuis Epoch. Plus de champs feront l'objet
74
d'additions dans les futures versions et les parsers doivent y être préparés.
75
Lorsque le parser traitera ces données, il devra s'arrêter au premier
76
caractère non-numérique afin que des informations supplémentaires soient
79
Le champ 1 dispose d'un tag "pkd" dont le listing ressemble à ceci :
81
pkd:0:1024:B665B1435F4C2 .... FF26ABB:
83
! !------ indicateur du nombre de bits de la valeur
84
!--------- index (eg. DSA va de 0 à 3 : p,q,g,y)
88
Format de la sortie "--status-fd"
89
=================================
91
Chaque ligne dispose d'un préfixe :
95
Suivie par un mot clef indiquant le type de la ligne de statut,
96
et quelques arguments selon le type (probablement aucun) ; une application
97
devrait toujours assumer que des arguments supplémentaires seront
98
présents dans les versions futures.
100
GOODSIG <long keyid> <username>
101
La signature keyid est valide.
102
Pour chaque signature seul l'un des trois codes GOODSIG, BADSIG ou
103
ERRSIG seront produits et ils pourront être utilisés comme
104
marqueurs pour les nouvelles signatures.
106
BADSIG <long keyid> <username>
107
La signature keyid n'a pas été vérifiée correctement.
109
ERRSIG <long keyid> <pubkey_algo> <hash_algo> \
110
<sig_class> <timestamp> <rc>
111
Il n'a pas été possible de vérifier la signature. Ceci peut provenir
112
d'une clef publique manquante, ou bien à cause d'un algorithme non-
113
supporté. Un RC de 4 indique un algorithme inconnu, un 9 indique
114
une clef publique manquante. Les autres champs donnent plus d'information
115
sur la signature. sig_class est une valeur hexadécimale de 2 octets.
117
VALIDSIG <fingerprint in hex> <sig_creation_date> <sig-timestamp>
118
La signature keyid est valide. C'est ici la même chose que GOODSIG
119
mais avec le fingerprint comme argument. Les lignes de statut seront
120
émises pour une bonne signature.
121
sig-timestamp est la date de création de la signature en secondes
124
SIG_ID <radix64_string> <sig_creation_date> <sig-timestamp>
125
N'est émis que pour les signatures de classe 0 ou 1 qui ont été
126
vérifiées comme valides. Le chaîne est un identifiant d'utilisateur
127
et peut être utilisée dans les applications pour détecter les
128
attaques par rejeu de messages signés. Notez que seuls les
129
algorithmes DLP offrent des identifiants uniques ; les autres peuvent
130
produire des id dupliqués lorsqu'ils furent créés à la même seconde.
132
ENC_TO <long keyid> <keytype> <keylength>
133
Le message est chiffré avec ce keyid.
134
keytype est une valeur numérique de l'algorithme à clef publique,
135
keylength est la taille de la clef ou 0 si elle n'est pas connue
136
(ce qui est toujours le cas).
139
Aucune donnée n'a été trouvée. Les codes suivants sont utilisés :
140
1 - Pas de données sous ARMOR.
141
2 - Un paquet attendu n'a pas été trouvé.
142
3 - Paquet invalide trouvé ; ceci peut indiquer un message
143
non-OpenPGP. Vous devez vous attendre à une extension
144
de ces lignes de statu à l'avenir.
147
Des données innatendues ont été rencontrées
148
0 - pas de détail supplémentaire
155
Pour les signatures valides, l'une de ces lignes de statut sera produite
156
pour indiquer le niveau de confiance attribué à la clef. Pas d'arguments
160
La clef de signature a expiré. Pas d'arguments pour l'instant.
163
L'utilisateur a révoqué sa clef. Pas d'arguments pour l'instant.
166
L'ARMOR ASCII est corrompu. Pas d'arguments pour l'instant.
169
Les algorithmes IDEA ont été utilisés sur les données. Un programme
170
pourra basculer sur un autre programme de traitement si GnuPG échoue.
171
Ce message de statut sera affiché pour le RSA aussi, mais ceci a été
172
abandonné puisque le brevêt sur le RSA a expiré.
173
Toutefois, nous ne pouvons modifier le nom du message.
185
NEED_PASSPHRASE <long main keyid> <long keyid> <keytype> <keylength>
186
Sera affiché à chaque fois qu'une phrase passe sera requise.
187
keytype est la valeur numérique de l'algorithme à clef publique
188
ou bien 0 si cela n'est pas applicable. keylength est la taille de la
189
clef ou 0 si la taille n'est pas connue (ceci est actuellement
192
NEED_PASSPHRASE_SYM <cipher_algo> <s2k_mode> <s2k_hash>
193
Affiché à chaque fois qu'une phrase passe pour un chiffrement
194
symétrique sera requise.
197
Aucune phrase passe n'a été fournie. Une application qui rencontre
198
ce message devrait stopper immédiatement le parsing car le prochain
199
message sera probablement BAD_PASSPHRASE. Toutefois, si l'application
200
n'est qu'un wrapper autour de la fonctionnalité d'édition de clefs,
201
ceci pourrait avoir un autre sens et stopper le parsing pourrait
202
être incorrect, et il faudra ignorer le BAD_PASSPHRASE.
204
BAD_PASSPHRASE <long keyid>
205
La phrase passe fournie est soit invalide, soit n'a pas été fournie.
206
Dans le seconde cas vous devriez voir un MISSING_PASSPHRASE.
209
La phrase passe fournie est valide et le matériel de clefs secrète
213
La déchiffrement symétrique a échoué. Il s'agit généralement d'une
214
mauvaise phrase passe ne correspondant pas au message chiffré.
217
Succès du déchiffrement. Ceci signifie que soit la clef secrète
218
adaptée a été utilisée avec succès, soit que la phrase passe
219
valide pour un chiffrement symétrique aura conduit au déchiffrement.
220
Le programme pourait toutefois renvoyer un message d'erreur s'il
221
n'a pas été possible de vérifier la signature.
223
NO_PUBKEY <long keyid>
224
NO_SECKEY <long keyid>
225
La clef n'est pas utilisable.
227
IMPORTED <long keyid> <username>
228
Le keyid et la signature ont été importés.
230
IMPORTED_RES <count> <no_user_id> <imported> <imported_rsa> <unchanged>
231
<n_uids> <n_subk> <n_sigs> <n_revoc> <sec_read> <sec_imported> <sec_dups>
232
Statistiques finales sur le processus d'importation (cette ligne est longue!)
234
FILE_START <what> <filename>
235
Début de traitement du fichier <filename>. <what> indique l'opération
240
Marque la fin de traitement d'un fichier, ayant débuté avec FILE_START.
244
Marque le début et la fin du processus de déchiffrement. Ces messages
245
seront également produits lors de l'utilisation du mode --list-only.
249
Marque le début et la fin du processus de chiffrement.
251
DELETE_PROBLEM reason_code
252
L'effacement d'une clef a échoué. Un code indique la raison de l'erreur :
253
1 - La clef spécifiée n'existe pas
254
2 - La clef privée doit être détruite avant !
256
PROGRESS what char cur total
257
Utilisé par les fonctions primegen et de clef publique pour indiquer
258
la progression de l'opération. "char" est le caractère affiché sans
259
--status-fd avec les retours à la ligne marqués par "X". "cur" indique
260
la quantitité de traitement terminée et "total" indique la valeur
261
finale à atteindre. Un total de 0 indique que le total n'est pas
262
connu. 100/100 peut être utilisé pour détecter la fin de l'opération.
264
SIG_CREATED <type> <pubkey algo> <hash algo> <class> <timestamp> <key fpr>
265
Une signature a été créée à l'aide de ces paramètres.
269
(seul le premier caractère doit être vérifié)
270
class: 2 chiffres hexadécimaux avec la classe de signature
274
type: 'B' = primaire et sous-clef
278
SESSION_KEY <algo>:<hexdigits>
279
La clef de session utilisée pour déchiffrer le message. Ce message
280
sera seulement affiché si l'option --show-session est utilisée.
281
Le format est utilisable pour un passage direct à la fonction
282
--override-session-key.
285
NOTATION_DATA <string>
286
Le nom et la chaîne sont "escaped" à l'aide de %XX et les données
287
peuvent être découpées sur plusieurs lignes notation_data.
289
USERID_HINT <long main keyid> <string>
290
Donne un indice sur l'ID utilisateur pour un keyID donné.
293
La chaîne est "escaped" en %XX
297
Produit par pipemode.
303
La génération de clef marque sa progression à l'aide de différents caractères, dont
304
voici la signification :
306
"." : les 10 derniers tests Miller-Rabin ont échoué.
307
"+" : réussite du test Miller-Rabin.
308
"!" : Rechargement du pool avec des nombres premiers frais.
309
"^" : Vérification d'une nouvelle valeur pour le générateur.
310
"<" : La taille d'un facteur a été réduite.
311
">" : La taille d'un facteur a été augmentée.
313
Le nombre premier pour l'ElGamal est généré de la manière suivante :
315
1. On crée un nombre premier q de 160, 200 ou 240 bits (selon la taille
317
2. On sélectionne la taille de l'autre facteur premier, afin qu'elle soit
318
au moins de la taille de q et on calcule le nombre de facteurs premiers
320
3. On crée un pool de nombres premiers, chacun dont la longueur fut déterminée
322
4. On obtient une nouvelle permutation du pool et nous continuons avec
323
l'étape 3 une fois toutes les permutations testées.
324
5. Le premier cancidat est calculé par p = 2 * q * p[1] * ... * p[n] + 1
325
6. On vérifie que ce premier dispose de la taille désirée (ceci peut changer
326
q s'il ne semble pas possible de produire un premier de la taille voulue)
327
7. On vérifie si ce nombre est premier à l'aide de divisions d'essai et par
328
le test de Miller-Rabin.
329
8. On continue à l'étape 4 si on n'a pas trouvé de premier à l'étape 7.
330
9. On trouve un générateur pour ce premier.
332
Cet algorithme se base sur la suggestion de Lim et Lee du Crypto' 97 (p. 260).
334
Génération de clef innatendue
335
=============================
337
Cette fonction est actuellement expérimentale et permet la production de
338
clefs innatendues avec un contrôle depuis un fichier de paramètres.
339
Cette fonctionnalité n'a pas fait l'objet de tests poussés ! Veuillez ne
340
PAS vous plaindre si nous décidons d'apporter des modifications importantes
343
Pour utiliser cette fonctionnalité, vous devez utiliser --gen-key en
344
combinaison avec --batch et fournir les paramètres soit depuis stdin,
345
soit depuis un fichier dont le nom est fourni en ligne de commande.
347
Ce fichier devra utiliser le format suivant :
349
o En texte uniquement, chaque ligne étant limitée à environ 1000 caractères.
350
o Vous devez utiliser un codage UTF-8 pour marquer les caractères non ASCII.
351
o Les lignes vides seront ignorées.
352
o Les espaces en début et fin de ligne seront ignorés.
353
o Un signe "-" en tant que premier caractère "non white space" marque
354
une ligne de commentaire.
355
o Les commandes sont marquées par un signe "%" en début de ligne,
356
suivi par la commande et ses arguments sont séparés par des espaces.
357
o Les paramètres sont indiqués par un mot clef, suivi par un ":". Les
358
arguments sont séparés par des espaces.
359
o Le premier paramètre doit être "Key-Type" et ses contrôles peuvent
360
être placés à votre discrétion.
361
o La génération de clef aura lieu soit à la fin du fichier de paramètres,
362
soit lorsque le premier "Key-Type" est rencontré au sein du fichier,
363
dans un ensenble de contrôle "%commit".
364
o Les ensembles de contrôle sont :
369
Ne réalise pas la production de clef (pratique pour vérifier la
373
Réalise la production de clef. Un commit implicite est produit
374
à chaque rencontre de "Key-Type".
378
Ne renvoie pas la clef vers le sortie par défaut ou dans le keyring
379
indiqué en ligne de commande, mais vers le fichier <filename>. Ce
380
contrôle doit être utilisé avant que le commit ne soit rencontré.
381
Toute double mention sera ignorée et le dernier nom de fichier
382
rencontré sera celui utilisé. Le fichier sera utilisé jusqu'à ce
383
qu'un nouveau fichier soit spécifié (au points de commit) sinon
384
toutes les clefs seront placées dans le même fichier. Si un nouveau
385
nom de fichier est indiqué, le fichier sera créé (et tout ancien
386
fichier sera alors écrasé). Les deux indications doivent être
387
fournies au contrôle.
389
o L'ordre des paramètres n'a pas d'importance, sauf pour "Key-Type" qui
390
doit être le premier paramètre rencontré. Les paramètres ne sont
391
destinés qu'au bloc keybloc généré et les paramètres des productions
392
précédentes de clefs ne seront pas pris en compte. Certaines
393
vérifications syntaxiques seront mises en place et peuvent être
394
ou non actives. Les paramètres actuellement définis sont :
396
Key-Type: <algo-number>|<algo-string>
397
Débute un nouveau bloc de paramètres indiquant le type de la clef
398
primaire à produire. L'algorithme doit être capable de produire
399
des signatures. Ce paramètre est indispensable !
401
Key-Length: <length-in-bits>
402
Indique la taille de la clef, en bits. La valeur par défaut est
405
Subkey-Type: <algo-number>|<algo-string>
406
Permet de produire une clef secondaire. Actuellement, seule une
407
sous-clef peut être gérée.
409
Subkey-Length: <length-in-bits>
410
Taille de la sous-clef en bits. La valeur par défaut est
414
Si vous souhaitez spécifier une phrase passe pour la clef
415
secrète vous pouvez utiliser cette commande. Par défaut,
416
aucune phrase passe ne sera associée aux clefs privées.
419
Name-Comment: <string>
421
Voici les trois composantes d'une clef. Vous devez ici
422
n'utiliser que de l'UTF-8. Si vous ne fournissez aucune
423
de ces indications, aucun ID d'utilisateur ne sera créé.
425
Expire-Date: <iso-date>|(<number>[d|w|m|y])
426
Spécifie la date d'expiration de la clef (et de sa sous-clef)
427
La date doit être entrée sous la forme d'une date au format
428
ISO (année-mois-jour) ou bien sous forme d'un nombre de
429
jours, de semaines, de mois ou d'années. Si vous n'utilisez
430
pas de lettre pour indiquer la durée, des "jours" sont
435
%echo Génération d'une clef standard
440
Name-Real: Joe le testeur
441
Name-Comment: ma phrase passe est stupide
442
Name-Email: joe@foo.bar
447
# Un commit est requis ici, pour pouvoir afficher un "done" :-)
451
$ gpg --batch --gen-key -a foo
453
$ gpg --no-default-keyring --secret-keyring foo.sec \
454
--keyring foo.pub --list-secret-keys
455
/home/wk/work/gnupg-stable/scratch/foo.sec
456
------------------------------------------
457
sec 1024D/915A878D 2000-03-09 Joe le testeur (ma phrase passe est stupide) <joe@foo.bar>
458
ssb 1024g/8F70E2C0 2000-03-09
462
Composition de la TrustDB
463
=========================
465
La TrustDB est construire à partir d'enregistrements à taille fixe, où le premier
466
octet décrit le type d'enregistrement. Toutes les valeurs numériques sont
467
conservées dans un réseau d'ordre d'octets. La longueur de chaque enregistrement
468
est de 40 octets. Le premier enregistrement de la TrustDB est toujours de type 1
469
et c'est le seul enregistrement de ce type.
474
Cet enregistrement n'est pas utilisé. Il peut être utilisé
480
Indique la version de la TrustDB. Cet enregistrement doit toujours être
481
le premier enregistrement de la base de données et c'est le seul
482
enregistrement de type 1.
485
3 octets 'gpg' valeur "magic"
486
1 octet Version de la TrustDB (2)
487
1 octet marginales requises
488
1 octet complètes requises
489
1 octet max_cert_depth
491
Ces trois éléments sont utilisés pour vérifier si la valeur de validité
492
mise en cache dans l'enregistrement du répertoire peut être utilisée :
495
1 u32 datation de la création de la trustdb
496
1 u32 datation de la dernière modification
498
Cette datation pourrait affecter la validité des clefs dans la base de
499
données. Cette valeur sera comparée à celle de la datation de validité
500
des enregistrements dir :
502
1 u32 datation de la dernière validation
504
Cette valeur sera utilisée pour stocker le passage du temps, lorsque
505
cette TrustDB sera comparée au trousseau de clefs publiques :
507
1 u32 numéro de l'enregistrement du keyhashtable
508
1 u32 premier enregistrement libre
509
1 u32 numéro de l'enregistrement répertoire shadow de la table de hachage
511
Cette table ne devrait pas être combinée avec la table de clefs car le
512
keyid n'est pas dans chaque cas un élément du fingerprint.
514
4 bytes réservés pour l'enregistrement d'extension de version
517
Record type 2: (enregistrement répertoire)
520
Regroupe les informations sur un certificat de clef publique.
521
Ces valeur sont statiques et ne sont jamais modifiées sans une
522
interaction avec l'utilisateur :
526
1 u32 LID . (numéro d'enregistrement de cet enregistrement)
527
1 u32 Liste de key-records (le premier est la clef primaire)
528
1 u32 Liste de uid-records
532
1 octet validité maximale de tous les id utilisateurs
533
1 u32 datation de la dernière vérification de validité
534
1 u32 Vérification requise lorsque cette datation sera atteinte
535
(0 = pas de vérification requise)
538
Record type 3: (enregistrement de clef)
541
Regroupe les informations sur une clef publique primaire.
542
(ces informations sont principalement utilisées pour réaliser les lookup
543
dans l'enregistrement trust)
548
1 u32 next - prochain enregistrement
551
1 octet algorithme de la clef publique
552
1 octet taille du fingerprint (en octets)
553
20 octets fingerprint de la clef publique
554
(Cette valeur est utilisée pour identifier toute clef)
556
Record type 4: (enregistrement uid)
559
Regroupe les informations sur un id utilisateur (un "uid").
560
Nous ne stockons par l'uid mais un hachage de l'uid : cela semble suffire.
564
1 u32 LID pointe vers l'enregistrement directory
565
1 u32 next le userid suivant
566
1 u32 pointeur vers l'enregistrement preference
567
1 u32 siglist liste de signatures valides
569
1 octet validité de la clef calculée pour cet userid
570
20 bytes ripemd160 hachage du nom de l'utilisateur
573
Record type 5: (enregistrement pref)
576
Regroupe les informations formant les préférences.
580
1 u32 LID; pointe vers l'enregistrement directory (et PAS vers le uid !!!)
581
(égal à 0 pour un enregistrement de préférences standard)
583
30 byte données de préférences
585
Record type 6 (sigrec)
588
Cet enregistrement est utilisé pour traquer les signatures de clefs. Les
589
auto-signatures ne sont pas conservées. Si une clef publique ne se trouve
590
pas dans la TrustDB, la signature pointe vers un enregistrement dir fantôme,
591
lequel contient une liste des enregistrements qui seraient intéressés
592
par cette clef (et l'enregistrement signature en fait partie).
596
1 u32 LID pointe en retour vers l'enregistrment dir
597
1 u32 next prochain sigrec de cet uid ou bien 0 pour indiquer que ce
598
sigrec est le dernier.
600
1 u32 Local_id des dir signatures ou de l'enregistrement dir fantôme
601
1 octet Flag: Bit 0 = vérifié: Bit 1 est valide (nous avons un
602
véritable enregistrement directory)
603
1 = valide est vrai (mais pourrait être révoqué)
607
Record type 8: (enregistrement répertoire (dir) fantôme)
610
Cet enregistrement est utilisé pour réserver un LID pour une clef publique.
611
Nous avons besoin de cet enregistrement pour créer les enregistrements sigs
612
des autres clefs, même si nous ne disposons pas d'une signature de la clef
614
Cet enregistrement (le numéro d'enregistrement pour être plus précis)
615
sera réutilisé dans l'enregistrement dir lorsque nous importerons la
616
véritable clef publique.
620
1 u32 LID (Ceci est simplement le numéro d'enregistrement de ce record.)
622
1 octet algorithme de la clef publique
626
hintlist contient la liste des enregistrements qui ont des références qui pointent
627
vers cette clef. Nous utilisons cet élément pour augmenter la vitesse d'accès
628
des enregistrements de signature qui ne sont pas encore vérifiés. Notez que ces
629
données ne sont qu'un indice, une indication ("hint") mais les enregistrements actuels
630
pourraient ne pas détenir d'enregistrement de signature pour la clef, mais le
631
code du programme saura prendre soin de tout cela.
637
Record Type 10 (table de hachage)
640
Comme nous utilisons les fingerprint pour accéder aux clefs, nous devons
641
implémenter un accès rapide en utilisant des méthodes de hachages simples,
642
afin d'éviter une surcharge de gdbm. La propriété des fingerprint
643
est qu'ils permettent un usage direct en tant que valeurs hachées (ils
644
peuvent être considérés comme des nombres aléatoires cryptographiquement
646
Nous utilisons une architecture à multiples niveaux dynamique, qui combine
647
les tables de hachage, les listes d'enregistrements et les listes
650
Cet enregistrement est une table de hachages de 256 entrées ; une propriété
651
spéciale est que tous les enregistrements sont stockés consécutivement
652
pour produire une grande table. La valeur hachée est simplement le 1er,
653
2nd.. octet du fingerprint (selon le niveau d'indirection).
655
Lorsque nous les utilisons pour hacher les enregistrements de répertoires
656
shadow, une différente table est utilisée, et elle se trouve indexée
661
n u32 recnum; n dépend de la taille de l'enregistrement :
662
n = (reclen-2)/4 ce qui donne 9 pour la taille actuelle
663
d'enregistrement de 40 octets.
665
Le nombre total de ces enregistrements constituant la table est :
669
ce qui donne 29 pour une taille d'enregistrement de 40.
671
Pour rechercher une clef, nous utilisons le premier octet du fingerprint
672
pour obtenir le recnum de la table de hachage et nous étudions l'enregistrement
675
o Si cet enregistrement est une autre table de hachage, nous pouvons
676
utiliser le second octet pour indexer cette table de hachage et continuer.
678
o Si cet enregistrement est une liste de hachages, nous pouvons parcourir
679
toutes les entrées jusqu'à trouver la bonne.
681
o Si cet enregistrement est un enregistrement de clef, nous comparons
682
le fingerprint avec celui recherché et nous déterminons s'il s'agit
683
de la clef recherchée.
687
Record type 11 (liste hachée)
690
Consultez la table hachée pour une explication.
691
Ceci sera également utilisé à d'autres fins.
695
1 u32 next enregistrement de liste hachée suivant
696
n times n = (reclen-5)/5
699
Pour la taille actuelle utilisée par les enregistrements (taille 40) nous avons n = 7.
704
Record type 254 (enregistrement libre)
707
Tous ces enregistrements forment une liste chaînée d'enregistrements non-utilisés.
718
GnuPG utilise des en-têtes PGP 2 et il est aussi capable de comprendre
719
les en-têtes de type OpenPGP. C'est une amélioration utilisée sur les anciens
720
en-têtes de paquets :
722
Les CTB bits 10, les "packet-length length bits" ont leurs valeurs listées
723
dans la table suivante :
725
00 - 1-octet champ packet-length
726
01 - 2-octets champ packet-length
727
10 - 4-octets champ packet-length
728
11 - pas de taille de paquet fournie, taille inconnue
730
Comme indiqué dans cette table, selon la taille du packet-length les
731
octets restants (1, 2, 4 ou 0) du champ de structure de paquets sont
732
un "champ packet-length". Ce champ est une valeur numérique à part entière.
733
La valeur du champ packet-length est définie par la valeur de la
734
totalité du champ numérique.
736
La valeur 11 est actuellement utilisée dans un cas : les données
737
compressées. C''est à dire qu'un bloc de données compressées
738
ressemble à : <A3 01 .. .. > où A3 est le binaire "10 1000 11" et
739
produit ici un paquet de taille non-définie. L'interprétation
740
correcte en est : "jusqu'à la fin de la structure englobante"
741
bien qu'en fait la structure englobante soit généralement
744
+ Ceci sera modifié dans une future version, où la signification de la
745
+ valeur 11 (voir ci-dessous) aura aussi sa place.
747
+ Une valeur de 11 pour d'autres paquets active un codage spécial
748
+ de la taille, où la taille du paquet suivant ne pourra pas être
749
+ déterminée avant l'écriture du paquet, en particulier ceci sera
750
+ utilisé si de grande quantités de données sont à traiter dans
753
+ Ceci fonctionne de la manière suivante : après le CTB (qui est un
754
+ champ de longueur de 11) un champ marqueur sera utilisé, il indiquera
755
+ alors la taille du bloc de données suivant. C'est un simple champ
756
+ de deux octets (MSB en premier) contenant la quantité de données qui
757
+ suivent le champ, sans inclure le champ de taille toutefois. Après
758
+ ce bloc de données un autre champ de taille suivra, qui donnera la taille
759
+ du bloc de données suivant. Une valeur de 0 indique une fin de paquet.
760
+ La taille maximale d'un bloc de données est limitée à 65534, ce qui
761
+ réserve la valeur 0xffff pour des extensions futures. Ces marqueurs de
762
+ taille devront être insérés dans le flux de données avant que les
763
+ données ne soient envoyées en sortie.
765
+ Ce champ de deux octets est largement suffisant, car l'application
766
+ doit placer en tampon cette quantité de données pour précéder le
767
+ marqueur de taille avant de produire une sortie. Les blocs de données
768
+ d'une taille supérieure à 32 Ko n'ont aucun sens. Notez que ceci pourra
769
+ également être utilisé pour les flux de données compressées, mais
770
+ nous devrons alors utiliser une autre version de paquet afin de dire à
771
+ l'application qu'elle ne peut assumer qu'il s'agit du dernier paquet.
774
Extensions GNU à l'algorithme S2K
775
=================================
777
Le S2K mode 101 est utilisé pour identifier ces extensions.
778
Après l'algorithme de hachage les trois octets "GNU" sont utilisés
779
pour indiquer clairement qu'il s'agit d'extensions GNU et les octets
780
qui suivent donnent le mode de protection GNU utilisé : 1000. Les
783
1001 - ne pas conserver du tout de partie secrète
787
Usage des fichiers gdbm pour les trousseaux de clefs
788
====================================================
790
La clef utilisé pour stocker le keyblock est son propre fingerprint,
791
les autres enregistrements sont utilisés pour les clefs secondaires.
792
Les fingerprint font toujours 20 octets où 16 bits de fingerprint
793
sont suivis par 0. Le premier octet de chaque clef indique une
794
information sur le type de clef :
796
1 = la clef est un fingerprint de 20 octets (16 octets fpr "paddés" de 0)
797
les données sont le keyblock
798
2 = la clef est un keyid complet de 8 octets
799
les données sont une liste de 20 octets fingerprints
800
3 = la clef est un keyid court de 4 octets
801
les données sont une liste de 20 octets fingerprints
802
4 = la clef est une adresse email
803
les données sont une liste de 20 octets fingerprints
805
Les données sont pre-appended (précédées) par un octet de type :
808
2 = liste de 20 octets fingerprints "paddés"
809
3 = liste de liste de fingerprints ("but how to we key them?")
816
Ce mode est utilisé pour réaliser des opérations multiples avec un
817
unique appel à gpg. C'est assez pratique lorsqu'il faut pouvoir vérifier
818
un grand nombre de signatures. Actuellement nous n'avons qu'un support
819
des signatures détachées. Ce mode est une astuce qui permet d'éviter
820
de faire fonctionner gpg n en daemon mode et d'utiliser les Unix Domain
821
Sockets pour lui faire passer les données. Il n'existe aucun moyen
822
pratique de portabilité de ce concept sous Windows, alors nous utilisons
823
des pipes simples pour faire fonctionner ce mode sous Windows. Comme nous
824
n'avons aucun moyen de signaler des EOF multiples dans un pipe nous
825
devons laisser le contrôle s'insérer dans le flux de données lui-même.
826
Nous réalisons alors une distinction entre les données du flux et un
827
état de contrôle. A son lancement, le système se trouve dans un état
828
de données mais n'acceptera aucune donnée. Il attend en fait une
829
transition vers un mode de contrôle qui s'obtient en envoyant un simple
830
caractère '@'. Une fois dans le mode de contrôle, des commandes sont
831
attendues et ces commandes sont à un octet après lequel le système
832
revient au mode de données (mais cela n'implique pas qu'il acceptera
833
des données immédiatement). La commande de contrôle la plus simple
834
est '@' qui permet d'insérer ce caractère dans le flux de données.
836
Voici le format que nous utilisons pour les signatures détachées :
838
"@<" - Début d'un nouveau flux
839
"@B" - La signature détachée suit.
840
Ceci émet le paquet de contrôle (1,'B')
842
"@t" - Le texte signé suit.
843
Ceci émet le paquet de contrôle (2, 'B')
845
"@." - Fin de l'opération. Le paquet de contrôle final force la
846
vérification de la signature.
854
Dans la version* 3 de version de paquet nous calculons les keyid de cette manière :
856
RSA : les 64 bits de poids faible de n
857
ELGAMAL : nous construisons un paquet de clef publique v3 (avec CTB 0x99)
858
et nous calculons une valeur hachée rmd160 à partir de ce paquet.
859
Il est utilisé comme fingerprint avec les 64 bits de poids faible
860
qui produisent le keyid.
862
* Les certificats de révocation ne comportent qu'un paquet de signature ;
863
"import" sait comment traiter ces paquets. L'idée derrière ce principe
864
est de conserver une petite taille de paquet.
868
Format des messages Keyserver
869
=============================
871
Le serveur de clef peut être contacté par un Unix Domain Socket ou via TCP.
873
Le format des requêtes est :
877
"Content-length:" digits
881
Où le command-tag est :
889
Le format de réponse utilisé est :
892
"GNUPG/1.0" status-code status-text
893
"Content-length:" digits
897
suivi par <digits> octets de données.
900
Les codes de statut utilisés sont :
902
o 1xx: Information: requête reçue, traitement en cours.
904
o 2xx: Succès - L'action a été reçue, comprise et acceptée.
906
o 4xx: Erreur client : la requête contient une erreur, mauvaise syntaxe
907
ou demande irréalisable.
909
o 5xx: Erreur serveur - Le serveur n'a pu traiter une demande
913
Documentation sur HKP (le protocol de serveurs de clefs http)
914
=============================================================
916
Un serveur HTTP minimal sur port 11371 reconnaît les requêtes GET
917
pour /pks/lookup. Les paramètres standard encodés URL de la requête
918
sont toujours ceux-ci : (toujours key=valeur)
920
- op=index (comme pgp -kv), op=vindex (comme pgp -kvv) and op=get (comme
923
- search=<stringlist>. Nous avons ici une liste de mots qui doivent
924
apparaître dans la clef. Ces mots sont séparés par des espaces,
925
points, @, etc. Les délimiteurs ne feront pas partie de la
926
recherche et l'ordre des mots n'a aucune importance (mais consultez
929
- exact=on. Ce switch permet d'indiquer au serveur hkp qu'il ne doit
930
rechercher que les correspondances exactes. Dans ce cas, les
931
délimiteurs et l'ordre des mots sera considéré.
933
- fingerprint=on. Renvoie également les fingerprint, lorsque utilisé
934
avec 'index' ou 'vindex'
936
Les serveurs de clefs savent aussi reconnaître le format http-POST vers /pks/add.
937
Vous utilisez ceci pour envoyer des clefs au serveur.
939
Le mieux pour produire une requête reste :
941
/pks/lookup/<gnupg_formatierte_user_id>?op=<operation>
943
Ceci peut être implémenté en utilisant le mécanisme de traduction Hurd.
944
Toutefois, nous pensons que les traitements du serveur de clef doivent
945
faire l'objet d'une refonte.
added
removed
doc/fr/DETAILS
