diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/DETAILS | 32 | ||||
| -rw-r--r-- | doc/gpg.1pod | 50 |
2 files changed, 41 insertions, 41 deletions
diff --git a/doc/DETAILS b/doc/DETAILS index 6f1d895ad..de5a84747 100644 --- a/doc/DETAILS +++ b/doc/DETAILS @@ -6,7 +6,7 @@ a rmd160 hash value from it. This is used as the fingerprint and the low 64 bits are the keyid. - * Revocation certificates consists only of the signature packet; + * Revocation certificates consist only of the signature packet; "import" knows how to handle this. The rationale behind it is to keep them small. @@ -17,7 +17,7 @@ Layout of the TrustDB ===================== FIXME: use a directory record as top node instead of the pubkey record -The TrustDB is build from fixed length records, where the first bytes +The TrustDB is built from fixed length records, where the first byte 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 the DB is always of type 1 and this is the only record of this type. @@ -29,7 +29,7 @@ Record type 0: Record type 1: -------------- Version information for this TrustDB. This is always the first - record of the DB and the onyl one with type 1. + record of the DB and the only one with type 1. 1 byte value 1 3 bytes 'gpg' magic value 1 byte Version of the TrustDB @@ -74,7 +74,7 @@ Record type 3: 1 byte reserved 1 u32 owner This is used to bind all records for a given certificate together. It is valid only in this TrustDB - and usefull if we have duplicate keyids + and useful if we have duplicate keyids It points back to the directory node. 1 byte pubkey algorithm 1 byte reserved @@ -86,7 +86,7 @@ Record type 3: Record type 4: (cache record) -------------- Used to bind the trustDB to the concrete instance of keyblock in - a pubring. This is used to cache informations. + a pubring. This is used to cache information. 1 byte value 4 1 byte reserved @@ -132,14 +132,14 @@ Record Type 6 (hash table) ------------- Due to the fact that we use the keyid to lookup keys, we can implement quick access by some simple hash methods, and avoid - the overhead gdbm. A property of keyids is that they can be - used directly as hash value (They can be considered as strong - random numbers. + the overhead of gdbm. A property of keyids is that they can be + used directly as hash values. (They can be considered as strong + random numbers.) What we use is a dynamic multilevel architecture, which combines - Hashtables, record lists, and linked list. + Hashtables, record lists, and linked lists. This record is a hashtable of 256 entries; a special property - is, that all these records are adjacent stored to make up one + is that all these records are stored consecutively to make one big table. The hash value is simple the 1st, 2nd, ... byte of the keyid (depending on the indirection level). @@ -154,15 +154,15 @@ Record Type 6 (hash table) which is 29 for a record length of 40. To look up a key we use its lsb to get the recnum from this - hashtable and look up this addressed record: + hashtable and look up the addressed record: - If this record is another hashtable, we use 2nd lsb to index this hast table and so on. - - if this record is of hashlist, we lwalk thru these - reclist record until we found one whos hash fields + - if this record is a hashlist, we walk thru the + reclist records until we found one whose hash field matches the MSB of our keyid, and lookup this record - if this record is a dir record, we compare the keyid and if this is correct, we get the keyrecod and compare - the fingerprint to decide wether it is the requested key; + the fingerprint to decide whether it is the requested key; if this is not the correct dir record, we look at the next dir record which is linked by the link field. @@ -185,8 +185,8 @@ Record type 7 (hash list) Packet Headers =============== -GNUPG uses PGP 2 packet headers and also understand OpenPGP packet header. -There is one enhavement used ith the old style packet headers: +GNUPG uses PGP 2 packet headers and also understands OpenPGP packet header. +There is one enhancement used with the old style packet headers: CTB bits 10, the "packet-length length bits", have values listed in the following table: diff --git a/doc/gpg.1pod b/doc/gpg.1pod index da755256f..002aee1fd 100644 --- a/doc/gpg.1pod +++ b/doc/gpg.1pod @@ -8,14 +8,14 @@ B<gpg> [--homedir name] [--options file] [options] command [args] =head1 DESCRIPTION -This is the main program from the GNUPG system. +This is the main program for the GNUPG system. =head1 COMMANDS B<gpg> recognizes these commands: B<-s>, B<--sign> - Make a signature. This option maybe combined + Make a signature. This option may be combined with B<--encrypt>. B<--clearsign> @@ -28,7 +28,7 @@ B<-e>, B<--encrypt> Encrypt data. This option may be combined with B<--sign>. B<-c>, B<--symmetric> - Encrypt only with symmetric cipher + Encrypt with symmetric cipher only This command asks for a passphrase. B<--store> @@ -39,8 +39,8 @@ B<--decrypt> [I<file>] write it to stdout (or the file specified with B<--output>). If the decrypted file is signed, the signature is also verified. This command differs - from the default operation, as it never write to the - filename which is included in the file and that it + from the default operation, as it never writes to the + filename which is included in the file and it rejects files which don't begin with an encrypted message. @@ -49,27 +49,27 @@ B<--verify> [[I<sigfile>] {I<signed-files>}] without generating any output. With no arguments, the signature packet is read from stdin (it may be a detached signature when not used in batch mode). If - only a sigfile is given, is maybe a complete signature - or a detached signature in which case the signed stuff + only a sigfile is given, it may be a complete signature + or a detached signature, in which case the signed stuff is expected from stdin. With more than 1 argument, the first should be a detached signature and the remaining files are the signed stuff. B<-k> [I<username>] [I<keyring>] - Kludge to be somewhat compatibe to PGP. - Without arguments, all public key-rings are listed, - with one argument, only I<keyring> is listed. + Kludge to be somewhat compatible with PGP. + Without arguments, all public key-rings are listed. + With one argument, only I<keyring> is listed. Special combinations are also allowed, but it may - give starnge results when combined with more options. + give strange results when combined with more options. B<-kv> Same as B<-k> B<-kvv> List the signatures with every key. - B<-kvvv> Additional check all signatures. + B<-kvvv> Additionally check all signatures. B<-kvc> List fingerprints B<-kvvc> List fingerprints and signatures B<--list-keys> [I<names>] - List all keys from the default public keyring or just the ones - given on the commandline. + List all keys from the default public keyring, or just the ones + given on the command line. B<--list-sigs> [I<names>] Same as B<--list-keys>, but the signatures are listed too. @@ -97,8 +97,8 @@ B<--sign-key> I<name> all existing signatures of this key. If the key is not yet signed by the default user (or the users given with B<-u>), the program displays the information of - the key again, together with it's fingerprint and - asked whether it should be signed. This question + the key again, together with its fingerprint and + asks whether it should be signed. This question is repeated for all users specified with B<-u>. The key is then signed and the keyring which contains the key is updated. @@ -121,7 +121,7 @@ B<--gen-revoke> B<--export> [I<names>] Either export all keys from all key-rings (default - key-rings and those registered via option B<--keyring>, + key-rings and those registered via option B<--keyring>), or if at least one name is given, those of the given name. The new keyring is written to F<stdout> or to the file given with option "output". Use together @@ -135,8 +135,8 @@ B<--import> Long options can be put in an options file (default F<~/.gnupg/options>); do not write the 2 dashes, but simply the name of the option and any -arguments if required, lines with a hash as the first non-white-space -character are ignored. Commands maybe put in this file too, but that +arguments if required. Lines with a hash as the first non-white-space +character are ignored. Commands may be put in this file too, but that does not make sense. B<gpg> recognizes these options: @@ -159,8 +159,8 @@ B<-r> I<name>, B<--remote-user> I<name> so that it can be used in an options file. B<-v>, B<--verbose> - Give more informations during processing. If used - 2 times, the input data is listed in detail. + Give more information during processing. If used + twice, the input data is listed in detail. B<-z> I<n> @@ -229,7 +229,7 @@ B<--no-comment> Do not write comment packets. B<--completes-needed> I<n> - Number of completey trusted users to introduce a new + Number of completely trusted users to introduce a new key signator (defaults to 1). B<--marginals-needed> I<n> @@ -238,17 +238,17 @@ B<--marginals-needed> I<n> B<--cipher-algo> I<name> Use I<name> as cipher algorithm. Running the program - with the option B<--verbose> yields a list off supported + with the option B<--verbose> yields a list of supported algorithms. B<--pubkey-algo> I<name> Use I<name> as puplic key algorithm. Running the program - with the option B<--verbose> yields a list off supported + with the option B<--verbose> yields a list of supported algorithms. B<--digest-algo> I<name> Use I<name> as message digest algorithm. Running the - program with the option B<--verbose> yields a list off + program with the option B<--verbose> yields a list of supported algorithms. B<--passphrase-fd> I<n> |