See ChangeLog: Wed Oct 4 13:16:18 CEST 2000 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 information 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         keylength 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         No passphrase was supplied.  An application which encounters this
148         message may want to stop parsing immediately because the next message
149         will probably be a BAD_PASSPHRASE.  However, if the application
150         is a wrapper around the key edit menu functionality it might not
151         make sense to stop parsing but simply ignoring the following
152         PAD_PASSPHRASE.
153
154     BAD_PASSPHRASE <long keyid>
155         The supplied passphrase was wrong or not given.  In the latter case
156         you may have seen a MISSING_PASSPHRASE.
157
158     GOOD_PASSPHRASE
159         The supplied passphrase was good and the secret key material
160         is therefore usable.
161
162     DECRYPTION_FAILED
163         The symmetric decryption failed - one reason could be a wrong
164         passphrase for a symmetrical encrypted message.
165
166     DECRYPTION_OKAY
167         The decryption process succeeded.  This means, that either the
168         correct secret key has been used or the correct passphrase
169         for a conventional encrypted message was given.  The program
170         itself may return an errorcode because it may not be possible to
171         verify a signature for some reasons.
172
173     NO_PUBKEY  <long keyid>
174     NO_SECKEY  <long keyid>
175         The key is not available
176
177     IMPORTED   <long keyid>  <username>
178         The keyid and name of the signature just imported
179
180     IMPORTED_RES <count> <no_user_id> <imported> <imported_rsa> <unchanged>
181         <n_uids> <n_subk> <n_sigs> <n_revoc> <sec_read> <sec_imported> <sec_dups>
182         Final statistics on import process (this is one long line)
183
184     FILE_START <what> <filename>
185         Start processing a file <filename>.  <what> indicates the performed
186         operation:
187             1 - verify
188
189     FILE_DONE
190         Marks the end of a file processing which has been started
191         by FILE_START.
192
193
194 Key generation
195 ==============
196     Key generation shows progress by printing different characters to
197     stderr:
198              "."  Last 10 Miller-Rabin tests failed
199              "+"  Miller-Rabin test succeeded
200              "!"  Reloading the pool with fresh prime numbers
201              "^"  Checking a new value for the generator
202              "<"  Size of one factor decreased
203              ">"  Size of one factor increased
204
205     The prime number for ElGamal is generated this way:
206
207     1) Make a prime number q of 160, 200, 240 bits (depending on the keysize)
208     2) Select the length of the other prime factors to be at least the size
209        of q and calculate the number of prime factors needed
210     3) Make a pool of prime numbers, each of the length determined in step 2
211     4) Get a new permutation out of the pool or continue with step 3
212        if we have tested all permutations.
213     5) Calculate a candidate prime p = 2 * q * p[1] * ... * p[n] + 1
214     6) Check that this prime has the correct length (this may change q if
215        it seems not to be possible to make a prime of the desired length)
216     7) Check whether this is a prime using trial divisions and the
217        Miller-Rabin test.
218     8) Continue with step 4 if we did not find a prime in step 7.
219     9) Find a generator for that prime.
220
221     This algorithm is based on Lim and Lee's suggestion from the
222     Crypto '97 proceedings p. 260.
223
224
225
226 Layout of the TrustDB
227 =====================
228 The TrustDB is built from fixed length records, where the first byte
229 describes the record type.  All numeric values are stored in network
230 byte order. The length of each record is 40 bytes. The first record of
231 the DB is always of type 1 and this is the only record of this type.
232
233   Record type 0:
234   --------------
235     Unused record, can be reused for any purpose.
236
237   Record type 1:
238   --------------
239     Version information for this TrustDB.  This is always the first
240     record of the DB and the only one with type 1.
241      1 byte value 1
242      3 bytes 'gpg'  magic value
243      1 byte Version of the TrustDB (2)
244      1 byte marginals needed
245      1 byte completes needed
246      1 byte max_cert_depth
247             The three items are used to check whether the cached
248             validity value from the dir record can be used.
249      1 u32  locked flags
250      1 u32  timestamp of trustdb creation
251      1 u32  timestamp of last modification which may affect the validity
252             of keys in the trustdb.  This value is checked against the
253             validity timestamp in the dir records.
254      1 u32  timestamp of last validation
255             (Used to keep track of the time, when this TrustDB was checked
256              against the pubring)
257      1 u32  record number of keyhashtable
258      1 u32  first free record
259      1 u32  record number of shadow directory hash table
260             It does not make sense to combine this table with the key table
261             because the keyid is not in every case a part of the fingerprint.
262      4 bytes reserved for version extension record
263
264
265   Record type 2: (directory record)
266   --------------
267     Informations about a public key certificate.
268     These are static values which are never changed without user interaction.
269
270      1 byte value 2
271      1 byte  reserved
272      1 u32   LID     .  (This is simply the record number of this record.)
273      1 u32   List of key-records (the first one is the primary key)
274      1 u32   List of uid-records
275      1 u32   cache record
276      1 byte  ownertrust
277      1 byte  dirflag
278      1 byte  maximum validity of all the user ids
279      1 u32   time of last validity check.
280      1 u32   Must check when this time has been reached.
281              (0 = no check required)
282
283
284   Record type 3:  (key record)
285   --------------
286     Informations about a primary public key.
287     (This is mainly used to lookup a trust record)
288
289      1 byte value 3
290      1 byte  reserved
291      1 u32   LID
292      1 u32   next   - next key record
293      7 bytes reserved
294      1 byte  keyflags
295      1 byte  pubkey algorithm
296      1 byte  length of the fingerprint (in bytes)
297      20 bytes fingerprint of the public key
298               (This is the value we use to identify a key)
299
300   Record type 4: (uid record)
301   --------------
302     Informations about a userid
303     We do not store the userid but the hash value of the userid because that
304     is sufficient.
305
306      1 byte value 4
307      1 byte reserved
308      1 u32  LID  points to the directory record.
309      1 u32  next   next userid
310      1 u32  pointer to preference record
311      1 u32  siglist  list of valid signatures
312      1 byte uidflags
313      1 byte validity of the key calculated over this user id
314      20 bytes ripemd160 hash of the username.
315
316
317   Record type 5: (pref record)
318   --------------
319     Informations about preferences
320
321      1 byte value 5
322      1 byte   reserved
323      1 u32  LID; points to the directory record (and not to the uid record!).
324             (or 0 for standard preference record)
325      1 u32  next
326      30 byte preference data
327
328   Record type 6  (sigrec)
329   -------------
330     Used to keep track of key signatures. Self-signatures are not
331     stored.  If a public key is not in the DB, the signature points to
332     a shadow dir record, which in turn has a list of records which
333     might be interested in this key (and the signature record here
334     is one).
335
336      1 byte   value 6
337      1 byte   reserved
338      1 u32    LID           points back to the dir record
339      1 u32    next   next sigrec of this uid or 0 to indicate the
340                      last sigrec.
341      6 times
342         1 u32  Local_id of signators dir or shadow dir record
343         1 byte Flag: Bit 0 = checked: Bit 1 is valid (we have a real
344                              directory record for this)
345                          1 = valid is set (but my be revoked)
346
347
348
349   Record type 8: (shadow directory record)
350   --------------
351     This record is used to reserved a LID for a public key.  We
352     need this to create the sig records of other keys, even if we
353     do not yet have the public key of the signature.
354     This record (the record number to be more precise) will be reused
355     as the dir record when we import the real public key.
356
357      1 byte value 8
358      1 byte  reserved
359      1 u32   LID      (This is simply the record number of this record.)
360      2 u32   keyid
361      1 byte  pubkey algorithm
362      3 byte reserved
363      1 u32   hintlist   A list of records which have references to
364                         this key.  This is used for fast access to
365                         signature records which are not yet checked.
366                         Note, that this is only a hint and the actual records
367                         may not anymore hold signature records for that key
368                         but that the code cares about this.
369     18 byte reserved
370
371
372
373   Record Type 10 (hash table)
374   --------------
375     Due to the fact that we use fingerprints to lookup keys, we can
376     implement quick access by some simple hash methods, and avoid
377     the overhead of gdbm.  A property of fingerprints is that they can be
378     used directly as hash values.  (They can be considered as strong
379     random numbers.)
380       What we use is a dynamic multilevel architecture, which combines
381     hashtables, record lists, and linked lists.
382
383     This record is a hashtable of 256 entries; a special property
384     is that all these records are stored consecutively to make one
385     big table. The hash value is simple the 1st, 2nd, ... byte of
386     the fingerprint (depending on the indirection level).
387
388     When used to hash shadow directory records, a different table is used
389     and indexed by the keyid.
390
391      1 byte value 10
392      1 byte reserved
393      n u32  recnum; n depends on the record length:
394             n = (reclen-2)/4  which yields 9 for the current record length
395             of 40 bytes.
396
397     the total number of such record which makes up the table is:
398          m = (256+n-1) / n
399     which is 29 for a record length of 40.
400
401     To look up a key we use the first byte of the fingerprint to get
402     the recnum from this hashtable and look up the addressed record:
403        - If this record is another hashtable, we use 2nd byte
404          to index this hash table and so on.
405        - if this record is a hashlist, we walk all entries
406          until we found one a matching one.
407        - if this record is a key record, we compare the
408          fingerprint and to decide whether it is the requested key;
409
410
411   Record type 11 (hash list)
412   --------------
413     see hash table for an explanation.
414     This is also used for other purposes.
415
416     1 byte value 11
417     1 byte reserved
418     1 u32  next          next hash list record
419     n times              n = (reclen-5)/5
420         1 u32  recnum
421
422     For the current record length of 40, n is 7
423
424
425
426   Record type 254 (free record)
427   ---------------
428     All these records form a linked list of unused records.
429      1 byte  value 254
430      1 byte  reserved (0)
431      1 u32   next_free
432
433
434
435 Packet Headers
436 ===============
437
438 GNUPG uses PGP 2 packet headers and also understands OpenPGP packet header.
439 There is one enhancement used with the old style packet headers:
440
441    CTB bits 10, the "packet-length length bits", have values listed in
442    the following table:
443
444       00 - 1-byte packet-length field
445       01 - 2-byte packet-length field
446       10 - 4-byte packet-length field
447       11 - no packet length supplied, unknown packet length
448
449    As indicated in this table, depending on the packet-length length
450    bits, the remaining 1, 2, 4, or 0 bytes of the packet structure field
451    are a "packet-length field".  The packet-length field is a whole
452    number field.  The value of the packet-length field is defined to be
453    the value of the whole number field.
454
455    A value of 11 is currently used in one place: on compressed data.
456    That is, a compressed data block currently looks like <A3 01 . .  .>,
457    where <A3>, binary 10 1000 11, is an indefinite-length packet. The
458    proper interpretation is "until the end of the enclosing structure",
459    although it should never appear outermost (where the enclosing
460    structure is a file).
461
462 +  This will be changed with another version, where the new meaning of
463 +  the value 11 (see below) will also take place.
464 +
465 +  A value of 11 for other packets enables a special length encoding,
466 +  which is used in case, where the length of the following packet can
467 +  not be determined prior to writing the packet; especially this will
468 +  be used if large amounts of data are processed in filter mode.
469 +
470 +  It works like this: After the CTB (with a length field of 11) a
471 +  marker field is used, which gives the length of the following datablock.
472 +  This is a simple 2 byte field (MSB first) containing the amount of data
473 +  following this field, not including this length field. After this datablock
474 +  another length field follows, which gives the size of the next datablock.
475 +  A value of 0 indicates the end of the packet. The maximum size of a
476 +  data block is limited to 65534, thereby reserving a value of 0xffff for
477 +  future extensions. These length markers must be inserted into the data
478 +  stream just before writing the data out.
479 +
480 +  This 2 byte filed is large enough, because the application must buffer
481 +  this amount of data to prepend the length marker before writing it out.
482 +  Data block sizes larger than about 32k doesn't make any sense. Note
483 +  that this may also be used for compressed data streams, but we must use
484 +  another packet version to tell the application that it can not assume,
485 +  that this is the last packet.
486
487
488 Usage of gdbm files for keyrings
489 ================================
490     The key to store the keyblock is it's fingerprint, other records
491     are used for secondary keys.  fingerprints are always 20 bytes
492     where 16 bit fingerprints are appended with zero.
493     The first byte of the key gives some information on the type of the
494     key.
495       1 = key is a 20 bit fingerprint (16 bytes fpr are padded with zeroes)
496           data is the keyblock
497       2 = key is the complete 8 byte keyid
498           data is a list of 20 byte fingerprints
499       3 = key is the short 4 byte keyid
500           data is a list of 20 byte fingerprints
501       4 = key is the email address
502           data is a list of 20 byte fingerprints
503
504     Data is prepended with a type byte:
505       1 = keyblock
506       2 = list of 20 byte padded fingerprints
507       3 = list of list fingerprints (but how to we key them?)
508
509
510
511
512 Other Notes
513 ===========
514     * For packet version 3 we calculate the keyids this way:
515         RSA     := low 64 bits of n
516         ELGAMAL := build a v3 pubkey packet (with CTB 0x99) and calculate
517                    a rmd160 hash value from it. This is used as the
518                    fingerprint and the low 64 bits are the keyid.
519
520     * Revocation certificates consist only of the signature packet;
521       "import" knows how to handle this.  The rationale behind it is
522       to keep them small.
523
524
525
526
527
528
529
530 Keyserver Message Format
531 =========================
532
533 The keyserver may be contacted by a Unix Domain socket or via TCP.
534
535 The format of a request is:
536
537 ====
538 command-tag
539 "Content-length:" digits
540 CRLF
541 =======
542
543 Where command-tag is
544
545 NOOP
546 GET <user-name>
547 PUT
548 DELETE <user-name>
549
550
551 The format of a response is:
552
553 ======
554 "GNUPG/1.0" status-code status-text
555 "Content-length:" digits
556 CRLF
557 ============
558 followed by <digits> bytes of data
559
560
561 Status codes are:
562
563      o  1xx: Informational - Request received, continuing process
564
565      o  2xx: Success - The action was successfully received, understood,
566         and accepted
567
568      o  4xx: Client Error - The request contains bad syntax or cannot be
569         fulfilled
570
571      o  5xx: Server Error - The server failed to fulfill an apparently
572         valid request
573
574
575
576 Documentation on HKP (the http keyserver protocol):
577
578 A minimalistic HTTP server on port 11371 recognizes a GET for /pks/lookup.
579 The standard http URL encoded query parameters are this (always key=value):
580
581 - op=index (like pgp -kv), op=vindex (like pgp -kvv) and op=get (like
582   pgp -kxa)
583
584 - search=<stringlist>. This is a list of words that must occur in the key.
585   The words are delimited with space, points, @ and so on. The delimiters
586   are not searched for and the order of the words doesn't matter (but see
587   next option).
588
589 - exact=on. This switch tells the hkp server to only report exact matching
590   keys back. In this case the order and the "delimiters" are important.
591
592 - fingerprint=on. Also reports the fingerprints when used with 'index' or
593   'vindex'
594
595 The keyserver also recognizes http-POSTs to /pks/add. Use this to upload
596 keys.
597
598
599 A better way to to this would be a request like:
600
601    /pks/lookup/<gnupg_formatierte_user_id>?op=<operation>
602
603 this can be implemented using Hurd's translator mechanism.
604 However, I think the whole key server stuff has to be re-thought;
605 I have some ideas and probably create a white paper.
606