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