See ChangeLog: Wed Jul 14 19:42:08 CEST 1999 Werner Koch
[gnupg.git] / doc / DETAILS
1
2 Format of "---with-colons" listings
3 ===================================
4
5 sec::1024:17:6C7EE1B8621CC013:1998-07-07:0:::Werner Koch <werner.koch@guug.de>:
6 ssb::1536:20:5CE086B5B5A18FF4:1998-07-07:0:::
7
8  1. Field:  Type of record
9             pub = public key
10             sub = subkey (secondary key)
11             sec = secret key
12             ssb = secret subkey (secondary key)
13             uid = user id (only field 10 is used).
14             fpr = fingerprint: (fingerprint is in field 10)
15             pkd = public key data (special field format, see below)
16
17  2. Field:  A letter describing the calculated trust. This is a single
18             letter, but be prepared that additional information may follow
19             in some future versions. (not used for secret keys)
20                 o = Unknown (this key is new to the system)
21                 d = The key has been disabled
22                 r = The key has been revoked
23                 e = The key has expired
24                 q = Undefined (no value assigned)
25                 n = Don't trust this key at all
26                 m = There is marginal trust in this key
27                 f = The key is full trusted.
28                 u = The key is ultimately trusted; this is only used for
29                     keys for which the secret key is also available.
30  3. Field:  length of key in bits.
31  4. Field:  Algorithm:  1 = RSA
32                        16 = ElGamal (encrypt only)
33                        17 = DSA (sometimes called DH, sign only)
34                        20 = ElGamal (sign and encrypt)
35             (for other id's see include/cipher.h)
36  5. Field:  KeyID
37  6. Field:  Creation Date (in UTC)
38  7. Field:  Key expiration date or empty if none.
39  8. Field:  Local ID: record number of the dir record in the trustdb.
40             This value is only valid as long as the trustdb is not
41             deleted. You can use "#<local-id> as the user id when
42             specifying a key. This is needed because keyids may not be
43             unique - a program may use this number to access keys later.
44  9. Field:  Ownertrust (primary public keys only)
45             This is a single letter, but be prepared that additional
46             information may follow in some future versions.
47 10. Field:  User-ID.  The value is quoted like a C string to avoid
48             control characters (the colon is quoted "\x3a").
49
50 More fields may be added later.
51
52 If field 1 has the tag "pkd", a listing looks like this:
53 pkd:0:1024:B665B1435F4C2 .... FF26ABB:
54     !  !   !-- the value
55     !  !------ for infomation number of bits in the value
56     !--------- index (eg. DSA goes from 0 to 3: p,q,g,y)
57
58
59
60 Format of the "--status-fd" output
61 ==================================
62 Every line is prefixed with "[GNUPG:] ", followed by a keyword with
63 the type of the status line and a some arguments depending on the
64 type (maybe none); an application should always be prepared to see
65 more arguments in future versions.
66
67
68     GOODSIG     <long keyid>  <username>
69         The signature with the keyid is good.
70
71     BADSIG      <long keyid>  <username>
72         The signature with the keyid has not been verified okay.
73
74     ERRSIG  <long keyid>  <pubkey_algo> <hash_algo> \
75             <sig_class> <timestamp> <rc>
76         It was not possible to check the signature.  This may be
77         caused by a missing public key or an unsupported algorithm.
78         A RC of 4 indicates unknown algorithm, a 9 indicates a missing
79         public key. The other fields give more information about
80         this signature.  sig_class is a 2 byte hex-value.
81
82     VALIDSIG    <fingerprint in hex> <sig_creation_date> <sig-timestamp>
83         The signature with the keyid is good. This is the same
84         as GOODSIG but has the fingerprint as the argument. Both
85         status lines ere emitted for a good signature.
86         sig-timestamp is the signature creation time in seconds after
87         the epoch.
88
89     SIG_ID  <radix64_string>  <sig_creation_date>  <sig-timestamp>
90         This is emitted only for signatures of class 0 or 1 which
91         have been verified okay.  The string is a signature id
92         and may be used in applications to detect replay attacks
93         of signed messages.  Note that only DLP algorithms give
94         unique ids - others may yield duplicated ones when they
95         have been created in the same second.
96
97     ENC_TO  <long keyid>  <keytype>  <keylength>
98         The message is encrypted to this keyid.
99         keytype is the numerical value of the public key algorithm,
100         kenlength is the length of the key or 0 if it is not known
101         (which is currently always the case).
102
103     NODATA  <what>
104         No data has been found. Codes for what are:
105             1 - No armored data.
106             2 - Expected a packet but did not found one.
107             3 - Invalid packet found, this may indicate a non OpenPGP message.
108         You may see more than one of these status lines.
109
110     TRUST_UNDEFINED
111     TRUST_NEVER
112     TRUST_MARGINAL
113     TRUST_FULLY
114     TRUST_ULTIMATE
115         For good signatures one of these status lines are emitted
116         to indicate how trustworthy the signature is.  No arguments yet.
117
118     SIGEXPIRED
119         The signature key has expired.  No arguments yet.
120
121     KEYREVOKED
122         The used key has been revoked by his owner.  No arguments yet.
123
124     BADARMOR
125         The ASCII armor is corrupted.  No arguments yet.
126
127     RSA_OR_IDEA
128         The RSA or IDEA algorithms has been used in the data.  A
129         program might want to fallback to another program to handle
130         the data if GnuPG failed.
131
132     SHM_INFO
133     SHM_GET
134     SHM_GET_BOOL
135     SHM_GET_HIDDEN
136
137     NEED_PASSPHRASE <long keyid>  <keytype>  <keylength>
138         Issued whenever a passphrase is needed.
139         keytype is the numerical value of the public key algorithm
140         or 0 if this is not applicable, keylength is the length
141         of the key or 0 if it is not known (this is currently always the case).
142
143     NEED_PASSPHRASE_SYM <cipher_algo> <s2k_mode> <s2k_hash>
144         Issued whenever a passphrase for symmetric encryption is needed.
145
146     MISSING_PASSPHRASE
147
148     BAD_PASSPHRASE <long keyid>
149         The supplied passphrase was wrong
150
151     GOOD_PASSPHRASE
152         The supplied passphrase was good and the secret key material
153         is therefore usuable.
154
155     DECRYPTION_FAILED
156         The symmetric decryption failed - one reason could be a wrong
157         passphrase for a symmetrical encrypted message.
158
159     DECRYPTION_OKAY
160         The decryption process succeeded.  This means, that either the
161         correct secret key has been used or the correct passphrase
162         for a conventional encrypted message was given.  The program
163         itself may return an errorcode becuase it may not be possible to
164         verify a signature for some reasons.
165
166     NO_PUBKEY  <long keyid>
167     NO_SECKEY  <long keyid>
168         The key is not available
169
170     IMPORTED   <long keyid>  <username>
171         The keyid and name of the signature just imported
172
173     IMPORTED_RES <count> <no_user_id> <imported> <imported_rsa> <unchanged>
174         <n_uids> <n_subk> <n_sigs> <n_revoc> <sec_read> <sec_imported> <sec_dups>
175         Final statistics on import process (this is one long line)
176
177
178
179 Key generation
180 ==============
181     Key generation shows progress by printing different characters to
182     stderr:
183              "."  Last 10 Miller-Rabin tests failed
184              "+"  Miller-Rabin test succeeded
185              "!"  Reloading the pool with fresh prime numbers
186              "^"  Checking a new value for the generator
187              "<"  Size of one factor decreased
188              ">"  Size of one factor increased
189
190     The prime number for ElGamal is generated this way:
191
192     1) Make a prime number q of 160, 200, 240 bits (depending on the keysize)
193     2) Select the length of the other prime factors to be at least the size
194        of q and calculate the number of prime factors needed
195     3) Make a pool of prime numbers, each of the length determined in step 2
196     4) Get a new permutation out of the pool or continue with step 3
197        if we have tested all permutations.
198     5) Calculate a candidate prime p = 2 * q * p[1] * ... * p[n] + 1
199     6) Check that this prime has the correct length (this may change q if
200        it seems not to be possible to make a prime of the desired length)
201     7) Check whether this is a prime using trial divisions and the
202        Miller-Rabin test.
203     8) Continue with step 4 if we did not find a prime in step 7.
204     9) Find a generator for that prime.
205
206     This algorithm is based on Lim and Lee's suggestion from the
207     Crypto '97 proceedings p. 260.
208
209
210
211 Layout of the TrustDB
212 =====================
213 The TrustDB is built from fixed length records, where the first byte
214 describes the record type.  All numeric values are stored in network
215 byte order. The length of each record is 40 bytes. The first record of
216 the DB is always of type 1 and this is the only record of this type.
217
218   Record type 0:
219   --------------
220     Unused record, can be reused for any purpose.
221
222   Record type 1:
223   --------------
224     Version information for this TrustDB.  This is always the first
225     record of the DB and the only one with type 1.
226      1 byte value 1
227      3 bytes 'gpg'  magic value
228      1 byte Version of the TrustDB (2)
229      1 byte marginals needed
230      1 byte completes needed
231      1 byte max_cert_depth
232             The three items are used to check whether the cached
233             validity value from the dir record can be used.
234      1 u32  locked flags
235      1 u32  timestamp of trustdb creation
236      1 u32  timestamp of last modification which may affect the validity
237             of keys in the trustdb.  This value is checked against the
238             validity timestamp in the dir records.
239      1 u32  timestamp of last validation
240             (Used to keep track of the time, when this TrustDB was checked
241              against the pubring)
242      1 u32  record number of keyhashtable
243      1 u32  first free record
244      1 u32  record number of shadow directory hash table
245             It does not make sense to combine this table with the key table
246             because the keyid is not in every case a part of the fingerprint.
247      4 bytes reserved for version extension record
248
249
250   Record type 2: (directory record)
251   --------------
252     Informations about a public key certificate.
253     These are static values which are never changed without user interaction.
254
255      1 byte value 2
256      1 byte  reserved
257      1 u32   LID     .  (This is simply the record number of this record.)
258      1 u32   List of key-records (the first one is the primary key)
259      1 u32   List of uid-records
260      1 u32   cache record
261      1 byte  ownertrust
262      1 byte  dirflag
263      1 byte  maximum validity of all the user ids
264      1 u32   time of last validity check.
265      1 u32   Must check when this time has been reached.
266              (0 = no check required)
267
268
269   Record type 3:  (key record)
270   --------------
271     Informations about a primary public key.
272     (This is mainly used to lookup a trust record)
273
274      1 byte value 3
275      1 byte  reserved
276      1 u32   LID
277      1 u32   next   - next key record
278      7 bytes reserved
279      1 byte  keyflags
280      1 byte  pubkey algorithm
281      1 byte  length of the fingerprint (in bytes)
282      20 bytes fingerprint of the public key
283               (This is the value we use to identify a key)
284
285   Record type 4: (uid record)
286   --------------
287     Informations about a userid
288     We do not store the userid but the hash value of the userid because that
289     is sufficient.
290
291      1 byte value 4
292      1 byte reserved
293      1 u32  LID  points to the directory record.
294      1 u32  next   next userid
295      1 u32  pointer to preference record
296      1 u32  siglist  list of valid signatures
297      1 byte uidflags
298      1 byte validity of the key calculated over this user id
299      20 bytes ripemd160 hash of the username.
300
301
302   Record type 5: (pref record)
303   --------------
304     Informations about preferences
305
306      1 byte value 5
307      1 byte   reserved
308      1 u32  LID; points to the directory record (and not to the uid record!).
309             (or 0 for standard preference record)
310      1 u32  next
311      30 byte preference data
312
313   Record type 6  (sigrec)
314   -------------
315     Used to keep track of key signatures. Self-signatures are not
316     stored.  If a public key is not in the DB, the signature points to
317     a shadow dir record, which in turn has a list of records which
318     might be interested in this key (and the signature record here
319     is one).
320
321      1 byte   value 6
322      1 byte   reserved
323      1 u32    LID           points back to the dir record
324      1 u32    next   next sigrec of this uid or 0 to indicate the
325                      last sigrec.
326      6 times
327         1 u32  Local_id of signators dir or shadow dir record
328         1 byte Flag: Bit 0 = checked: Bit 1 is valid (we have a real
329                              directory record for this)
330                          1 = valid is set (but my be revoked)
331
332
333
334   Record type 8: (shadow directory record)
335   --------------
336     This record is used to reserved a LID for a public key.  We
337     need this to create the sig records of other keys, even if we
338     do not yet have the public key of the signature.
339     This record (the record number to be more precise) will be reused
340     as the dir record when we import the real public key.
341
342      1 byte value 8
343      1 byte  reserved
344      1 u32   LID      (This is simply the record number of this record.)
345      2 u32   keyid
346      1 byte  pubkey algorithm
347      3 byte reserved
348      1 u32   hintlist   A list of records which have references to
349                         this key.  This is used for fast access to
350                         signature records which are not yet checked.
351                         Note, that this is only a hint and the actual records
352                         may not anymore hold signature records for that key
353                         but that the code cares about this.
354     18 byte reserved
355
356
357
358   Record Type 10 (hash table)
359   --------------
360     Due to the fact that we use fingerprints to lookup keys, we can
361     implement quick access by some simple hash methods, and avoid
362     the overhead of gdbm.  A property of fingerprints is that they can be
363     used directly as hash values.  (They can be considered as strong
364     random numbers.)
365       What we use is a dynamic multilevel architecture, which combines
366     hashtables, record lists, and linked lists.
367
368     This record is a hashtable of 256 entries; a special property
369     is that all these records are stored consecutively to make one
370     big table. The hash value is simple the 1st, 2nd, ... byte of
371     the fingerprint (depending on the indirection level).
372
373     When used to hash shadow directory records, a different table is used
374     and indexed by the keyid.
375
376      1 byte value 10
377      1 byte reserved
378      n u32  recnum; n depends on the record length:
379             n = (reclen-2)/4  which yields 9 for the current record length
380             of 40 bytes.
381
382     the total number of such record which makes up the table is:
383          m = (256+n-1) / n
384     which is 29 for a record length of 40.
385
386     To look up a key we use the first byte of the fingerprint to get
387     the recnum from this hashtable and look up the addressed record:
388        - If this record is another hashtable, we use 2nd byte
389          to index this hash table and so on.
390        - if this record is a hashlist, we walk all entries
391          until we found one a matching one.
392        - if this record is a key record, we compare the
393          fingerprint and to decide whether it is the requested key;
394
395
396   Record type 11 (hash list)
397   --------------
398     see hash table for an explanation.
399     This is also used for other purposes.
400
401     1 byte value 11
402     1 byte reserved
403     1 u32  next          next hash list record
404     n times              n = (reclen-5)/5
405         1 u32  recnum
406
407     For the current record length of 40, n is 7
408
409
410
411   Record type 254 (free record)
412   ---------------
413     All these records form a linked list of unused records.
414      1 byte  value 254
415      1 byte  reserved (0)
416      1 u32   next_free
417
418
419
420 Packet Headers
421 ===============
422
423 GNUPG uses PGP 2 packet headers and also understands OpenPGP packet header.
424 There is one enhancement used with the old style packet headers:
425
426    CTB bits 10, the "packet-length length bits", have values listed in
427    the following table:
428
429       00 - 1-byte packet-length field
430       01 - 2-byte packet-length field
431       10 - 4-byte packet-length field
432       11 - no packet length supplied, unknown packet length
433
434    As indicated in this table, depending on the packet-length length
435    bits, the remaining 1, 2, 4, or 0 bytes of the packet structure field
436    are a "packet-length field".  The packet-length field is a whole
437    number field.  The value of the packet-length field is defined to be
438    the value of the whole number field.
439
440    A value of 11 is currently used in one place: on compressed data.
441    That is, a compressed data block currently looks like <A3 01 . .  .>,
442    where <A3>, binary 10 1000 11, is an indefinite-length packet. The
443    proper interpretation is "until the end of the enclosing structure",
444    although it should never appear outermost (where the enclosing
445    structure is a file).
446
447 +  This will be changed with another version, where the new meaning of
448 +  the value 11 (see below) will also take place.
449 +
450 +  A value of 11 for other packets enables a special length encoding,
451 +  which is used in case, where the length of the following packet can
452 +  not be determined prior to writing the packet; especially this will
453 +  be used if large amounts of data are processed in filter mode.
454 +
455 +  It works like this: After the CTB (with a length field of 11) a
456 +  marker field is used, which gives the length of the following datablock.
457 +  This is a simple 2 byte field (MSB first) containing the amount of data
458 +  following this field, not including this length field. After this datablock
459 +  another length field follows, which gives the size of the next datablock.
460 +  A value of 0 indicates the end of the packet. The maximum size of a
461 +  data block is limited to 65534, thereby reserving a value of 0xffff for
462 +  future extensions. These length markers must be inserted into the data
463 +  stream just before writing the data out.
464 +
465 +  This 2 byte filed is large enough, because the application must buffer
466 +  this amount of data to prepend the length marker before writing it out.
467 +  Data block sizes larger than about 32k doesn't make any sense. Note
468 +  that this may also be used for compressed data streams, but we must use
469 +  another packet version to tell the application that it can not assume,
470 +  that this is the last packet.
471
472
473 Usage of gdbm files for keyrings
474 ================================
475     The key to store the keyblock is it's fingerprint, other records
476     are used for secondary keys.  fingerprints are always 20 bytes
477     where 16 bit fingerprints are appended with zero.
478     The first byte of the key gives some information on the type of the
479     key.
480       1 = key is a 20 bit fingerprint (16 bytes fpr are padded with zeroes)
481           data is the keyblock
482       2 = key is the complete 8 byte keyid
483           data is a list of 20 byte fingerprints
484       3 = key is the short 4 byte keyid
485           data is a list of 20 byte fingerprints
486       4 = key is the email address
487           data is a list of 20 byte fingerprints
488
489     Data is prepended with a type byte:
490       1 = keyblock
491       2 = list of 20 byte padded fingerprints
492       3 = list of list fingerprints (but how to we key them?)
493
494
495
496
497 Other Notes
498 ===========
499     * For packet version 3 we calculate the keyids this way:
500         RSA     := low 64 bits of n
501         ELGAMAL := build a v3 pubkey packet (with CTB 0x99) and calculate
502                    a rmd160 hash value from it. This is used as the
503                    fingerprint and the low 64 bits are the keyid.
504
505     * Revocation certificates consist only of the signature packet;
506       "import" knows how to handle this.  The rationale behind it is
507       to keep them small.
508
509
510
511
512
513
514
515 Keyserver Message Format
516 =========================
517
518 The keyserver may be contacted by a Unix Domain socket or via TCP.
519
520 The format of a request is:
521
522 ====
523 command-tag
524 "Content-length:" digits
525 CRLF
526 =======
527
528 Where command-tag is
529
530 NOOP
531 GET <user-name>
532 PUT
533 DELETE <user-name>
534
535
536 The format of a response is:
537
538 ======
539 "GNUPG/1.0" status-code status-text
540 "Content-length:" digits
541 CRLF
542 ============
543 followed by <digits> bytes of data
544
545
546 Status codes are:
547
548      o  1xx: Informational - Request received, continuing process
549
550      o  2xx: Success - The action was successfully received, understood,
551         and accepted
552
553      o  4xx: Client Error - The request contains bad syntax or cannot be
554         fulfilled
555
556      o  5xx: Server Error - The server failed to fulfill an apparently
557         valid request
558
559
560
561 Documentation on HKP (the http keyserver protocol):
562
563 A minimalistic HTTP server on port 11371 recognizes a GET for /pks/lookup.
564 The standard http URL encoded query parameters are this (always key=value):
565
566 - op=index (like pgp -kv), op=vindex (like pgp -kvv) and op=get (like
567   pgp -kxa)
568
569 - search=<stringlist>. This is a list of words that must occur in the key.
570   The words are delimited with space, points, @ and so on. The delimiters
571   are not searched for and the order of the words doesn't matter (but see
572   next option).
573
574 - exact=on. This switch tells the hkp server to only report exact mathing
575   keys back. In this case the order and the "delimiters" are important.
576
577 - fingerprint=on. Also reports the fingerprints when used with 'index' or
578   'vindex'
579
580 New (already used by GnuPG):
581
582    /pks/lookup/<gnupg_formatierte_user_id>?op=<operation>
583
584 The keyserver also recognizes http-POSTs to /pks/add. Use this to upload
585 keys.