1997-11-24 23:24:04 +01:00
|
|
|
|
|
1998-10-12 22:16:38 +02:00
|
|
|
|
Format of "---with-colons" listings
|
|
|
|
|
===================================
|
|
|
|
|
|
|
|
|
|
sec::1024:17:6C7EE1B8621CC013:1998-07-07:0:::Werner Koch <werner.koch@guug.de>:
|
|
|
|
|
ssb::1536:20:5CE086B5B5A18FF4:1998-07-07:0:::
|
|
|
|
|
|
|
|
|
|
1. Field: Type of record
|
|
|
|
|
pub = public key
|
|
|
|
|
sub = subkey (secondary key)
|
|
|
|
|
sec = secret key
|
|
|
|
|
ssb = secret subkey (secondary key)
|
|
|
|
|
uid = user id (only field 10 is used).
|
|
|
|
|
fpr = fingerprint: (fingerprint is in field 10)
|
|
|
|
|
|
|
|
|
|
2. Field: A letter describing the calculated trust, see doc/FAQ
|
1998-11-13 20:41:41 +01:00
|
|
|
|
This is a single letter, but be prepared that additional
|
|
|
|
|
information may follow in some future versions.
|
1998-10-12 22:16:38 +02:00
|
|
|
|
(not used for secret keys)
|
|
|
|
|
3. Field: length of key in bits.
|
|
|
|
|
4. Field: Algorithm: 1 = RSA
|
|
|
|
|
16 = ElGamal (encrypt only)
|
|
|
|
|
17 = DSA (sometimes called DH, sign only)
|
|
|
|
|
20 = ElGamal (sign and encrypt)
|
|
|
|
|
5. Field: KeyID
|
|
|
|
|
6. Field: Creation Date (in UTC)
|
1998-10-16 18:00:17 +02:00
|
|
|
|
7. Field: Key expiration date or empty if none.
|
1998-10-12 22:16:38 +02:00
|
|
|
|
8. Field: Local ID: record number of the dir record in the trustdb
|
|
|
|
|
this value is only valid as long as the trustdb is not
|
|
|
|
|
deleted. May be later used to lookup the key: You will be
|
|
|
|
|
able to use "#<local-id> as the user id. This is needed
|
|
|
|
|
because keyids may not be unique - a program may use this
|
|
|
|
|
number to access keys later.
|
|
|
|
|
9. Field: Ownertrust (primary public keys only)
|
1998-11-13 20:41:41 +01:00
|
|
|
|
This is a single letter, but be prepared that additional
|
|
|
|
|
information may follow in some future versions.
|
1998-10-12 22:16:38 +02:00
|
|
|
|
10. Field: User-ID. The value is quoted like a C string to avoid
|
|
|
|
|
control characters (the colon is quoted "\x3a").
|
|
|
|
|
|
|
|
|
|
More fields may be added later.
|
|
|
|
|
|
|
|
|
|
|
1999-01-09 16:06:59 +01:00
|
|
|
|
Format of the "--status-fd" output
|
|
|
|
|
==================================
|
|
|
|
|
Every line is prefixed with "[GNUPG:] ", followed by a keyword with
|
|
|
|
|
the type of the status line and a some arguments depending on the
|
|
|
|
|
type (maybe none); an application should always be prepared to see
|
1999-01-12 11:20:24 +01:00
|
|
|
|
more arguments in future versions.
|
1999-01-09 16:06:59 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
GOODSIG <long keyid> <username>
|
|
|
|
|
The signature with the keyid is good.
|
|
|
|
|
|
|
|
|
|
BADSIG <long keyid> <username>
|
|
|
|
|
The signature with the keyid has not been verified okay.
|
|
|
|
|
|
|
|
|
|
ERRSIG
|
|
|
|
|
It was not possible to check the signature. This may be
|
|
|
|
|
caused by a missing public key or an unsupported algorithm.
|
1999-01-12 11:20:24 +01:00
|
|
|
|
No argument yet.
|
1999-01-09 16:06:59 +01:00
|
|
|
|
|
|
|
|
|
VALIDSIG <fingerprint in hex>
|
|
|
|
|
The signature with the keyid is good. This is the same
|
|
|
|
|
as GOODSIG but has the fingerprint as the argument. Both
|
1999-01-12 11:20:24 +01:00
|
|
|
|
status lines ere emitted for a good signature.
|
1999-01-09 16:06:59 +01:00
|
|
|
|
|
|
|
|
|
TRUST_UNDEFINED
|
|
|
|
|
TRUST_NEVER
|
|
|
|
|
TRUST_MARGINAL
|
|
|
|
|
TRUST_FULLY
|
|
|
|
|
TRUST_ULTIMATE
|
|
|
|
|
For good signatures one of these status lines are emitted
|
1999-01-12 11:20:24 +01:00
|
|
|
|
to indicate how trustworthy the signature is. No arguments yet.
|
1999-01-09 16:06:59 +01:00
|
|
|
|
|
|
|
|
|
SIGEXPIRED
|
|
|
|
|
The signature key has expired. No arguments yet.
|
|
|
|
|
|
|
|
|
|
KEYREVOKED
|
|
|
|
|
The used key has been revoked by his owner. No arguments yet.
|
|
|
|
|
|
|
|
|
|
BADARMOR
|
1999-02-10 17:22:40 +01:00
|
|
|
|
The ASCII armor is corrupted. No arguments yet.
|
1999-01-09 16:06:59 +01:00
|
|
|
|
|
|
|
|
|
RSA_OR_IDEA
|
|
|
|
|
The RSA or IDEA algorithms has been used in the data. A
|
|
|
|
|
program might want to fallback to another program to handle
|
|
|
|
|
the data if GnuPG failed.
|
|
|
|
|
|
|
|
|
|
SHM_INFO
|
|
|
|
|
SHM_GET
|
|
|
|
|
SHM_GET_BOOL
|
|
|
|
|
SHM_GET_HIDDEN
|
|
|
|
|
NEED_PASSPHRASE
|
|
|
|
|
[Needs documentation]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1998-10-12 22:16:38 +02:00
|
|
|
|
Key generation
|
|
|
|
|
==============
|
1998-05-29 13:53:54 +02:00
|
|
|
|
Key generation shows progress by printing different characters to
|
|
|
|
|
stderr:
|
|
|
|
|
"." Last 10 Miller-Rabin tests failed
|
|
|
|
|
"+" Miller-Rabin test succeeded
|
|
|
|
|
"!" Reloading the pool with fresh prime numbers
|
|
|
|
|
"^" Checking a new value for the generator
|
|
|
|
|
"<" Size of one factor decreased
|
|
|
|
|
">" Size of one factor increased
|
|
|
|
|
|
|
|
|
|
The prime number for ElGamal is generated this way:
|
|
|
|
|
|
|
|
|
|
1) Make a prime number q of 160, 200, 240 bits (depending on the keysize)
|
|
|
|
|
2) Select the length of the other prime factors to be at least the size
|
|
|
|
|
of q and calculate the number of prime factors needed
|
|
|
|
|
3) Make a pool of prime numbers, each of the length determined in step 2
|
|
|
|
|
4) Get a new permutation out of the pool or continue with step 3
|
|
|
|
|
if we have tested all permutations.
|
|
|
|
|
5) Calculate a candidate prime p = 2 * q * p[1] * ... * p[n] + 1
|
|
|
|
|
6) Check that this prime has the correct length (this may change q if
|
|
|
|
|
it seems not to be possible to make a prime of the desired length)
|
|
|
|
|
7) Check whether this is a prime using trial divisions and the
|
|
|
|
|
Miller-Rabin test.
|
|
|
|
|
8) Continue with step 4 if we did not find a prime in step 7.
|
|
|
|
|
9) Find a generator for that prime.
|
|
|
|
|
|
|
|
|
|
|
1998-01-12 11:18:17 +01:00
|
|
|
|
|
|
|
|
|
Layout of the TrustDB
|
|
|
|
|
=====================
|
1998-04-14 19:51:16 +02:00
|
|
|
|
The TrustDB is built from fixed length records, where the first byte
|
1998-01-12 11:18:17 +01:00
|
|
|
|
describes the record type. All numeric values are stored in network
|
|
|
|
|
byte order. The length of each record is 40 bytes. The first record of
|
1998-09-18 17:24:53 +02:00
|
|
|
|
the DB is always of type 2 and this is the only record of this type.
|
1998-01-12 11:18:17 +01:00
|
|
|
|
|
|
|
|
|
Record type 0:
|
|
|
|
|
--------------
|
|
|
|
|
Unused record, can be reused for any purpose.
|
|
|
|
|
|
|
|
|
|
Record type 1:
|
|
|
|
|
--------------
|
|
|
|
|
Version information for this TrustDB. This is always the first
|
1998-04-14 19:51:16 +02:00
|
|
|
|
record of the DB and the only one with type 1.
|
1998-12-08 13:20:53 +01:00
|
|
|
|
1 byte value 1
|
1998-02-24 19:50:46 +01:00
|
|
|
|
3 bytes 'gpg' magic value
|
1998-12-08 13:20:53 +01:00
|
|
|
|
1 byte Version of the TrustDB (2)
|
1998-11-13 20:41:41 +01:00
|
|
|
|
1 byte marginals needed
|
|
|
|
|
1 byte completes needed
|
|
|
|
|
1 byte max_cert_depth
|
|
|
|
|
The three items are used to check whether the cached
|
|
|
|
|
validity value from the dir record can be used.
|
1998-07-29 21:35:05 +02:00
|
|
|
|
1 u32 locked flags
|
1998-01-12 11:18:17 +01:00
|
|
|
|
1 u32 timestamp of trustdb creation
|
|
|
|
|
1 u32 timestamp of last modification
|
|
|
|
|
1 u32 timestamp of last validation
|
|
|
|
|
(Used to keep track of the time, when this TrustDB was checked
|
|
|
|
|
against the pubring)
|
1998-07-29 21:35:05 +02:00
|
|
|
|
1 u32 record number of keyhashtable
|
1998-10-07 15:30:43 +02:00
|
|
|
|
1 u32 first free record
|
1998-10-12 22:16:38 +02:00
|
|
|
|
1 u32 record number of shadow directory hash table
|
|
|
|
|
It does not make sense to combine this table with the key table
|
1999-01-12 11:20:24 +01:00
|
|
|
|
because the keyid is not in every case a part of the fingerprint.
|
1998-10-12 22:16:38 +02:00
|
|
|
|
4 bytes reserved for version extension record
|
1998-01-12 11:18:17 +01:00
|
|
|
|
|
1998-01-31 22:21:22 +01:00
|
|
|
|
|
|
|
|
|
Record type 2: (directory record)
|
1998-01-12 11:18:17 +01:00
|
|
|
|
--------------
|
|
|
|
|
Informations about a public key certificate.
|
1998-01-13 20:04:23 +01:00
|
|
|
|
These are static values which are never changed without user interaction.
|
1998-01-12 11:18:17 +01:00
|
|
|
|
|
|
|
|
|
1 byte value 2
|
1998-07-14 19:10:28 +02:00
|
|
|
|
1 byte reserved
|
|
|
|
|
1 u32 LID . (This is simply the record number of this record.)
|
|
|
|
|
1 u32 List of key-records (the first one is the primary key)
|
|
|
|
|
1 u32 List of uid-records
|
1998-01-31 22:21:22 +01:00
|
|
|
|
1 u32 cache record
|
1998-07-14 19:10:28 +02:00
|
|
|
|
1 byte ownertrust
|
1998-11-13 20:41:41 +01:00
|
|
|
|
1 byte dirflag
|
1999-02-10 17:22:40 +01:00
|
|
|
|
1 byte validity of the key calucalted over all user ids
|
1998-11-13 20:41:41 +01:00
|
|
|
|
19 byte reserved
|
1998-01-31 22:21:22 +01:00
|
|
|
|
|
|
|
|
|
|
1998-07-14 19:10:28 +02:00
|
|
|
|
Record type 3: (key record)
|
1998-01-31 22:21:22 +01:00
|
|
|
|
--------------
|
1998-07-09 15:37:17 +02:00
|
|
|
|
Informations about a primary public key.
|
1998-07-14 19:10:28 +02:00
|
|
|
|
(This is mainly used to lookup a trust record)
|
1998-01-31 22:21:22 +01:00
|
|
|
|
|
|
|
|
|
1 byte value 3
|
1998-07-14 19:10:28 +02:00
|
|
|
|
1 byte reserved
|
|
|
|
|
1 u32 LID
|
|
|
|
|
1 u32 next - next key record
|
1998-07-21 14:53:38 +02:00
|
|
|
|
7 bytes reserved
|
|
|
|
|
1 byte keyflags
|
1998-07-14 19:10:28 +02:00
|
|
|
|
1 byte pubkey algorithm
|
|
|
|
|
1 byte length of the fingerprint (in bytes)
|
1998-01-12 11:18:17 +01:00
|
|
|
|
20 bytes fingerprint of the public key
|
1998-07-14 19:10:28 +02:00
|
|
|
|
(This is the value we use to identify a key)
|
|
|
|
|
|
|
|
|
|
Record type 4: (uid record)
|
|
|
|
|
--------------
|
|
|
|
|
Informations about a userid
|
|
|
|
|
We do not store the userid but the hash value of the userid because that
|
|
|
|
|
is sufficient.
|
|
|
|
|
|
|
|
|
|
1 byte value 4
|
|
|
|
|
1 byte reserved
|
|
|
|
|
1 u32 LID points to the directory record.
|
|
|
|
|
1 u32 next next userid
|
|
|
|
|
1 u32 pointer to preference record
|
|
|
|
|
1 u32 siglist list of valid signatures
|
1998-07-21 14:53:38 +02:00
|
|
|
|
1 byte uidflags
|
1999-02-10 17:22:40 +01:00
|
|
|
|
1 byte validity of the key calculated over this user id
|
1998-07-14 19:10:28 +02:00
|
|
|
|
20 bytes ripemd160 hash of the username.
|
1998-01-31 22:21:22 +01:00
|
|
|
|
|
|
|
|
|
|
1998-07-14 19:10:28 +02:00
|
|
|
|
Record type 5: (pref record)
|
|
|
|
|
--------------
|
|
|
|
|
Informations about preferences
|
|
|
|
|
|
|
|
|
|
1 byte value 5
|
|
|
|
|
1 byte reserved
|
|
|
|
|
1 u32 LID; points to the directory record (and not to the uid record!).
|
|
|
|
|
(or 0 for standard preference record)
|
|
|
|
|
1 u32 next
|
1998-08-05 18:51:59 +02:00
|
|
|
|
30 byte preference data
|
1998-07-14 19:10:28 +02:00
|
|
|
|
|
|
|
|
|
Record type 6 (sigrec)
|
|
|
|
|
-------------
|
1998-10-12 22:16:38 +02:00
|
|
|
|
Used to keep track of key signatures. Self-signatures are not
|
|
|
|
|
stored. If a public key is not in the DB, the signature points to
|
|
|
|
|
a shadow dir record, which in turn has a list of records which
|
|
|
|
|
might be interested in this key (and the signature record here
|
|
|
|
|
is one).
|
1998-07-14 19:10:28 +02:00
|
|
|
|
|
|
|
|
|
1 byte value 6
|
|
|
|
|
1 byte reserved
|
|
|
|
|
1 u32 LID points back to the dir record
|
1998-10-12 22:16:38 +02:00
|
|
|
|
1 u32 next next sigrec of this uid or 0 to indicate the
|
1998-07-14 19:10:28 +02:00
|
|
|
|
last sigrec.
|
|
|
|
|
6 times
|
1998-10-12 22:16:38 +02:00
|
|
|
|
1 u32 Local_id of signators dir or shadow dir record
|
|
|
|
|
1 byte Flag: Bit 0 = checked: Bit 1 is valid (we have a real
|
|
|
|
|
directory record for this)
|
|
|
|
|
1 = valid is set (but my be revoked)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Record type 8: (shadow directory record)
|
|
|
|
|
--------------
|
|
|
|
|
This record is used to reserved a LID for a public key. We
|
|
|
|
|
need this to create the sig records of other keys, even if we
|
|
|
|
|
do not yet have the public key of the signature.
|
|
|
|
|
This record (the record number to be more precise) will be reused
|
|
|
|
|
as the dir record when we import the real public key.
|
|
|
|
|
|
|
|
|
|
1 byte value 8
|
|
|
|
|
1 byte reserved
|
|
|
|
|
1 u32 LID (This is simply the record number of this record.)
|
|
|
|
|
2 u32 keyid
|
|
|
|
|
1 byte pubkey algorithm
|
|
|
|
|
3 byte reserved
|
|
|
|
|
1 u32 hintlist A list of records which have references to
|
|
|
|
|
this key. This is used for fast access to
|
|
|
|
|
signature records which are not yet checked.
|
|
|
|
|
Note, that this is only a hint and the actual records
|
|
|
|
|
may not anymore hold signature records for that key
|
|
|
|
|
but that the code cares about this.
|
|
|
|
|
18 byte reserved
|
1998-07-14 19:10:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Record type 9: (cache record)
|
1998-01-12 11:18:17 +01:00
|
|
|
|
--------------
|
|
|
|
|
Used to bind the trustDB to the concrete instance of keyblock in
|
1998-04-14 19:51:16 +02:00
|
|
|
|
a pubring. This is used to cache information.
|
1998-01-12 11:18:17 +01:00
|
|
|
|
|
1998-07-14 19:10:28 +02:00
|
|
|
|
1 byte value 9
|
1998-01-12 11:18:17 +01:00
|
|
|
|
1 byte reserved
|
|
|
|
|
1 u32 Local-Id.
|
1998-01-14 13:34:05 +01:00
|
|
|
|
8 bytes keyid of the primary key (needed?)
|
1998-01-12 11:18:17 +01:00
|
|
|
|
1 byte cache-is-valid the following stuff is only
|
|
|
|
|
valid if this is set.
|
|
|
|
|
1 byte reserved
|
|
|
|
|
20 bytes rmd160 hash value over the complete keyblock
|
|
|
|
|
This is used to detect any changes of the keyblock with all
|
|
|
|
|
CTBs and lengths headers. Calculation is easy if the keyblock
|
1999-01-12 11:20:24 +01:00
|
|
|
|
is obtained from a keyserver: simply create the hash from all
|
1998-01-12 11:18:17 +01:00
|
|
|
|
received data bytes.
|
|
|
|
|
|
|
|
|
|
1 byte number of untrusted signatures.
|
|
|
|
|
1 byte number of marginal trusted signatures.
|
|
|
|
|
1 byte number of fully trusted signatures.
|
|
|
|
|
(255 is stored for all values greater than 254)
|
|
|
|
|
1 byte Trustlevel
|
|
|
|
|
0 = undefined (not calculated)
|
|
|
|
|
1 = unknown
|
|
|
|
|
2 = not trusted
|
|
|
|
|
3 = marginally trusted
|
|
|
|
|
4 = fully trusted
|
|
|
|
|
5 = ultimately trusted (have secret key too).
|
|
|
|
|
|
1998-01-14 13:34:05 +01:00
|
|
|
|
|
1998-07-14 19:10:28 +02:00
|
|
|
|
Record Type 10 (hash table)
|
|
|
|
|
--------------
|
1998-07-29 21:35:05 +02:00
|
|
|
|
Due to the fact that we use fingerprints to lookup keys, we can
|
1998-01-31 22:24:36 +01:00
|
|
|
|
implement quick access by some simple hash methods, and avoid
|
1998-07-29 21:35:05 +02:00
|
|
|
|
the overhead of gdbm. A property of fingerprints is that they can be
|
1998-04-14 19:51:16 +02:00
|
|
|
|
used directly as hash values. (They can be considered as strong
|
|
|
|
|
random numbers.)
|
1998-01-31 22:24:36 +01:00
|
|
|
|
What we use is a dynamic multilevel architecture, which combines
|
1998-07-06 12:23:57 +02:00
|
|
|
|
hashtables, record lists, and linked lists.
|
1998-01-31 22:24:36 +01:00
|
|
|
|
|
|
|
|
|
This record is a hashtable of 256 entries; a special property
|
1998-04-14 19:51:16 +02:00
|
|
|
|
is that all these records are stored consecutively to make one
|
1998-01-31 22:24:36 +01:00
|
|
|
|
big table. The hash value is simple the 1st, 2nd, ... byte of
|
1998-07-29 21:35:05 +02:00
|
|
|
|
the fingerprint (depending on the indirection level).
|
1998-01-31 22:24:36 +01:00
|
|
|
|
|
1998-10-12 22:16:38 +02:00
|
|
|
|
When used to hash shadow directory records, a different table is used
|
|
|
|
|
and indexed by the keyid.
|
|
|
|
|
|
1998-07-14 19:10:28 +02:00
|
|
|
|
1 byte value 10
|
1998-01-31 22:24:36 +01:00
|
|
|
|
1 byte reserved
|
1998-07-29 21:35:05 +02:00
|
|
|
|
n u32 recnum; n depends on the record length:
|
1998-01-31 22:24:36 +01:00
|
|
|
|
n = (reclen-2)/4 which yields 9 for the current record length
|
|
|
|
|
of 40 bytes.
|
|
|
|
|
|
1999-01-12 11:20:24 +01:00
|
|
|
|
the total number of such record which makes up the table is:
|
1998-01-31 22:24:36 +01:00
|
|
|
|
m = (256+n-1) / n
|
|
|
|
|
which is 29 for a record length of 40.
|
|
|
|
|
|
1998-07-29 21:35:05 +02:00
|
|
|
|
To look up a key we use the first byte of the fingerprint to get
|
|
|
|
|
the recnum from this hashtable and look up the addressed record:
|
|
|
|
|
- If this record is another hashtable, we use 2nd byte
|
1999-01-12 11:20:24 +01:00
|
|
|
|
to index this hash table and so on.
|
1998-07-29 21:35:05 +02:00
|
|
|
|
- if this record is a hashlist, we walk all entries
|
|
|
|
|
until we found one a matching one.
|
|
|
|
|
- if this record is a key record, we compare the
|
|
|
|
|
fingerprint and to decide whether it is the requested key;
|
|
|
|
|
|
1998-01-31 22:24:36 +01:00
|
|
|
|
|
1998-07-14 19:10:28 +02:00
|
|
|
|
Record type 11 (hash list)
|
|
|
|
|
--------------
|
1998-01-31 22:24:36 +01:00
|
|
|
|
see hash table for an explanation.
|
1998-10-12 22:16:38 +02:00
|
|
|
|
This is also used for other purposes.
|
1998-01-31 22:24:36 +01:00
|
|
|
|
|
1998-07-14 19:10:28 +02:00
|
|
|
|
1 byte value 11
|
1998-01-31 22:24:36 +01:00
|
|
|
|
1 byte reserved
|
1998-07-14 19:10:28 +02:00
|
|
|
|
1 u32 next next hash list record
|
1998-07-29 21:35:05 +02:00
|
|
|
|
n times n = (reclen-5)/5
|
1998-01-31 22:24:36 +01:00
|
|
|
|
1 u32 recnum
|
|
|
|
|
|
1998-07-29 21:35:05 +02:00
|
|
|
|
For the current record length of 40, n is 7
|
1998-01-31 22:24:36 +01:00
|
|
|
|
|
1998-10-12 22:16:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Record type 254 (free record)
|
|
|
|
|
---------------
|
|
|
|
|
All these records form a linked list of unused records.
|
1998-10-07 15:30:43 +02:00
|
|
|
|
1 byte value 254
|
|
|
|
|
1 byte reserved (0)
|
|
|
|
|
1 u32 next_free
|
|
|
|
|
|
1998-02-18 14:58:46 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Packet Headers
|
|
|
|
|
===============
|
|
|
|
|
|
1998-04-14 19:51:16 +02:00
|
|
|
|
GNUPG uses PGP 2 packet headers and also understands OpenPGP packet header.
|
|
|
|
|
There is one enhancement used with the old style packet headers:
|
1998-02-18 14:58:46 +01:00
|
|
|
|
|
|
|
|
|
CTB bits 10, the "packet-length length bits", have values listed in
|
|
|
|
|
the following table:
|
|
|
|
|
|
|
|
|
|
00 - 1-byte packet-length field
|
|
|
|
|
01 - 2-byte packet-length field
|
|
|
|
|
10 - 4-byte packet-length field
|
|
|
|
|
11 - no packet length supplied, unknown packet length
|
|
|
|
|
|
|
|
|
|
As indicated in this table, depending on the packet-length length
|
|
|
|
|
bits, the remaining 1, 2, 4, or 0 bytes of the packet structure field
|
|
|
|
|
are a "packet-length field". The packet-length field is a whole
|
|
|
|
|
number field. The value of the packet-length field is defined to be
|
|
|
|
|
the value of the whole number field.
|
|
|
|
|
|
|
|
|
|
A value of 11 is currently used in one place: on compressed data.
|
|
|
|
|
That is, a compressed data block currently looks like <A3 01 . . .>,
|
|
|
|
|
where <A3>, binary 10 1000 11, is an indefinite-length packet. The
|
|
|
|
|
proper interpretation is "until the end of the enclosing structure",
|
|
|
|
|
although it should never appear outermost (where the enclosing
|
|
|
|
|
structure is a file).
|
|
|
|
|
|
|
|
|
|
+ This will be changed with another version, where the new meaning of
|
|
|
|
|
+ the value 11 (see below) will also take place.
|
|
|
|
|
+
|
|
|
|
|
+ A value of 11 for other packets enables a special length encoding,
|
|
|
|
|
+ which is used in case, where the length of the following packet can
|
|
|
|
|
+ not be determined prior to writing the packet; especially this will
|
|
|
|
|
+ be used if large amounts of data are processed in filter mode.
|
|
|
|
|
+
|
|
|
|
|
+ It works like this: After the CTB (with a length field of 11) a
|
|
|
|
|
+ marker field is used, which gives the length of the following datablock.
|
1999-01-12 11:20:24 +01:00
|
|
|
|
+ This is a simple 2 byte field (MSB first) containing the amount of data
|
1998-02-18 14:58:46 +01:00
|
|
|
|
+ following this field, not including this length field. After this datablock
|
|
|
|
|
+ another length field follows, which gives the size of the next datablock.
|
|
|
|
|
+ A value of 0 indicates the end of the packet. The maximum size of a
|
|
|
|
|
+ data block is limited to 65534, thereby reserving a value of 0xffff for
|
1999-01-12 11:20:24 +01:00
|
|
|
|
+ future extensions. These length markers must be inserted into the data
|
1998-02-18 14:58:46 +01:00
|
|
|
|
+ stream just before writing the data out.
|
|
|
|
|
+
|
|
|
|
|
+ This 2 byte filed is large enough, because the application must buffer
|
|
|
|
|
+ this amount of data to prepend the length marker before writing it out.
|
|
|
|
|
+ Data block sizes larger than about 32k doesn't make any sense. Note
|
|
|
|
|
+ that this may also be used for compressed data streams, but we must use
|
|
|
|
|
+ another packet version to tell the application that it can not assume,
|
|
|
|
|
+ that this is the last packet.
|
|
|
|
|
|
1998-04-04 22:16:55 +02:00
|
|
|
|
|
1998-10-21 19:34:36 +02:00
|
|
|
|
Usage of gdbm files for keyrings
|
|
|
|
|
================================
|
1999-01-12 11:20:24 +01:00
|
|
|
|
The key to store the keyblock is it's fingerprint, other records
|
1998-10-21 19:34:36 +02:00
|
|
|
|
are used for secondary keys. fingerprints are always 20 bytes
|
1999-02-10 17:22:40 +01:00
|
|
|
|
where 16 bit fingerprints are appended with zero.
|
1998-10-21 19:34:36 +02:00
|
|
|
|
The first byte of the key gives some information on the type of the
|
|
|
|
|
key.
|
|
|
|
|
1 = key is a 20 bit fingerprint (16 bytes fpr are padded with zeroes)
|
|
|
|
|
data is the keyblock
|
|
|
|
|
2 = key is the complete 8 byte keyid
|
|
|
|
|
data is a list of 20 byte fingerprints
|
|
|
|
|
3 = key is the short 4 byte keyid
|
|
|
|
|
data is a list of 20 byte fingerprints
|
|
|
|
|
4 = key is the email address
|
|
|
|
|
data is a list of 20 byte fingerprints
|
|
|
|
|
|
|
|
|
|
Data is prepended with a type byte:
|
|
|
|
|
1 = keyblock
|
|
|
|
|
2 = list of 20 byte padded fingerprints
|
|
|
|
|
3 = list of list fingerprints (but how to we key them?)
|
|
|
|
|
|
|
|
|
|
|
1998-04-04 22:16:55 +02:00
|
|
|
|
|
|
|
|
|
|
1998-10-12 22:16:38 +02:00
|
|
|
|
Other Notes
|
|
|
|
|
===========
|
|
|
|
|
* For packet version 3 we calculate the keyids this way:
|
|
|
|
|
RSA := low 64 bits of n
|
|
|
|
|
ELGAMAL := build a v3 pubkey packet (with CTB 0x99) and calculate
|
|
|
|
|
a rmd160 hash value from it. This is used as the
|
|
|
|
|
fingerprint and the low 64 bits are the keyid.
|
|
|
|
|
|
|
|
|
|
* Revocation certificates consist only of the signature packet;
|
|
|
|
|
"import" knows how to handle this. The rationale behind it is
|
|
|
|
|
to keep them small.
|
|
|
|
|
|
|
|
|
|
|
1998-10-18 17:21:22 +02:00
|
|
|
|
Supported targets:
|
|
|
|
|
------------------
|
|
|
|
|
powerpc-unknown-linux-gnu (linuxppc)
|
|
|
|
|
hppa1.1-hp-hpux10.20
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1998-10-12 22:16:38 +02:00
|
|
|
|
|
1998-04-04 22:16:55 +02:00
|
|
|
|
|
1998-06-09 17:14:06 +02:00
|
|
|
|
|
|
|
|
|
|
1998-04-04 22:16:55 +02:00
|
|
|
|
Keyserver Message Format
|
|
|
|
|
-------------------------
|
|
|
|
|
|
|
|
|
|
The keyserver may be contacted by a Unix Domain socket or via TCP.
|
|
|
|
|
|
1998-04-20 16:47:21 +02:00
|
|
|
|
The format of a request is:
|
1998-04-04 22:16:55 +02:00
|
|
|
|
|
|
|
|
|
----
|
|
|
|
|
command-tag
|
|
|
|
|
"Content-length:" digits
|
|
|
|
|
CRLF
|
|
|
|
|
------
|
|
|
|
|
|
|
|
|
|
Where command-tag is
|
|
|
|
|
|
1998-04-20 16:47:21 +02:00
|
|
|
|
NOOP
|
1998-04-04 22:16:55 +02:00
|
|
|
|
GET <user-name>
|
|
|
|
|
PUT
|
|
|
|
|
DELETE <user-name>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The format of a response is:
|
|
|
|
|
|
|
|
|
|
------
|
|
|
|
|
"GNUPG/1.0" status-code status-text
|
|
|
|
|
"Content-length:" digits
|
|
|
|
|
CRLF
|
|
|
|
|
------------
|
|
|
|
|
followed by <digits> bytes of data
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Status codes are:
|
|
|
|
|
|
|
|
|
|
o 1xx: Informational - Request received, continuing process
|
|
|
|
|
|
|
|
|
|
o 2xx: Success - The action was successfully received, understood,
|
|
|
|
|
and accepted
|
|
|
|
|
|
|
|
|
|
o 4xx: Client Error - The request contains bad syntax or cannot be
|
|
|
|
|
fulfilled
|
|
|
|
|
|
|
|
|
|
o 5xx: Server Error - The server failed to fulfill an apparently
|
|
|
|
|
valid request
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1998-05-26 15:38:00 +02:00
|
|
|
|
Ich werde jetzt doch das HKP Protokoll implementieren:
|
|
|
|
|
|
|
|
|
|
Naja, die Doku ist so gut wie nichtexistent, da gebe ich Dir recht.
|
|
|
|
|
In kurzen Worten:
|
|
|
|
|
|
|
|
|
|
(Minimal-)HTTP-Server auf Port 11371, versteht ein GET auf /pks/lookup,
|
|
|
|
|
wobei die Query-Parameter (Key-Value-Paare mit = zwischen Key und
|
|
|
|
|
Value; die Paare sind hinter ? und durch & getrennt). G<>ltige
|
|
|
|
|
Operationen sind:
|
|
|
|
|
|
|
|
|
|
- - op (Operation) mit den M<>glichkeiten index (gleich wie -kv bei
|
|
|
|
|
PGP), vindex (-kvv) und get (-kxa)
|
|
|
|
|
- - search: Liste der Worte, die im Key vorkommen m<>ssen. Worte sind
|
|
|
|
|
mit Worttrennzeichen wie Space, Punkt, @, ... getrennt, Worttrennzeichen
|
|
|
|
|
werden nicht betrachtet, die Reihenfolge der Worte ist egal.
|
|
|
|
|
- - exact: (on=aktiv, alles andere inaktiv) Nur die Schl<68>ssel
|
|
|
|
|
zur<75>ckgeben, die auch den "search"-String beinhalten (d.h.
|
|
|
|
|
Wortreihenfolge und Sonderzeichen sind wichtig)
|
|
|
|
|
- - fingerprint (Bei [v]index auch den Fingerprint ausgeben), "on"
|
|
|
|
|
f<>r aktiv, alles andere inaktiv
|
|
|
|
|
|
|
|
|
|
Neu (wird von GNUPG benutzt):
|
|
|
|
|
/pks/lookup/<gnupg_formatierte_user_id>?op=<operation>
|
|
|
|
|
|
|
|
|
|
Zus<EFBFBD>tzlich versteht der Keyserver auch ein POST auf /pks/add, womit
|
|
|
|
|
man Keys hochladen kann.
|
|
|
|
|
|