security-and-privacy/gnupg
security-and-privacy/gnupg
1
0
Fork 0
mirror of git://git.gnupg.org/gnupg.git synced 2025-07-02 22:46:30 +02:00
Code Activity

This commit was manufactured by cvs2svn to create branch

Browse source 
'GNUPG-1-9-BRANCH'.
This commit is contained in:
Repo Admin 2002-10-19 07:55:27 +00:00
parent 8d76177f10
commit 82a17c9fb3
563 changed files with 0 additions and 267875 deletions
Download patch file Download diff file Expand all files Collapse all files

500
doc/ChangeLog
View file

@ -1,500 +0,0 @@
2002-10-12 Werner Koch <wk@gnupg.org>
* DETAILS (KEY_CREATED): Enhanced by fingerprint.
2002-10-03 David Shaw <dshaw@jabberwocky.com>
* gpg.sgml: Note that '#' means secret-key-unavailable, and that
keyserver schemes are case-insensitive.
2002-09-30 David Shaw <dshaw@jabberwocky.com>
* gpg.sgml: Note that --pgp2 disables --textmode when encrypting.
2002-09-20 David Shaw <dshaw@jabberwocky.com>
* gpg.sgml: Some minor language cleanup.
2002-09-20 Werner Koch <wk@gnupg.org>
* DETAILS: s/XORed/ORed/.
2002-09-15 Werner Koch <wk@gnupg.org>
* gpg.sgml: Add rebuild-keydb-caches.
2002-09-12 David Shaw <dshaw@jabberwocky.com>
* DETAILS: Fix batch key generation example.
2002-09-11 Werner Koch <wk@gnupg.org>
* Makefile.am (EXTRA_DIST): Include gnupg-32.reg
2002-09-02 Werner Koch <wk@gnupg.org>
* gpg.sgml: Updated the charset option.
* DETAILS: Added status IMPORT_OK.
* gnupg.7: New mini man page.
2002-08-30 David Shaw <dshaw@jabberwocky.com>
* gpg.sgml: Document keyserver-option include-subkeys. Note that
honor-http-proxy is a keyserver-option now.
* DETAILS: Add "Key not trusted" to INV_RECP status code.
2002-08-23 Werner Koch <wk@gnupg.org>
* faq.raw: Updated. New Maintainer is David D. Scribner.
2002-08-22 David Shaw <dshaw@jabberwocky.com>
* gpg.sgml: Clarify meaning of keyserver option include-revoked.
2002-08-21 Werner Koch <wk@gnupg.org>
* DETAILS: Added IMPORT_PROBLEM.
2002-08-20 David Shaw <dshaw@jabberwocky.com>
* DETAILS: Clarify that trust letters 'q' and '-' can be treated
identically.
* gpg.sgml: Document --ignore-mdc-error.
2002-08-06 David Shaw <dshaw@jabberwocky.com>
* gpg.sgml: Clarify that only long-form options can go in the
config file.
2002-08-06 Werner Koch <wk@gnupg.org>
* gpg.sgml: Fixed doc regarding the name change of the option
file.
2002-07-30 David Shaw <dshaw@jabberwocky.com>
* gpg.sgml: Clarify --edit/addrevoker (sensitive), and
--keyserver-options (--import/export-options may be used as well).
Document --import-options and --export-options with their various
options. --show-photos now works during signature verification as
well. Document --exec-path. Note in --simple-sk-checksum that
the passphrase must be changed for this to take effect. Note that
--pgp7 does not disable MDC. Document --no-mdc-warning.
2002-07-25 Werner Koch <wk@gnupg.org>
* gpg.sgml: Document new --delete behaviour.
2002-07-25 David Shaw <dshaw@jabberwocky.com>
* gpg.sgml: Clarify the differences between "pref" and "showpref".
Note in "setpref" that a list of available algorithms can be
printed with "gpg -v --version". Note in "updpref" that we don't
select keys via attribute uids, so preferences there will be
ignored.
2002-07-01 David Shaw <dshaw@jabberwocky.com>
* gpg.sgml: Clarify "group".
2002-07-01 Werner Koch <wk@gnupg.org>
* Makefile.am: Due to problems with VPATH builds we don't try to
build the texi vesions of the manual pages anymore automatically.
2002-06-30 Werner Koch <wk@gnupg.org>
* README.W32: Adjusted some descriptions. Fixed the regsitry
entry descriptions.
2002-06-21 David Shaw <dshaw@jabberwocky.com>
* DETAILS: Document "uat".
* gpg.sgml: Document
--personal-{compress|digest|compress}-preferences, --group, and
add comments to --expert.
2002-06-17 Werner Koch <wk@gnupg.org>
* gpg.sgml: Grammar fix.
2002-06-03 David Shaw <dshaw@jabberwocky.com>
* DETAILS: Details of ATTRIBUTE.
* gpg.sgml: Document --attribute-fd
2002-06-03 Timo Schulz <ts@winpt.org>
* DETAILS: Add ATTRIBUTE.
2002-05-31 David Shaw <dshaw@jabberwocky.com>
* gpg.sgml: Add "edit/addrevoker". Document --desig-revoke. Note
that -z and --compress are the same option. Note that
--digest-algo can no longer violate OpenPGP with a non-160 bit
hash with DSA. Document --cert-digest-algo with suitable warnings
not to use it. Note the default s2k-cipher-algo is now CAST5.
Note that --force-v3-sigs overrides --ask-sig-expire. Revise
--expert documentation, as it is now definitely legal to have more
than one photo ID on a key. --preference-list is now
--default-preference-list with the new meaning. Document
--personal-preference-list.
* DETAILS: Document "Revoker" for batch key generation.
2002-05-22 Werner Koch <wk@gnupg.org>
* gpg.sgml: sgml syntax fix.
2002-05-12 Werner Koch <wk@gnupg.org>
* gpg.sgml: Fixed URL in the description section.
* faq.raw: Minor typo fixes noted by kromJx@myrealbox.com.
2002-05-11 Werner Koch <wk@gnupg.org>
* gpg.sgml: Typo fix.
2002-05-07 David Shaw <dshaw@jabberwocky.com>
* gpg.sgml: Add entries for --sk-comments, --no-sk-comments,
--pgp7, and --no-pgp7. Fix --pgp2 and --pgp6: the proper name is
--escape-from-lines and not --escape-from.
2002-04-30 Timo Schulz <ts@winpt.org>
* gpg.sgml: Add an entry for --encrypt-files and --decrypt-files.
2002-04-29 David Shaw <dshaw@jabberwocky.com>
* gpg.sgml: Fix minor error in --pgp6 documentation: it does not
imply --digest-algo MD5
2002-04-29 Werner Koch <wk@gnupg.org>
* samplekeys.asc: Added gnupg distribution key 57548DCD.
* faq.raw: Inserted Douglas Calvert as new maintainer. Acknowledge
Nils. Add entry about trust packet parsing problems.
2002-04-24 David Shaw <dshaw@jabberwocky.com>
* gpg.sgml: Add some documentation for
--edit/{addphoto|showphoto|nrsign|nrlsign}, and the difference
between %t and %T in photo viewer command lines.
2002-04-23 Stefan Bellon <sbellon@sbellon.de>
* gpg.sgml: Moved options from section "COMMANDS" to
section "OPTIONS".
2002-04-20 David Shaw <dshaw@jabberwocky.com>
* samplekeys.asc: Added 0x5B0358A2
2002-04-19 David Shaw <dshaw@jabberwocky.com>
* gpg.sgml: Add "%t" flag for photo IDs, a note about primary
having different meanings for photo and regular IDs, rename
--default-check-level to --default-cert-check-level, add
--auto-check-trustdb, and --pgp6.
* DETAILS: Add EXPSIG, EXPKEYSIG, and KEYEXPIRED. Add notes to
SIGEXPIRED (deprecated), and VALIDSIG (added expiration date).
Add "Preferences" command to unattended key generation
instructions. Also fixed a few typos.
* samplekeys.asc: new (added to EXTRA_DIST in Makefile.am as well)
2002-01-31 Marcus Brinkmann <marcus@g10code.de>
* DETAILS: Fix a spelling error, correct IMPORTED_RES to IMPORT_RES,
correct INV_RECP (the second occurence) to NO_RECP.
2002-04-03 David Shaw <dshaw@jabberwocky.com>
* gpg.sgml: auto-key-retrieve is a keyserver-option (noted by
Roger Sondermann).
2002-03-27 David Shaw <dshaw@jabberwocky.com>
* gpg.sgml: --pgp2 also means --disable-mdc, --no-ask-sig-expire,
and --no-ask-cert-expire. It does not mean --no-force-v3-sigs
(noted by Timo).
2002-03-27 David Shaw <dshaw@jabberwocky.com>
* gpg.sgml: Add a few notes about --pgp2 meaning MIT PGP 2.6.2,
and keyserver details about HKP and NAI HKP.
2002-03-18 David Shaw <dshaw@jabberwocky.com>
* gpg.sgml: Change meaning of --allow-non-selfsigned-uid to match
change in code, and add --no-allow-non-selfsigned-uid.
2002-03-13 Werner Koch <wk@gnupg.org>
* faq.raw: Due to a lack of time Nils can't serve anymore as a
maintainer. Removed his address and setup a generic address.
2002-03-06 Werner Koch <wk@gnupg.org>
* gpg.sgml: Add an entry for --export-ownertrust. Suggested by
Bernhard Reiter.
2002-01-26 Timo Schulz <ts@winpt.org>
* gnupg-w32.reg: New. Registry file for W32 in registry format.
2002-01-26 Werner Koch <wk@gnupg.org>
* gpg.sgml: A few words about --gpg-agent-info and GPG_AGENT_INFO.
2002-01-25 Timo Schulz <ts@winpt.org>
* README.W32: Modify the filename because now the .exe extension
is automatically added to the binary.
2002-01-14 Werner Koch <wk@gnupg.org>
* gpg.sgml: Talk about PGP 5 and higher.
2002-01-11 David Shaw <dshaw@jabberwocky.com>
* gpg.sgml: Added documentation for --{no-}ask-cert-expire,
--{no-}ask-sig-expire, and revise --expert (it doesn't switch on
the expiration prompt anymore) and --default-check-level (to be
clearer as to what makes a good key check before signing).
2002-01-07 Werner Koch <wk@gnupg.org>
* DETAILS: Removed the comment that unattended key generation is
experimental. It is now a standard feature.
2001-12-22 David Shaw <dshaw@jabberwocky.com>
* gpg.sgml: Fixed a few typos.
* gpg.sgml: Added documentation for --show-photos,
--no-show-photos, --photo-viewer, --nrsign-key,
--default-check-level, --search-keys, --keyserver-options,
--show-notation, --no-show-notation, --show-policy-url,
--no-show-policy-url, --for-your-eyes-only,
--no-for-your-eyes-only, --pgp2, --no-pgp2,
--no-permission-warning, --expert, --no-expert.
2001-10-31 Werner Koch <wk@gnupg.org>
* gpg.sgml: Add a remark on how to get the long key ID. Suggested
by Sebastian Klemke.
2001-10-23 Werner Koch <wk@gnupg.org>
* gpg.sgml: Add missing tag.
2001-09-28 Werner Koch <wk@gnupg.org>
* gpg.sgml: Add a note on option parsing.
2001-09-24 Werner Koch <wk@gnupg.org>
* gpg.sgml: Described --{update,check}-trustdb.
2001-09-03 Werner Koch <wk@gnupg.org>
* gpg.sgml, gpgv.sgml: Removed GDBM stuff.
2001-08-29 Werner Koch <wk@gnupg.org>
* faq.raw: Described how to delete a secret key w/o a public key
and changed the entry on updating the preferences.
2001-08-08 Werner Koch <wk@gnupg.org>
* gpg.sgml: Documented --print-mds and marked the --print-md * as
deprecated because it does not work in the W32 version. Suggested
by John Kane.
(WARNINGS): Typo fix.
(--with-colons): Clarified that the output is in UTF-8.
2001-08-01 Werner Koch <wk@gnupg.org>
* gpg.sgml: Added --ignore-valid-from
2001-04-20 Werner Koch <wk@gnupg.org>
* faq.raw (Maintained-by): Removed note that load-extension is not
available under Windoze.
* gpg.sgml: Add new --charset UTF-8.
2001-04-19 Werner Koch <wk@gnupg.org>
* faq.raw: Add a note about dates displayed as ????-??-??.
2001-04-17 Werner Koch <wk@gnupg.org>
* Makefile.am (%.texi): Add rules to create .texi from .sgml.
However we can't automate this because automake does not like
.texi files as BUILT_SOURCES.
(%.dvi,%.ps): Removed these rules, because they are not needed
and get in the way of automake's dvi target
* HACKING: Changed CVS description.
2001-04-06 Werner Koch <wk@gnupg.org>
* gpg.sgml: Small typo fixes by Florian Weimer.
2001-03-27 Werner Koch <wk@gnupg.org>
* gpg.sgml: Add --no-sig-cache and --no-sig-create-check.
2001-03-23 Werner Koch <wk@gnupg.org>
* DETAILS: New status UNEXPECTED.
2001-03-13 Werner Koch <wk@gnupg.org>
* gpg.sgml: Described --fixed-list-mode.
2001-03-06 Werner Koch <wk@gnupg.org>
* gpgv.sgml: Changed some gpg to gpgv. Thanks to John A. Murdie.
2001-03-03 Werner Koch <wk@gnupg.org>
* gpg.sgml: Tell something about the 0x12345678! key ID syntax.
2001-01-18 Werner Koch <wk@gnupg.org>
* README.W32: Changed building instructions for MinGW32/CPD 0.3
2001-01-09 Werner Koch <wk@gnupg.org>
* DETAILS: Fixed docs for NEED_PASSPHRASE and added USERID_HINT.
2000-11-30 Werner Koch <wk@gnupg.org>
* gpg.sgml: Fixed the description of --verify. Add a short note
the warnings sections.
2000-10-19 Werner Koch <wk@gnupg.org>
* gpg.sgml: Fixed doc for --allow-non-selfsigned-uid.
Add entry for --ignore-crc-error.
2000-10-18 Werner Koch <wk@gnupg.org>
* OpenPGP: Dropped the paragraph that RSA is not implemented.
2000-10-14 Werner Koch <wk@gnupg.org>
* faq.raw: Add an answer to the problem of multiple signatures.
Wed Oct 4 15:50:18 CEST 2000 Werner Koch <wk@openit.de>
* gpgv.sgml: New.
* Makefile.am: build it.
Thu Sep 14 14:20:38 CEST 2000 Werner Koch <wk@openit.de>
* faq.raw: New.
* Makefile.am: Support to build FAQs
Wed Jul 12 13:32:06 CEST 2000 Werner Koch <wk@>
* gpg.sgml: Add a note about the availability of the GPH.
2000-07-03 13:59:24 Werner Koch (wk@habibti.openit.de)
* DETAILS, FAQ: Typo fixes by Yosiaki IIDA.
2000-05-12 10:57:21 Werner Koch (wk@habibti.openit.de)
* gpg.sgml: Documented --no-tty.
2000-03-09 15:01:51 Werner Koch (wk@habibti.openit.de)
* DETAILS: Ad a short blurb about unattended key generation.
Wed Feb 9 15:33:44 CET 2000 Werner Koch <wk@gnupg.de>
* gpg.sgml: Describe --ignore-time-conflict.
* gpg.sgml: Fixed a few typos. Thanks to Holger Trapp.
Wed Jan 5 11:51:17 CET 2000 Werner Koch <wk@gnupg.de>
* FAQ: Enhanced answer for the 3des-s2k bug.
Sat Dec 4 12:30:28 CET 1999 Werner Koch <wk@gnupg.de>
* gpg.sgml: Add section about the user ID
Mon Nov 22 11:14:53 CET 1999 Werner Koch <wk@gnupg.de>
* gph: Removed the directory from the dist becuase it will
go into it's own package.
Thu Sep 23 09:52:58 CEST 1999 Werner Koch <wk@isil.d.shuttle.de>
* README.W32: New.
Mon Sep 6 19:59:08 CEST 1999 Werner Koch <wk@isil.d.shuttle.de>
* Makefile.am (SUBDIRS): New subdir gph for the manual.
Thu Jul 22 20:03:03 CEST 1999 Werner Koch <wk@isil.d.shuttle.de>
* gpg.sgml (--always-trust): Added.
Wed Jul 14 19:42:08 CEST 1999 Werner Koch <wk@isil.d.shuttle.de>
* Makefile.am: Create a dummy man page if docbook-to-man is missing.
Wed Jun 16 20:16:21 CEST 1999 Werner Koch <wk@isil.d.shuttle.de>
* gpg1.pod: Removed.
* gpg.sgml: New. Replaces the pod file
* Makefile.am: Add rule to make a man file from sgml
Tue Jun 15 12:21:08 CEST 1999 Werner Koch <wk@isil.d.shuttle.de>
* Makefile.in.in: Use DESTDIR.
Mon May 31 19:41:10 CEST 1999 Werner Koch <wk@isil.d.shuttle.de>
* gpg.1pod: Enhanced the Bugs section (Michael).
Wed Feb 10 17:15:39 CET 1999 Werner Koch <wk@isil.d.shuttle.de>
* gpg.1pod: Spelling and grammar corrections (John A. Martin)
* FAQ: Ditto.
* DETAILS: Ditto.
Copyright 1998, 1999, 2000, 2001 Free Software Foundation, Inc.
This file is free software; as a special exception the author gives
unlimited permission to copy and/or distribute it, with or without
modifications, as long as this notice is preserved.
This file is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY, to the extent permitted by law; without even the
implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

990
doc/DETAILS
View file

@ -1,990 +0,0 @@
Format of colon listings
========================
First an example:
$ gpg --fixed-list-mode --with-colons --list-keys \
--with-fingerprint --with-fingerprint wk@gnupg.org
pub:f:1024:17:6C7EE1B8621CC013:899817715:1055898235::m:::scESC:
fpr:::::::::ECAF7590EB3443B5C7CF3ACB6C7EE1B8621CC013:
uid:f::::::::Werner Koch <wk@g10code.com>:
uid:f::::::::Werner Koch <wk@gnupg.org>:
sub:f:1536:16:06AD222CADF6A6E1:919537416:1036177416:::::e:
fpr:::::::::CF8BCC4B18DE08FCD8A1615906AD222CADF6A6E1:
sub:r:1536:20:5CE086B5B5A18FF4:899817788:1025961788:::::esc:
fpr:::::::::AB059359A3B81F410FCFF97F5CE086B5B5A18FF4:
The double --with-fingerprint prints the fingerprint for the subkeys
too, --fixed-list-mode is themodern listing way printing dates in
seconds since Epoch and does not merge the first userID with the pub
record.
1. Field: Type of record
pub = public key
crt = X.509 certificate
crs = X.509 certificate and private key available
sub = subkey (secondary key)
sec = secret key
ssb = secret subkey (secondary key)
uid = user id (only field 10 is used).
uat = user attribute (same as user id except for field 10).
sig = signature
rev = revocation signature
fpr = fingerprint: (fingerprint is in field 10)
pkd = public key data (special field format, see below)
grp = reserved for gpgsm
rvk = revocation key
2. Field: A letter describing the calculated trust. This is a single
letter, but be prepared that additional information may follow
in some future versions. (not used for secret keys)
o = Unknown (this key is new to the system)
i = The key is invalid (e.g. due to a missing self-signature)
d = The key has been disabled
r = The key has been revoked
e = The key has expired
- = Unknown trust (i.e. no value assigned)
q = Undefined trust
'-' and 'q' may safely be treated as the same
value for most purposes
n = Don't trust this key at all
m = There is marginal trust in this key
f = The key is full trusted.
u = The key is ultimately trusted; this is only used for
keys for which the secret key is also available.
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)
(for other id's see include/cipher.h)
5. Field: KeyID either of
6. Field: Creation Date (in UTC)
7. Field: Key expiration date or empty if none.
8. Field: Used for serial number in crt records (used to be the Local-ID)
9. Field: Ownertrust (primary public keys only)
This is a single letter, but be prepared that additional
information may follow in some future versions.
10. Field: User-ID. The value is quoted like a C string to avoid
control characters (the colon is quoted "\x3a").
This is not used with --fixed-list-mode in gpg.
A UAT record puts the attribute subpacket count here, a
space, and then the total attribute subpacket size.
In gpgsm the issuer name comes here
An FPR record stores the fingerprint here.
The fingerprint of an revocation key is stored here.
11. Field: Signature class. This is a 2 digit hexnumber followed by
either the letter 'x' for an exportable signature or the
letter 'l' for a local-only signature.
The class byte of an revocation key is also given here,
'x' and 'l' ist used the same way.
12. Field: Key capabilities:
e = encrypt
s = sign
c = certify
A key may have any combination of them. The primary key has in
addition to these letters, uppercase version of the letter to
denote the _usable_ capabilities of the entire key.
13. Field: Used in FPR records for S/MIME keys to store the fingerprint of
the issuer certificate. This is useful to build the
certificate path based on certificates stored in the local
keyDB; it is only filled if the issue certificate is
available. The advantage of using this value is that it is
guaranteed to have been been build by the same lookup
algorithm as gpgsm uses.
For "uid" recods this lists the preferences n the sameway the
-edit menu does.
14. Field Flag field used in the --edit menu output:
All dates are displayed in the format yyyy-mm-dd unless you use the
option --fixed-list-mode in which case they are displayed as seconds
since Epoch. More fields may be added later, so parsers should be
prepared for this. When parsing a number the parser should stop at the
first non-number character so that additional information can later be
added.
If field 1 has the tag "pkd", a listing looks like this:
pkd:0:1024:B665B1435F4C2 .... FF26ABB:
! ! !-- the value
! !------ for information number of bits in the value
!--------- index (eg. DSA goes from 0 to 3: p,q,g,y)
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
more arguments in future versions.
GOODSIG <long keyid> <username>
The signature with the keyid is good. For each signature only
one of the three codes GOODSIG, BADSIG or ERRSIG will be
emitted and they may be used as a marker for a new signature.
The username is the primary one encoded in UTF-8 and %XX
escaped.
EXPSIG <long keyid> <username>
The signature with the keyid is good, but the signature is
expired. The username is the primary one encoded in UTF-8 and
%XX escaped.
EXPKEYSIG <long keyid> <username>
The signature with the keyid is good, but the signature was
made by an expired key. The username is the primary one
encoded in UTF-8 and %XX escaped.
BADSIG <long keyid> <username>
The signature with the keyid has not been verified okay.
The username is the primary one encoded in UTF-8 and %XX
escaped.
ERRSIG <long keyid> <pubkey_algo> <hash_algo> \
<sig_class> <timestamp> <rc>
It was not possible to check the signature. This may be
caused by a missing public key or an unsupported algorithm.
A RC of 4 indicates unknown algorithm, a 9 indicates a missing
public key. The other fields give more information about
this signature. sig_class is a 2 byte hex-value.
VALIDSIG <fingerprint in hex> <sig_creation_date> <sig-timestamp>
<expire-timestamp>
The signature with the keyid is good. This is the same
as GOODSIG but has the fingerprint as the argument. Both
status lines are emitted for a good signature.
sig-timestamp is the signature creation time in seconds after
the epoch. expire-timestamp is the signature expiration time
in seconds after the epoch (zero means "does not expire").
SIG_ID <radix64_string> <sig_creation_date> <sig-timestamp>
This is emitted only for signatures of class 0 or 1 which
have been verified okay. The string is a signature id
and may be used in applications to detect replay attacks
of signed messages. Note that only DLP algorithms give
unique ids - others may yield duplicated ones when they
have been created in the same second.
ENC_TO <long keyid> <keytype> <keylength>
The message is encrypted to this keyid.
keytype is the numerical value of the public key algorithm,
keylength is the length of the key or 0 if it is not known
(which is currently always the case).
NODATA <what>
No data has been found. Codes for what are:
1 - No armored data.
2 - Expected a packet but did not found one.
3 - Invalid packet found, this may indicate a non OpenPGP message.
You may see more than one of these status lines.
UNEXPECTED <what>
Unexpected data has been encountered
0 - not further specified 1
TRUST_UNDEFINED <error token>
TRUST_NEVER <error token>
TRUST_MARGINAL
TRUST_FULLY
TRUST_ULTIMATE
For good signatures one of these status lines are emitted
to indicate how trustworthy the signature is. The error token
values are currently only emiited by gpgsm.
SIGEXPIRED
This is deprecated in favor of KEYEXPIRED.
KEYEXPIRED <expire-timestamp>
The key has expired. expire-timestamp is the expiration time
in seconds after the epoch.
KEYREVOKED
The used key has been revoked by its owner. No arguments yet.
BADARMOR
The ASCII armor is corrupted. No arguments yet.
RSA_OR_IDEA
The IDEA algorithms has been used in the data. A
program might want to fallback to another program to handle
the data if GnuPG failed. This status message used to be emitted
also for RSA but this has been dropped after the RSA patent expired.
However we can't change the name of the message.
SHM_INFO
SHM_GET
SHM_GET_BOOL
SHM_GET_HIDDEN
GET_BOOL
GET_LINE
GET_HIDDEN
GOT_IT
NEED_PASSPHRASE <long main keyid> <long keyid> <keytype> <keylength>
Issued whenever a passphrase is needed.
keytype is the numerical value of the public key algorithm
or 0 if this is not applicable, keylength is the length
of the key or 0 if it is not known (this is currently always the case).
NEED_PASSPHRASE_SYM <cipher_algo> <s2k_mode> <s2k_hash>
Issued whenever a passphrase for symmetric encryption is needed.
MISSING_PASSPHRASE
No passphrase was supplied. An application which encounters this
message may want to stop parsing immediately because the next message
will probably be a BAD_PASSPHRASE. However, if the application
is a wrapper around the key edit menu functionality it might not
make sense to stop parsing but simply ignoring the following
BAD_PASSPHRASE.
BAD_PASSPHRASE <long keyid>
The supplied passphrase was wrong or not given. In the latter case
you may have seen a MISSING_PASSPHRASE.
GOOD_PASSPHRASE
The supplied passphrase was good and the secret key material
is therefore usable.
DECRYPTION_FAILED
The symmetric decryption failed - one reason could be a wrong
passphrase for a symmetrical encrypted message.
DECRYPTION_OKAY
The decryption process succeeded. This means, that either the
correct secret key has been used or the correct passphrase
for a conventional encrypted message was given. The program
itself may return an errorcode because it may not be possible to
verify a signature for some reasons.
NO_PUBKEY <long keyid>
NO_SECKEY <long keyid>
The key is not available
IMPORTED <long keyid> <username>
The keyid and name of the signature just imported
IMPORT_OK <reason> [<fingerprint>]
The key with the primary key's FINGERPRINT has been imported.
Reason flags:
0 := Not actually changed
1 := Entirely new key.
2 := New user IDs
4 := New signatures
8 := New subkeys
16 := Contains private key.
The flags may be ORed.
IMPORT_PROBLEM <reason> [<fingerprint>]
Issued for each import failure. Reason codes are:
0 := "No specific reason given".
1 := "Invalid Certificate".
2 := "Issuer Certificate missing".
3 := "Certificate Chain too long".
4 := "Error storing certificate".
IMPORT_RES <count> <no_user_id> <imported> <imported_rsa> <unchanged>
<n_uids> <n_subk> <n_sigs> <n_revoc> <sec_read> <sec_imported> <sec_dups> <not_imported>
Final statistics on import process (this is one long line)
FILE_START <what> <filename>
Start processing a file <filename>. <what> indicates the performed
operation:
1 - verify
2 - encrypt
3 - decrypt
FILE_DONE
Marks the end of a file processing which has been started
by FILE_START.
BEGIN_DECRYPTION
END_DECRYPTION
Mark the start and end of the actual decryption process. These
are also emitted when in --list-only mode.
BEGIN_ENCRYPTION <mdc_method> <sym_algo>
END_ENCRYPTION
Mark the start and end of the actual encryption process.
DELETE_PROBLEM reason_code
Deleting a key failed. Reason codes are:
1 - No such key
2 - Must delete secret key first
3 - Ambigious specification
PROGRESS what char cur total
Used by the primegen and Public key functions to indicate progress.
"char" is the character displayed with no --status-fd enabled, with
the linefeed replaced by an 'X'. "cur" is the current amount
done and "total" is amount to be done; a "total" of 0 indicates that
the total amount is not known. 100/100 may be used to detect the
end of operation.
SIG_CREATED <type> <pubkey algo> <hash algo> <class> <timestamp> <key fpr>
A signature has been created using these parameters.
type: 'D' = detached
'C' = cleartext
'S' = standard
(only the first character should be checked)
class: 2 hex digits with the signature class
KEY_CREATED <type> <fingerprint>
A key has been created
type: 'B' = primary and subkey
'P' = primary
'S' = subkey
The fingerprint is one of the primary key for type B and P and
the one of the subkey for S.
SESSION_KEY <algo>:<hexdigits>
The session key used to decrypt the message. This message will
only be emmited when the special option --show-session-key
is used. The format is suitable to be passed to the option
--override-session-key
NOTATION_NAME <name>
NOTATION_DATA <string>
name and string are %XX escaped; the data may be splitted
among several notation_data lines.
USERID_HINT <long main keyid> <string>
Give a hint about the user ID for a certain keyID.
POLICY_URL <string>
string is %XX escaped
BEGIN_STREAM
END_STREAM
Issued by pipemode.
INV_RECP <reason> <requested_recipient>
Issued for each unusable recipient. The reasons codes
currently in use are:
0 := "No specific reason given".
1 := "Not Found"
2 := "Ambigious specification"
3 := "Wrong key usage"
4 := "Key revoked"
5 := "Key expired"
6 := "No CRL known"
7 := "CRL too old"
8 := "Policy mismatch"
9 := "Not a secret key"
10 := "Key not trusted"
Note that this status is also used for gpgsm's SIGNER command
where it relates to signer's of course.
NO_RECP <reserved>
Issued when no recipients are usable.
ALREADY_SIGNED <long-keyid>
Warning: This is experimental and might be removed at any time.
TRUNCATED <maxno>
The output was truncated to MAXNO items. This status code is issued
for certain external requests
ERROR <error location> <error code>
This is a generic error status message, it might be followed
by error location specific data. <error token> and
<error_location> should not contain a space.
ATTRIBUTE <fpr> <octets> <type> <index> <count>
<timestamp> <expiredate> <flags>
This is one long line issued for each attribute subpacket when
an attribute packet is seen during key listing. <fpr> is the
fingerprint of the key. <octets> is the length of the
attribute subpacket. <type> is the attribute type
(1==image). <index>/<count> indicates that this is the Nth
indexed subpacket of count total subpackets in this attribute
packet. <timestamp> and <expiredate> are from the
self-signature on the attribute packet. If the attribute
packet does not have a valid self-signature, then the
timestamp is 0. <flags> are a bitwise OR of:
0x01 = this attribute packet is a primary uid
0x02 = this attribute packet is revoked
0x04 = this attribute packet is expired
Key generation
==============
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.
This algorithm is based on Lim and Lee's suggestion from the
Crypto '97 proceedings p. 260.
Unattended key generation
=========================
This feature allows unattended generation of keys controlled by a
parameter file. To use this feature, you use --gen-key together with
--batch and feed the parameters either from stdin or from a file given
on the commandline.
The format of this file is as follows:
o Text only, line length is limited to about 1000 chars.
o You must use UTF-8 encoding to specify non-ascii characters.
o Empty lines are ignored.
o Leading and trailing spaces are ignored.
o A hash sign as the first non white space character indicates a comment line.
o Control statements are indicated by a leading percent sign, the
arguments are separated by white space from the keyword.
o Parameters are specified by a keyword, followed by a colon. Arguments
are separated by white space.
o The first parameter must be "Key-Type", control statements
may be placed anywhere.
o Key generation takes place when either the end of the parameter file
is reached, the next "Key-Type" parameter is encountered or at the
control statement "%commit"
o Control statements:
%echo <text>
Print <text>.
%dry-run
Suppress actual key generation (useful for syntax checking).
%commit
Perform the key generation. An implicit commit is done
at the next "Key-Type" parameter.
%pubring <filename>
%secring <filename>
Do not write the key to the default or commandline given
keyring but to <filename>. This must be given before the first
commit to take place, duplicate specification of the same filename
is ignored, the last filename before a commit is used.
The filename is used until a new filename is used (at commit points)
and all keys are written to that file. If a new filename is given,
this file is created (and overwrites an existing one).
Both control statements must be given.
o The order of the parameters does not matter except for "Key-Type"
which must be the first parameter. The parameters are only for the
generated keyblock and parameters from previous key generations are not
used. Some syntactically checks may be performed.
The currently defined parameters are:
Key-Type: <algo-number>|<algo-string>
Starts a new parameter block by giving the type of the
primary key. The algorithm must be capable of signing.
This is a required parameter.
Key-Length: <length-in-bits>
Length of the key in bits. Default is 1024.
Key-Usage: <usage-list>
Space or comma delimited list of key usage, allowed values are
"encrypt" and "sign". This is used to generate the key flags.
Please make sure that the algorithm is capable of this usage.
Subkey-Type: <algo-number>|<algo-string>
This generates a secondary key. Currently only one subkey
can be handled.
Subkey-Length: <length-in-bits>
Length of the subkey in bits. Default is 1024.
Subkey-Usage: <usage-list>
Similar to Key-Usage.
Passphrase: <string>
If you want to specify a passphrase for the secret key,
enter it here. Default is not to use any passphrase.
Name-Real: <string>
Name-Comment: <string>
Name-Email: <string>
The 3 parts of a key. Remember to use UTF-8 here.
If you don't give any of them, no user ID is created.
Expire-Date: <iso-date>|(<number>[d|w|m|y])
Set the expiration date for the key (and the subkey). It
may either be entered in ISO date format (2000-08-15) or as
number of days, weeks, month or years. Without a letter days
are assumed.
Preferences: <string>
Set the cipher, hash, and compression preference values for
this key. This expects the same type of string as "setpref"
in the --edit menu.
Revoker: <algo>:<fpr> [sensitive]
Add a designated revoker to the generated key. Algo is the
public key algorithm of the designated revoker (i.e. RSA=1,
DSA=17, etc.) Fpr is the fingerprint of the designated
revoker. The optional "sensitive" flag marks the designated
revoker as sensitive information. Only v4 keys may be
designated revokers.
Here is an example:
$ cat >foo <<EOF
%echo Generating a standard key
Key-Type: DSA
Key-Length: 1024
Subkey-Type: ELG-E
Subkey-Length: 1024
Name-Real: Joe Tester
Name-Comment: with stupid passphrase
Name-Email: joe@foo.bar
Expire-Date: 0
Passphrase: abc
%pubring foo.pub
%secring foo.sec
# Do a commit here, so that we can later print "done" :-)
%commit
%echo done
EOF
$ gpg --batch --gen-key foo
[...]
$ gpg --no-default-keyring --secret-keyring ./foo.sec \
--keyring ./foo.pub --list-secret-keys
/home/wk/work/gnupg-stable/scratch/foo.sec
------------------------------------------
sec 1024D/915A878D 2000-03-09 Joe Tester (with stupid passphrase) <joe@foo.bar>
ssb 1024g/8F70E2C0 2000-03-09
Layout of the TrustDB
=====================
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.
FIXME: The layout changed, document it here.
Record type 0:
--------------
Unused record, can be reused for any purpose.
Record type 1:
--------------
Version information for this TrustDB. This is always the first
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 (2)
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.
1 u32 locked flags
1 u32 timestamp of trustdb creation
1 u32 timestamp of last modification which may affect the validity
of keys in the trustdb. This value is checked against the
validity timestamp in the dir records.
1 u32 timestamp of last validation
(Used to keep track of the time, when this TrustDB was checked
against the pubring)
1 u32 record number of keyhashtable
1 u32 first free record
1 u32 record number of shadow directory hash table
It does not make sense to combine this table with the key table
because the keyid is not in every case a part of the fingerprint.
1 u32 record number of the trusthashtbale
Record type 2: (directory record)
--------------
Informations about a public key certificate.
These are static values which are never changed without user interaction.
1 byte value 2
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
1 u32 cache record
1 byte ownertrust
1 byte dirflag
1 byte maximum validity of all the user ids
1 u32 time of last validity check.
1 u32 Must check when this time has been reached.
(0 = no check required)
Record type 3: (key record)
--------------
Informations about a primary public key.
(This is mainly used to lookup a trust record)
1 byte value 3
1 byte reserved
1 u32 LID
1 u32 next - next key record
7 bytes reserved
1 byte keyflags
1 byte pubkey algorithm
1 byte length of the fingerprint (in bytes)
20 bytes fingerprint of the public key
(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
1 byte uidflags
1 byte validity of the key calculated over this user id
20 bytes ripemd160 hash of the username.
Record type 5: (pref record)
--------------
This record type is not anymore used.
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
30 byte preference data
Record type 6 (sigrec)
-------------
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).
1 byte value 6
1 byte reserved
1 u32 LID points back to the dir record
1 u32 next next sigrec of this uid or 0 to indicate the
last sigrec.
6 times
1 u32 Local_id of signatures 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 may be revoked)
Record type 8: (shadow directory record)
--------------
This record is used to reserve 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
Record Type 10 (hash table)
--------------
Due to the fact that we use fingerprints to lookup keys, we can
implement quick access by some simple hash methods, and avoid
the overhead of gdbm. A property of fingerprints 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 lists.
This record is a hashtable of 256 entries; a special property
is that all these records are stored consecutively to make one
big table. The hash value is simple the 1st, 2nd, ... byte of
the fingerprint (depending on the indirection level).
When used to hash shadow directory records, a different table is used
and indexed by the keyid.
1 byte value 10
1 byte reserved
n u32 recnum; n depends on the record length:
n = (reclen-2)/4 which yields 9 for the current record length
of 40 bytes.
the total number of such record which makes up the table is:
m = (256+n-1) / n
which is 29 for a record length of 40.
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
to index this hash table and so on.
- 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;
Record type 11 (hash list)
--------------
see hash table for an explanation.
This is also used for other purposes.
1 byte value 11
1 byte reserved
1 u32 next next hash list record
n times n = (reclen-5)/5
1 u32 recnum
For the current record length of 40, n is 7
Record type 254 (free record)
---------------
All these records form a linked list of unused records.
1 byte value 254
1 byte reserved (0)
1 u32 next_free
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:
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.
+ This is a simple 2 byte field (MSB first) containing the amount of data
+ 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
+ future extensions. These length markers must be inserted into the data
+ stream just before writing the data out.
+
+ This 2 byte field 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.
GNU extensions to the S2K algorithm
===================================
S2K mode 101 is used to identify these extensions.
After the hash algorithm the 3 bytes "GNU" are used to make
clear that these are extensions for GNU, the next bytes gives the
GNU protection mode - 1000. Defined modes are:
1001 - do not store the secret part at all
Usage of gdbm files for keyrings
================================
The key to store the keyblock is its fingerprint, other records
are used for secondary keys. Fingerprints are always 20 bytes
where 16 bit fingerprints are appended with zero.
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?)
Pipemode
========
This mode can be used to perform multiple operations with one call to
gpg. It comes handy in cases where you have to verify a lot of
signatures. Currently we support only detached signatures. This mode
is a kludge to avoid running gpg n daemon mode and using Unix Domain
Sockets to pass the data to it. There is no easy portable way to do
this under Windows, so we use plain old pipes which do work well under
Windows. Because there is no way to signal multiple EOFs in a pipe we
have to embed control commands in the data stream: We distinguish
between a data state and a control state. Initially the system is in
data state but it won't accept any data. Instead it waits for
transition to control state which is done by sending a single '@'
character. While in control state the control command os expected and
this command is just a single byte after which the system falls back
to data state (but does not necesary accept data now). The simplest
control command is a '@' which just inserts this character into the
data stream.
Here is the format we use for detached signatures:
"@<" - Begin of new stream
"@B" - Detached signature follows.
This emits a control packet (1,'B')
<detached_signature>
"@t" - Signed text follows.
This emits the control packet (2, 'B')
<signed_text>
"@." - End of operation. The final control packet forces signature
verification
"@>" - End of stream
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.
Keyserver Message Format
=========================
The keyserver may be contacted by a Unix Domain socket or via TCP.
The format of a request is:
====
command-tag
"Content-length:" digits
CRLF
=======
Where command-tag is
NOOP
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
Documentation on HKP (the http keyserver protocol):
A minimalistic HTTP server on port 11371 recognizes a GET for /pks/lookup.
The standard http URL encoded query parameters are this (always key=value):
- op=index (like pgp -kv), op=vindex (like pgp -kvv) and op=get (like
pgp -kxa)
- search=<stringlist>. This is a list of words that must occur in the key.
The words are delimited with space, points, @ and so on. The delimiters
are not searched for and the order of the words doesn't matter (but see
next option).
- exact=on. This switch tells the hkp server to only report exact matching
keys back. In this case the order and the "delimiters" are important.
- fingerprint=on. Also reports the fingerprints when used with 'index' or
'vindex'
The keyserver also recognizes http-POSTs to /pks/add. Use this to upload
keys.
A better way to do this would be a request like:
/pks/lookup/<gnupg_formatierte_user_id>?op=<operation>
This can be implemented using Hurd's translator mechanism.
However, I think the whole key server stuff has to be re-thought;
I have some ideas and probably create a white paper.

301
doc/HACKING
View file

@ -1,301 +0,0 @@
A Hacker's Guide to GNUPG
================================
(Some notes on GNUPG internals.)
===> Under construction <=======
CVS Access
==========
Anonymous read-only CVS access is available:
cvs -z3 -d :pserver:anoncvs@cvs.gnupg.org:/cvs/gnupg login
use the password "anoncvs". To check out the the complete
archive use:
cvs -z3 -d :pserver:anoncvs@cvs.gnupg.org:/cvs/gnupg \
checkout -R STABLE-BRANCH-1-0 gnupg
This service is provided to help you in hunting bugs and not to deliver
stable snapshots; it may happen that it even does not compile, so please
don't complain. CVS may put a high load on a server, so please don't poll
poll for new updates but wait for an announcement; to receive this you may
want to subscribe to:
gnupg-commit-watchers@gnupg.org
by sending a mail with subject "subscribe" to
gnupg-commit-watchers-request@gnupg.org
You must run scripts/autogen.sh before doing the ./configure,
as this creates some needed while which are not in the CVS.
autogen.sh should checks that you have all required tools
installed.
RSYNC access
============
The FTP archive is also available by anonymous rsync. A daily snapshot
of the CVS head revision is also available. See rsync(1) and try
"rsync ftp.gnupg.org::" to see available resources.
Special Tools
=============
Documentation is based on the docbook DTD. Actually we have only the
man page for now. To build a man page you need the docbook-to-man
tool and all the other thinks needed for SGML processing. Debian
comes with the docbook tools and you only need this docbook-to-man
script which is comes with gtk-doc or download it from
ftp.openit.de:/pub/devel/sgml. If you don't have it everything
should still work fine but you will have only a dummy man page.
RFCs
====
1423 Privacy Enhancement for Internet Electronic Mail:
Part III: Algorithms, Modes, and Identifiers.
1489 Registration of a Cyrillic Character Set.
1750 Randomness Recommendations for Security.
1991 PGP Message Exchange Formats.
2015 MIME Security with Pretty Good Privacy (PGP).
2144 The CAST-128 Encryption Algorithm.
2279 UTF-8, a transformation format of ISO 10646.
2440 OpenPGP.
Debug Flags
-----------
Use the option "--debug n" to output debug information. This option
can be used multiple times, all values are ORed; n maybe prefixed with
0x to use hex-values.
value used for
----- ----------------------------------------------
1 packet reading/writing
2 MPI details
4 ciphers and primes (may reveal sensitive data)
8 iobuf filter functions
16 iobuf stuff
32 memory allocation stuff
64 caching
128 show memory statistics at exit
256 trust verification stuff
Directory Layout
----------------
./ Readme, configure
./scripts Scripts needed by configure and others
./doc Documentation
./util General purpose utility function
./mpi Multi precision integer library
./cipher Cryptographic functions
./g10 GnuPG application
./tools Some helper and demo programs
./keybox The keybox library (under construction)
./gcrypt Stuff needed to build libgcrypt (under construction)
Detailed Roadmap
----------------
g10/g10.c Main module with option parsing and all the stuff you have
to do on startup. Also has the exout handler and some
helper functions.
g10/sign.c Create signature and optionally encrypt
g10/parse-packet.c
g10/build-packet.c
g10/free-packet.c
Parsing and creating of OpenPGP message packets.
g10/getkey.c Key selection code
g10/pkclist.c Build a list of public keys
g10/skclist.c Build a list of secret keys
g10/ringedit.c Keyring I/O
g10/keydb.h
g10/keyid.c Helper functions to get the keyid, fingerprint etc.
g10/trustdb.c
g10/trustdb.h
g10/tdbdump.c
Management of the trustdb.gpg
g10/compress.c Filter to handle compression
g10/filter.h Declarations for all filter functions
g10/delkey.c Delete a key
g10/kbnode.c Helper for the KBNODE linked list
g10/main.h Prototypes and some constants
g10/mainproc.c Message processing
g10/armor.c Ascii armor filter
g10/mdfilter.c Filter to calculate hashs
g10/textfilter.c Filter to handle CR/LF and trailing white space
g10/cipher.c En-/Decryption filter
g10/misc.c Utlity functions
g10/options.h Structure with all the command line options
and related constants
g10/openfile.c Create/Open Files
g10/tdbio.c I/O handling for the trustdb.gpg
g10/tdbio.h
g10/hkp.h Keyserver access
g10/hkp.c
g10/packet.h Defintion of OpenPGP structures.
g10/passphrase.c Passphrase handling code
g10/pubkey-enc.c
g10/seckey-cert.c
g10/seskey.c
g10/import.c
g10/export.c
g10/comment.c
g10/status.c
g10/status.h
g10/sign.c
g10/plaintext.c
g10/encr-data.c
g10/encode.c
g10/revoke.c
g10/keylist.c
g10/sig-check.c
g10/signal.c
g10/helptext.c
g10/verify.c
g10/decrypt.c
g10/keyedit.c
g10/dearmor.c
g10/keygen.c
Memory allocation
-----------------
Use only the functions:
m_alloc()
m_alloc_clear()
m_strdup()
m_free()
If you want to store a passphrase or some other sensitive data you may
want to use m_alloc_secure() instead of m_alloc(), as this puts the data
into a memory region which is protected from swapping (on some platforms).
m_free() works for both. This functions will not return if there is not
enough memory available.
Logging
-------
Option parsing
---------------
GNUPG does not use getopt or GNU getopt but functions of it's own. See
util/argparse.c for details. The advantage of these functions is that
it is more easy to display and maintain the help texts for the options.
The same option table is also used to parse resource files.
What is an IOBUF
----------------
This is the data structure used for most I/O of gnupg. It is similar
to System V Streams but much simpler. Because OpenPGP messages are nested
in different ways; the use of such a system has big advantages. Here is
an example, how it works: If the parser sees a packet header with a partial
length, it pushes the block_filter onto the IOBUF to handle these partial
length packets: from now on you don't have to worry about this. When it sees
a compressed packet it pushes the uncompress filter and the next read byte
is one which has already been uncompressed by this filter. Same goes for
enciphered packet, plaintext packets and so on. The file g10/encode.c
might be a good staring point to see how it is used - actually this is
the other way: constructing messages using pushed filters but it may be
easier to understand.
How to use the message digest functions
---------------------------------------
cipher/md.c implements an interface to hash (message digest functions).
a) If you have a common part of data and some variable parts
and you need to hash of the concatenated parts, you can use this:
md = md_open(...)
md_write( md, common_part )
md1 = md_copy( md )
md_write(md1, part1)
md_final(md1);
digest1 = md_read(md1)
md2 = md_copy( md )
md_write(md2, part2)
md_final(md2);
digest2 = md_read(md2)
An example are key signatures; the key packet is the common part
and the user-id packets are the variable parts.
b) If you need a running digest you should use this:
md = md_open(...)
md_write( md, part1 )
digest_of_part1 = md_digest( md );
md_write( md, part2 )
digest_of_part1_cat_part2 = md_digest( md );
....
Both methods may be combined. [Please see the source for the real syntax]
How to use the cipher functions
-------------------------------
cipher/cipher.c implements the interface to symmetric encryption functions.
As usual you have a function to open a cipher (which returns a handle to be used
with all other functions), some functions to set the key and other stuff and
a encrypt and decrypt function which does the real work. You probably know
how to work with files - so it should really be easy to work with these
functions. Here is an example:
CIPHER_HANDLE hd;
hd = cipher_open( CIPHER_ALGO_TWOFISH, CIPHER_MODE_CFB, 0 );
if( !hd )
oops( use other function to check for the real error );
rc = cipher_setkey( hd, key256bit, 32 ) )
if( rc )
oops( weak key or something like this );
cipher_setiv( hd, some_IV_or_NULL_for_all_zeroes );
cipher_encrypt( hd, plain, cipher, size );
cipher_close( hd );
How to use the public key functions
-----------------------------------
cipher/pubkey.c implements the interface to asymmetric encryption and
signature functions. This is basically the same as with the symmetric
counterparts, but due to their nature it is a little bit more complicated.
[Give an example]

108
doc/OpenPGP
View file

@ -1,108 +0,0 @@
GnuPG and OpenPGP
=================
See RFC2440 for a description of OpenPGP. We have an annotated version
of this RFC online: http://www.gnupg.org/rfc2440.html
Compatibility Notes
===================
GnuPG (>=1.0.3) is in compliance with RFC2440 despite these exceptions:
* (9.2) states that IDEA SHOULD be implemented. This is not done
due to patent problems.
All MAY features are implemented with this exception:
* multi-part armored messages are not supported.
MIME (rfc2015) should be used instead.
Most of the OPTIONAL stuff is implemented.
There are a couple of options which can be used to override some
RFC requirements. This is always mentioned with the description
of that options.
A special format of partial packet length exists for v3 packets
which can be considered to be in compliance with RFC1991; this
format is only created if a special option is active.
GnuPG uses a S2K mode of 101 for GNU extensions to the secret key
protection algorithms. This number is not defined in OpenPGP, but
given the fact that this number is in a range which used at many
other places in OpenPGP for private/experimenat algorithm identifiers,
this should be not a so bad choice. The 3 bytes "GNU" are used
to identify this as a GNU extension - see the file DETAILS for a
definition of the used data formats.
Some Notes on OpenPGP / PGP Compatibility:
==========================================
* PGP 5.x does not accept V4 signatures for anything other than
key material. The GnuPG option --force-v3-sigs mimics this
behavior.
* PGP 5.x does not recognize the "five-octet" lengths in
new-format headers or in signature subpacket lengths.
* PGP 5.0 rejects an encrypted session key if the keylength
differs from the S2K symmetric algorithm. This is a bug in its
validation function.
* PGP 5.0 does not handle multiple one-pass signature headers and
trailers. Signing one will compress the one-pass signed literal
and prefix a V3 signature instead of doing a nested one-pass
signature.
* When exporting a private key, PGP 2.x generates the header
"BEGIN PGP SECRET KEY BLOCK" instead of "BEGIN PGP PRIVATE KEY
BLOCK". All previous versions ignore the implied data type, and
look directly at the packet data type.
* In a clear-signed signature, PGP 5.0 will figure out the correct
hash algorithm if there is no "Hash:" header, but it will reject
a mismatch between the header and the actual algorithm used. The
"standard" (i.e. Zimmermann/Finney/et al.) version of PGP 2.x
rejects the "Hash:" header and assumes MD5. There are a number
of enhanced variants of PGP 2.6.x that have been modified for
SHA-1 signatures.
* PGP 5.0 can read an RSA key in V4 format, but can only recognize
it with a V3 keyid, and can properly use only a V3 format RSA
key.
* Neither PGP 5.x nor PGP 6.0 recognize ElGamal Encrypt and Sign
keys. They only handle ElGamal Encrypt-only keys.
Parts of this document are taken from:
======================================
OpenPGP Message Format
draft-ietf-openpgp-formats-07.txt
Copyright 1998 by The Internet Society. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

100
doc/README.W32
View file

@ -1,100 +0,0 @@
This is a binary version of GnuPG for MS-Windows 95, 98, WNT and W2000.
A FAQ comes with this package and a probably more recent one can be
found online at http://www.gnupg.org/faq.html. See
http://www.gnupg.org/docs-mls.html for a list of mailing lists. In
particular the list gnupg-users@gnupg.org might be useful to answer
questions - but please read the FAQ first.
Installation instructions:
--------------------------
1. Unpack the ZIP archive (alright, you already did this).
2. Copy "gpg.exe" and "gpgv.exe" to some place where you
usually store your binaries.
3. Create a directory "c:\gnupg" (or any other as you like)
4. If you did not use the default directory "c:\gnupg", you
should enter a string with the directory into the Registry
under the key:
HKEY_CURRENT_USER -> Software -> GNU -> GnuPG
(you probably need to create the keys GNU and GnuPG) and insert a
new string under the name "HomeDir" with the value of the default
directory you want to use. Please use forward slashes and not the
backslashes when setting filenames for GnuPG into the Registry.
5. Enter "gpg" and see what happens
6. Read the file README and the online HOWTOs
Internationalization support:
-----------------------------
1. Decide where to store the translation files for your language.
Here we assume the directory "c:/gnu/locale/fr"
2. Set the directory with the translations into the Registry under
the key:
HKEY_CURRENT_USER -> Control Panel -> Mingw32 -> NLS
(you probably need to create the keys Mingw32 and NLS) using a string
entry with the name "MoDir".
3. Select which language to use and copy the currect translation file
under the name "gnupg.mo" into the directory set in step 2
(Example: "copy fr.mo c:\gnu\locale\fr\gnupg.mo")
4. Done.
Currently we only support the Codepages 437, 850 und Latin1. If you have
problems, either delete the gnupg.mo file or don't set the environment
variable
How to build it from the source:
--------------------------------
This version has been build with the Mingw32/CPD kit using the latest
stable version of GnuPG.
First get the source: It has to be available at the same location you
found this binary package - if not you should have received a written
offer to get the source delivered to you See the file COPYING (section
3) for details.
If you got this package from its canonical place (ftp.gnupg.org), the
source is available at:
ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.2.n.tar.gz
or for development snapshots
ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.x.n.tar.gz
this is the same source as for the Unix version. If your binary
version of GnuPG is called something like gnupg-w32-1.0.4-1.zip, you
should find a patch file named gnupg-w32-1.0.4-1.0.4-1.diff.gz at the
same location, which has to be applied to the stock gpg source file.
Instructions are at the top of this file.
To build it, you need the MingW32/CPD kit, which is available at
ftp://ftp.gnupg.org/people/werner/cpd/mingw32-cpd-0.3.0.tar.gz
ftp://ftp.gnupg.org/people/werner/cpd/gcc-core-2.95.2.tar.gz
ftp://ftp.gnupg.org/people/werner/cpd/binutils-2.9.1.tar.gz
gcc and binutils are stock GNU source which are available
at every GNU mirror.
After you have installed this environment you should be able to do this:
$ scripts/autogen.sh --build-w32
$ make
$ mingw32 strip g10/gpg.exe
$ cp g10/gpg.exe /some_windows_drive/
And everything hopefully works.
Don't forget that MS-Windows ist just a temporary workaround until
you can switch to a GNU system ;-)
Be the source always with you.
Werner

41
doc/credits-1.0
View file

@ -1,41 +0,0 @@
The GNU Privacy Guard has been created by the GnuPG team:
Matthew Skala, Michael Roth, Niklas Hernaeus, Rémi Guyomarch
and Werner Koch. Gael Queri, Gregory Steuck, Janusz A. Urbanowicz,
Marco d'Itri, Thiago Jung Bauermann, Urko Lusa and Walter Koch
did the official translations. Mike Ashley is working on the
GNU Privacy Handbook.
The following people helped greatly by suggesting improvements,
testing, fixing bugs, providing resources and doing other important
tasks: Allan Clark, Anand Kumria, Ariel T Glenn, Bodo Moeller,
Bryan Fullerton, Brian Moore, Brian Warner, Caskey L. Dickson,
Cees van de Griend, Charles Levert, Christian von Roques,
Christopher Oliver, Christian Recktenwald, Daniel Eisenbud,
Daniel Koenig, David Ellement, Detlef Lannert, Dirk Lattermann,
Ed Boraas, Enzo Michelangeli, Ernst Molitor, Fabio Coatti,
Felix von Leitner, Frank Heckenbach, Frank Stajano, Gaël Quéri,
Greg Louis, Greg Troxel, Gregory Steuck, Geoff Keating, Harald Denker,
Hendrik Buschkamp, Holger Schurig, Hugh Daniel, Ian McKellar,
Janusz A. Urbanowicz, James Troup, Jean-loup Gailly, Jens Bachem,
Joachim Backes, John A. Martin, Johnny Teveßen, Jörg Schilling,
Jun Kuriyama, Karl Fogel, Karsten Thygesen, Katsuhiro Kondou,
Kazu Yamamoto, Lars Kellogg-Stedman, Marco d'Itri, Mark Adler,
Mark Elbrecht, Markus Friedl, Martin Kahlert, Martin Hamilton,
Martin Schulte, Matthew Skala, Max Valianskiy, Michael Roth,
Michael Sobolev, Nicolas Graner, NIIBE Yutaka, Niklas Hernaeus,
Nimrod Zimerman, N J Doye, Oliver Haakert, Oskari Jääskeläinen,
Paul D. Smith, Philippe Laliberte, Peter Gutmann, QingLong,
Ralph Gillen, Rat, Reinhard Wobst, Rémi Guyomarch, Reuben Sumner,
Roland Rosenfeld, Ross Golder, Serge Munhoven, SL Baur, Stefan Karrmann,
Stefan Keller, Steffen Ullrich, Steffen Zahn, Steven Bakker,
Susanne Schultz, Thiago Jung Bauermann, Thomas Roessler, Tom Spindler,
Tom Zerucha, Tomas Fasth, Thomas Mikkelsen, Ulf Möller, Urko Lusa,
Walter Koch, Wim Vandeputte and Gerlinde Klaes.
This software has been made possible by the previous work of
Chris Wedgwood, Jean-loup Gailly, Jon Callas, Mark Adler, Martin Hellmann
Paul Kendall, Philip R. Zimmermann, Peter Gutmann, Philip A. Nelson,
Taher ElGamal, Torbjorn Granlund, Whitfield Diffie, some unknown NSA
mathematicians and all the folks who have worked hard to create complete
and free operating systems.

1019
doc/faq.raw
View file

File diff suppressed because it is too large Load diff

17
doc/fr/ChangeLog
View file

@ -1,17 +0,0 @@
2001-09-10 Gilbert Fernandes <gilbertf@posse-press.com>
* Traduction en français des documents doc/*
Copyright 2001 Free Software Foundation, Inc.
Ce fichier est un logiciel libre ; l'auteur vous donne une autorisation
spéciale de copies illimitées et/ou distribution illimitée avec ou sans
modifications attendu que cette notice de copyright et note associée
se trouve conservée dans le document.
This file is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY, to the extent permitted by law; without even the
implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

945
doc/fr/DETAILS
View file

@ -1,945 +0,0 @@
Format des listings "---with-colons"
====================================
sec::1024:17:6C7EE1B8621CC013:1998-07-07:0:::Werner Koch <werner.koch@guug.de>:
ssb::1536:20:5CE086B5B5A18FF4:1998-07-07:0:::
1. Champ: Type d'enregistrement
pub = clef publique
sub = sous-clef (clef secondaire)
sec = clef secrète
ssb = sous-clef secrète (clef secondaire)
uid = id d'utilisateur (seul le champ 10 est utilisé)
sig = signature
fpr = fingerprint: (le champ 10 est le fingerprint)
pkd = données publiques de la clef
(champ au format spécial, voir ci-dessous)
2. Champ: Une lettre décrivant la confiance calculée. Ce n'est qu'une
seule lettre, mais elle fera peut-être l'objet d'une information
supplémentaire pour les versions futures, comme décrit ici
(ceci ne sera pas utilisé pour les clefs privées)
o = Inconnu (cette clef est nouvelle au système)
i = La clef est invalide (eg. il manque sa propre signature)
d = La clef a été désactivée
r = La clef a été révoquée
e = La clef a expiré
q = Non-défini (pas de valeur attribuée)
n = Ne jamais faire confiance à cette clef
m = Cette clef dispose d'une confiance marginale
f = Cette clef dispose d'une confiance totale
u = Cette clef dispose d'une confiance ultime. Cette valeur
n'est utilisée que pour les clefs où la clef secrète est
également disponibles.
3. Champ: taille de la clef en bits.
4. Champ: Algorithme utilisé: 1 = RSA
16 = ElGamal (chiffrement uniquement)
17 = DSA (parfois appellé DH, signature seulement)
20 = ElGamal (signe et chiffre)
(pour d'autres is, consultez include/cipher.h)
5. Champ: ID de clef (KeyID)
6. Champ: Date de création (en UTC)
7. Champ: Date d'expiration de la clef, vide si aucune.
8. Champ: ID local : numéro d'enregistrement du répertoire dans la
trustdb. Cette valeur n'est valide que tant que la
trustdb n'est pas effacée. Vous pouvez utiliser
"#<local-id>" comme id d'utilisateur lorsque vous spécifiez
la clef. Ceci est requis puisque les id de clef ne sont pas
toujours uniques - un programme peut donc utiliser ce numéro
pour accéder aux clefs ultérieurement.
9. Champ: Confiance propre (clef publiques primaires uniquement)
C'est une simple lettre, mais une information supplémentaire pourrait
se voir ajoutée dans les versions futures.
10. Champ: ID utilisateur. La valeur est placée entre guillemets comme une
chaîne en C, par exemple : "\x3a".
11. Champ: Classe de signature. C'est un nombre hexadécimal à deux chiffres
suivi par la lettre "x" si la signature peut être exportée ou la
lettre "l" si la signature est uniquement locale.
12. Champ: Capacités de la clef :
e = chiffrement
s = signature
c = certification
Une clef peut disposer de toute combinaison de ces caractéristiques.
La clef primaire dispose, en plus de ces lettres, une version en
majuscule des lettres pour marquer les capacités "d'utilisation"
de la totalité de la clef.
Toutes les dates sont affichées dans le format :
yyyy-mm-dd
Sauf si vous utilisez l'option --fixed-list-mode où dans ce cas précis les
dates sont affichées en secondes depuis Epoch. Plus de champs feront l'objet
d'additions dans les futures versions et les parsers doivent y être préparés.
Lorsque le parser traitera ces données, il devra s'arrêter au premier
caractère non-numérique afin que des informations supplémentaires soient
ajoutées à l'avenir.
Le champ 1 dispose d'un tag "pkd" dont le listing ressemble à ceci :
pkd:0:1024:B665B1435F4C2 .... FF26ABB:
! ! !-- la valeur
! !------ indicateur du nombre de bits de la valeur
!--------- index (eg. DSA va de 0 à 3 : p,q,g,y)
Format de la sortie "--status-fd"
=================================
Chaque ligne dispose d'un préfixe :
"[GNUPG:] "
Suivie par un mot clef indiquant le type de la ligne de statut,
et quelques arguments selon le type (probablement aucun) ; une application
devrait toujours assumer que des arguments supplémentaires seront
présents dans les versions futures.
GOODSIG <long keyid> <username>
La signature keyid est valide.
Pour chaque signature seul l'un des trois codes GOODSIG, BADSIG ou
ERRSIG seront produits et ils pourront être utilisés comme
marqueurs pour les nouvelles signatures.
BADSIG <long keyid> <username>
La signature keyid n'a pas été vérifiée correctement.
ERRSIG <long keyid> <pubkey_algo> <hash_algo> \
<sig_class> <timestamp> <rc>
Il n'a pas été possible de vérifier la signature. Ceci peut provenir
d'une clef publique manquante, ou bien à cause d'un algorithme non-
supporté. Un RC de 4 indique un algorithme inconnu, un 9 indique
une clef publique manquante. Les autres champs donnent plus d'information
sur la signature. sig_class est une valeur hexadécimale de 2 octets.
VALIDSIG <fingerprint in hex> <sig_creation_date> <sig-timestamp>
La signature keyid est valide. C'est ici la même chose que GOODSIG
mais avec le fingerprint comme argument. Les lignes de statut seront
émises pour une bonne signature.
sig-timestamp est la date de création de la signature en secondes
depuis Epoch.
SIG_ID <radix64_string> <sig_creation_date> <sig-timestamp>
N'est émis que pour les signatures de classe 0 ou 1 qui ont été
vérifiées comme valides. Le chaîne est un identifiant d'utilisateur
et peut être utilisée dans les applications pour détecter les
attaques par rejeu de messages signés. Notez que seuls les
algorithmes DLP offrent des identifiants uniques ; les autres peuvent
produire des id dupliqués lorsqu'ils furent créés à la même seconde.
ENC_TO <long keyid> <keytype> <keylength>
Le message est chiffré avec ce keyid.
keytype est une valeur numérique de l'algorithme à clef publique,
keylength est la taille de la clef ou 0 si elle n'est pas connue
(ce qui est toujours le cas).
NODATA <what>
Aucune donnée n'a été trouvée. Les codes suivants sont utilisés :
1 - Pas de données sous ARMOR.
2 - Un paquet attendu n'a pas été trouvé.
3 - Paquet invalide trouvé ; ceci peut indiquer un message
non-OpenPGP. Vous devez vous attendre à une extension
de ces lignes de statu à l'avenir.
UNEXPECTED <what>
Des données innatendues ont été rencontrées
0 - pas de détail supplémentaire
TRUST_UNDEFINED
TRUST_NEVER
TRUST_MARGINAL
TRUST_FULLY
TRUST_ULTIMATE
Pour les signatures valides, l'une de ces lignes de statut sera produite
pour indiquer le niveau de confiance attribué à la clef. Pas d'arguments
pour l'instant.
SIGEXPIRED
La clef de signature a expiré. Pas d'arguments pour l'instant.
KEYREVOKED
L'utilisateur a révoqué sa clef. Pas d'arguments pour l'instant.
BADARMOR
L'ARMOR ASCII est corrompu. Pas d'arguments pour l'instant.
RSA_OR_IDEA
Les algorithmes IDEA ont été utilisés sur les données. Un programme
pourra basculer sur un autre programme de traitement si GnuPG échoue.
Ce message de statut sera affiché pour le RSA aussi, mais ceci a été
abandonné puisque le brevêt sur le RSA a expiré.
Toutefois, nous ne pouvons modifier le nom du message.
SHM_INFO
SHM_GET
SHM_GET_BOOL
SHM_GET_HIDDEN
GET_BOOL
GET_LINE
GET_HIDDEN
GOT_IT
NEED_PASSPHRASE <long main keyid> <long keyid> <keytype> <keylength>
Sera affiché à chaque fois qu'une phrase passe sera requise.
keytype est la valeur numérique de l'algorithme à clef publique
ou bien 0 si cela n'est pas applicable. keylength est la taille de la
clef ou 0 si la taille n'est pas connue (ceci est actuellement
toujours le cas).
NEED_PASSPHRASE_SYM <cipher_algo> <s2k_mode> <s2k_hash>
Affiché à chaque fois qu'une phrase passe pour un chiffrement
symétrique sera requise.
MISSING_PASSPHRASE
Aucune phrase passe n'a été fournie. Une application qui rencontre
ce message devrait stopper immédiatement le parsing car le prochain
message sera probablement BAD_PASSPHRASE. Toutefois, si l'application
n'est qu'un wrapper autour de la fonctionnalité d'édition de clefs,
ceci pourrait avoir un autre sens et stopper le parsing pourrait
être incorrect, et il faudra ignorer le BAD_PASSPHRASE.
BAD_PASSPHRASE <long keyid>
La phrase passe fournie est soit invalide, soit n'a pas été fournie.
Dans le seconde cas vous devriez voir un MISSING_PASSPHRASE.
GOOD_PASSPHRASE
La phrase passe fournie est valide et le matériel de clefs secrète
est utilisable.
DECRYPTION_FAILED
La déchiffrement symétrique a échoué. Il s'agit généralement d'une
mauvaise phrase passe ne correspondant pas au message chiffré.
DECRYPTION_OKAY
Succès du déchiffrement. Ceci signifie que soit la clef secrète
adaptée a été utilisée avec succès, soit que la phrase passe
valide pour un chiffrement symétrique aura conduit au déchiffrement.
Le programme pourait toutefois renvoyer un message d'erreur s'il
n'a pas été possible de vérifier la signature.
NO_PUBKEY <long keyid>
NO_SECKEY <long keyid>
La clef n'est pas utilisable.
IMPORTED <long keyid> <username>
Le keyid et la signature ont été importés.
IMPORTED_RES <count> <no_user_id> <imported> <imported_rsa> <unchanged>
<n_uids> <n_subk> <n_sigs> <n_revoc> <sec_read> <sec_imported> <sec_dups>
Statistiques finales sur le processus d'importation (cette ligne est longue!)
FILE_START <what> <filename>
Début de traitement du fichier <filename>. <what> indique l'opération
réalisée :
1 - vérifier
FILE_DONE
Marque la fin de traitement d'un fichier, ayant débuté avec FILE_START.
BEGIN_DECRYPTION
END_DECRYPTION
Marque le début et la fin du processus de déchiffrement. Ces messages
seront également produits lors de l'utilisation du mode --list-only.
BEGIN_ENCRYPTION
END_ENCRYPTION
Marque le début et la fin du processus de chiffrement.
DELETE_PROBLEM reason_code
L'effacement d'une clef a échoué. Un code indique la raison de l'erreur :
1 - La clef spécifiée n'existe pas
2 - La clef privée doit être détruite avant !
PROGRESS what char cur total
Utilisé par les fonctions primegen et de clef publique pour indiquer
la progression de l'opération. "char" est le caractère affiché sans
--status-fd avec les retours à la ligne marqués par "X". "cur" indique
la quantitité de traitement terminée et "total" indique la valeur
finale à atteindre. Un total de 0 indique que le total n'est pas
connu. 100/100 peut être utilisé pour détecter la fin de l'opération.
SIG_CREATED <type> <pubkey algo> <hash algo> <class> <timestamp> <key fpr>
Une signature a été créée à l'aide de ces paramètres.
type: 'D' = détachée
'C' = en texte clair
'S' = standard
(seul le premier caractère doit être vérifié)
class: 2 chiffres hexadécimaux avec la classe de signature
KEY_CREATED <type>
Une clef a été créée
type: 'B' = primaire et sous-clef
'P' = primaire
'S' = sous-clef
SESSION_KEY <algo>:<hexdigits>
La clef de session utilisée pour déchiffrer le message. Ce message
sera seulement affiché si l'option --show-session est utilisée.
Le format est utilisable pour un passage direct à la fonction
--override-session-key.
NOTATION_NAME <name>
NOTATION_DATA <string>
Le nom et la chaîne sont "escaped" à l'aide de %XX et les données
peuvent être découpées sur plusieurs lignes notation_data.
USERID_HINT <long main keyid> <string>
Donne un indice sur l'ID utilisateur pour un keyID donné.
POLICY_URL <string>
La chaîne est "escaped" en %XX
BEGIN_STREAM
END_STREAM
Produit par pipemode.
Génération de clef
==================
La génération de clef marque sa progression à l'aide de différents caractères, dont
voici la signification :
"." : les 10 derniers tests Miller-Rabin ont échoué.
"+" : réussite du test Miller-Rabin.
"!" : Rechargement du pool avec des nombres premiers frais.
"^" : Vérification d'une nouvelle valeur pour le générateur.
"<" : La taille d'un facteur a été réduite.
">" : La taille d'un facteur a été augmentée.
Le nombre premier pour l'ElGamal est généré de la manière suivante :
1. On crée un nombre premier q de 160, 200 ou 240 bits (selon la taille
de la clef).
2. On sélectionne la taille de l'autre facteur premier, afin qu'elle soit
au moins de la taille de q et on calcule le nombre de facteurs premiers
requis.
3. On crée un pool de nombres premiers, chacun dont la longueur fut déterminée
à l'étape 2.
4. On obtient une nouvelle permutation du pool et nous continuons avec
l'étape 3 une fois toutes les permutations testées.
5. Le premier cancidat est calculé par p = 2 * q * p[1] * ... * p[n] + 1
6. On vérifie que ce premier dispose de la taille désirée (ceci peut changer
q s'il ne semble pas possible de produire un premier de la taille voulue)
7. On vérifie si ce nombre est premier à l'aide de divisions d'essai et par
le test de Miller-Rabin.
8. On continue à l'étape 4 si on n'a pas trouvé de premier à l'étape 7.
9. On trouve un générateur pour ce premier.
Cet algorithme se base sur la suggestion de Lim et Lee du Crypto' 97 (p. 260).
Génération de clef innatendue
=============================
Cette fonction est actuellement expérimentale et permet la production de
clefs innatendues avec un contrôle depuis un fichier de paramètres.
Cette fonctionnalité n'a pas fait l'objet de tests poussés ! Veuillez ne
PAS vous plaindre si nous décidons d'apporter des modifications importantes
à cette commande.
Pour utiliser cette fonctionnalité, vous devez utiliser --gen-key en
combinaison avec --batch et fournir les paramètres soit depuis stdin,
soit depuis un fichier dont le nom est fourni en ligne de commande.
Ce fichier devra utiliser le format suivant :
o En texte uniquement, chaque ligne étant limitée à environ 1000 caractères.
o Vous devez utiliser un codage UTF-8 pour marquer les caractères non ASCII.
o Les lignes vides seront ignorées.
o Les espaces en début et fin de ligne seront ignorés.
o Un signe "-" en tant que premier caractère "non white space" marque
une ligne de commentaire.
o Les commandes sont marquées par un signe "%" en début de ligne,
suivi par la commande et ses arguments sont séparés par des espaces.
o Les paramètres sont indiqués par un mot clef, suivi par un ":". Les
arguments sont séparés par des espaces.
o Le premier paramètre doit être "Key-Type" et ses contrôles peuvent
être placés à votre discrétion.
o La génération de clef aura lieu soit à la fin du fichier de paramètres,
soit lorsque le premier "Key-Type" est rencontré au sein du fichier,
dans un ensenble de contrôle "%commit".
o Les ensembles de contrôle sont :
%echo <texte>
Affiche <texte>
%dry-run
Ne réalise pas la production de clef (pratique pour vérifier la
syntaxe).
%commit
Réalise la production de clef. Un commit implicite est produit
à chaque rencontre de "Key-Type".
%pubring <filename>
%secring <filename>
Ne renvoie pas la clef vers le sortie par défaut ou dans le keyring
indiqué en ligne de commande, mais vers le fichier <filename>. Ce
contrôle doit être utilisé avant que le commit ne soit rencontré.
Toute double mention sera ignorée et le dernier nom de fichier
rencontré sera celui utilisé. Le fichier sera utilisé jusqu'à ce
qu'un nouveau fichier soit spécifié (au points de commit) sinon
toutes les clefs seront placées dans le même fichier. Si un nouveau
nom de fichier est indiqué, le fichier sera créé (et tout ancien
fichier sera alors écrasé). Les deux indications doivent être
fournies au contrôle.
o L'ordre des paramètres n'a pas d'importance, sauf pour "Key-Type" qui
doit être le premier paramètre rencontré. Les paramètres ne sont
destinés qu'au bloc keybloc généré et les paramètres des productions
précédentes de clefs ne seront pas pris en compte. Certaines
vérifications syntaxiques seront mises en place et peuvent être
ou non actives. Les paramètres actuellement définis sont :
Key-Type: <algo-number>|<algo-string>
Débute un nouveau bloc de paramètres indiquant le type de la clef
primaire à produire. L'algorithme doit être capable de produire
des signatures. Ce paramètre est indispensable !
Key-Length: <length-in-bits>
Indique la taille de la clef, en bits. La valeur par défaut est
1024.
Subkey-Type: <algo-number>|<algo-string>
Permet de produire une clef secondaire. Actuellement, seule une
sous-clef peut être gérée.
Subkey-Length: <length-in-bits>
Taille de la sous-clef en bits. La valeur par défaut est
1024.
Passphrase: <string>
Si vous souhaitez spécifier une phrase passe pour la clef
secrète vous pouvez utiliser cette commande. Par défaut,
aucune phrase passe ne sera associée aux clefs privées.
Name-Real: <string>
Name-Comment: <string>
Name-Email: <string>
Voici les trois composantes d'une clef. Vous devez ici
n'utiliser que de l'UTF-8. Si vous ne fournissez aucune
de ces indications, aucun ID d'utilisateur ne sera créé.
Expire-Date: <iso-date>|(<number>[d|w|m|y])
Spécifie la date d'expiration de la clef (et de sa sous-clef)
La date doit être entrée sous la forme d'une date au format
ISO (année-mois-jour) ou bien sous forme d'un nombre de
jours, de semaines, de mois ou d'années. Si vous n'utilisez
pas de lettre pour indiquer la durée, des "jours" sont
assumés par défaut.
Voici un exemple :
$ cat >foo <<EOF
%echo Génération d'une clef standard
Key-Type: DSA
Key-Length: 1024
Subkey-Type: ELG-E
Subkey-Length: 1024
Name-Real: Joe le testeur
Name-Comment: ma phrase passe est stupide
Name-Email: joe@foo.bar
Expire-Date: 0
Passphrase: abc
%pubring foo.pub
%secring foo.sec
# Un commit est requis ici, pour pouvoir afficher un "done" :-)
%commit
%echo done
EOF
$ gpg --batch --gen-key -a foo
[...]
$ gpg --no-default-keyring --secret-keyring foo.sec \
--keyring foo.pub --list-secret-keys
/home/wk/work/gnupg-stable/scratch/foo.sec
------------------------------------------
sec 1024D/915A878D 2000-03-09 Joe le testeur (ma phrase passe est stupide) <joe@foo.bar>
ssb 1024g/8F70E2C0 2000-03-09
Composition de la TrustDB
=========================
La TrustDB est construire à partir d'enregistrements à taille fixe, où le premier
octet décrit le type d'enregistrement. Toutes les valeurs numériques sont
conservées dans un réseau d'ordre d'octets. La longueur de chaque enregistrement
est de 40 octets. Le premier enregistrement de la TrustDB est toujours de type 1
et c'est le seul enregistrement de ce type.
Record type 0:
--------------
Cet enregistrement n'est pas utilisé. Il peut être utilisé
à votre discrétion.
Record type 1:
--------------
Indique la version de la TrustDB. Cet enregistrement doit toujours être
le premier enregistrement de la base de données et c'est le seul
enregistrement de type 1.
1 octet valeur : 1
3 octets 'gpg' valeur "magic"
1 octet Version de la TrustDB (2)
1 octet marginales requises
1 octet complètes requises
1 octet max_cert_depth
Ces trois éléments sont utilisés pour vérifier si la valeur de validité
mise en cache dans l'enregistrement du répertoire peut être utilisée :
1 u32 locked flags
1 u32 datation de la création de la trustdb
1 u32 datation de la dernière modification
Cette datation pourrait affecter la validité des clefs dans la base de
données. Cette valeur sera comparée à celle de la datation de validité
des enregistrements dir :
1 u32 datation de la dernière validation
Cette valeur sera utilisée pour stocker le passage du temps, lorsque
cette TrustDB sera comparée au trousseau de clefs publiques :
1 u32 numéro de l'enregistrement du keyhashtable
1 u32 premier enregistrement libre
1 u32 numéro de l'enregistrement répertoire shadow de la table de hachage
Cette table ne devrait pas être combinée avec la table de clefs car le
keyid n'est pas dans chaque cas un élément du fingerprint.
4 bytes réservés pour l'enregistrement d'extension de version
Record type 2: (enregistrement répertoire)
--------------
Regroupe les informations sur un certificat de clef publique.
Ces valeur sont statiques et ne sont jamais modifiées sans une
interaction avec l'utilisateur :
1 octet valeur : 2
1 octet réservé
1 u32 LID . (numéro d'enregistrement de cet enregistrement)
1 u32 Liste de key-records (le premier est la clef primaire)
1 u32 Liste de uid-records
1 u32 cache record
1 octet ownertrust
1 octet dirflag
1 octet validité maximale de tous les id utilisateurs
1 u32 datation de la dernière vérification de validité
1 u32 Vérification requise lorsque cette datation sera atteinte
(0 = pas de vérification requise)
Record type 3: (enregistrement de clef)
--------------
Regroupe les informations sur une clef publique primaire.
(ces informations sont principalement utilisées pour réaliser les lookup
dans l'enregistrement trust)
1 octet valeur : 3
1 octet réservé
1 u32 LID
1 u32 next - prochain enregistrement
7 octets réservés
1 octet keyflags
1 octet algorithme de la clef publique
1 octet taille du fingerprint (en octets)
20 octets fingerprint de la clef publique
(Cette valeur est utilisée pour identifier toute clef)
Record type 4: (enregistrement uid)
--------------
Regroupe les informations sur un id utilisateur (un "uid").
Nous ne stockons par l'uid mais un hachage de l'uid : cela semble suffire.
1 octet valeur : 4
1 octet réservé
1 u32 LID pointe vers l'enregistrement directory
1 u32 next le userid suivant
1 u32 pointeur vers l'enregistrement preference
1 u32 siglist liste de signatures valides
1 octet uidflags
1 octet validité de la clef calculée pour cet userid
20 bytes ripemd160 hachage du nom de l'utilisateur
Record type 5: (enregistrement pref)
--------------
Regroupe les informations formant les préférences.
1 octet valeur : 5
1 octet réservé
1 u32 LID; pointe vers l'enregistrement directory (et PAS vers le uid !!!)
(égal à 0 pour un enregistrement de préférences standard)
1 u32 suivant
30 byte données de préférences
Record type 6 (sigrec)
-------------
Cet enregistrement est utilisé pour traquer les signatures de clefs. Les
auto-signatures ne sont pas conservées. Si une clef publique ne se trouve
pas dans la TrustDB, la signature pointe vers un enregistrement dir fantôme,
lequel contient une liste des enregistrements qui seraient intéressés
par cette clef (et l'enregistrement signature en fait partie).
1 octet valeur : 6
1 octet réservé
1 u32 LID pointe en retour vers l'enregistrment dir
1 u32 next prochain sigrec de cet uid ou bien 0 pour indiquer que ce
sigrec est le dernier.
6 times
1 u32 Local_id des dir signatures ou de l'enregistrement dir fantôme
1 octet Flag: Bit 0 = vérifié: Bit 1 est valide (nous avons un
véritable enregistrement directory)
1 = valide est vrai (mais pourrait être révoqué)
Record type 8: (enregistrement répertoire (dir) fantôme)
--------------
Cet enregistrement est utilisé pour réserver un LID pour une clef publique.
Nous avons besoin de cet enregistrement pour créer les enregistrements sigs
des autres clefs, même si nous ne disposons pas d'une signature de la clef
publique.
Cet enregistrement (le numéro d'enregistrement pour être plus précis)
sera réutilisé dans l'enregistrement dir lorsque nous importerons la
véritable clef publique.
1 octet valeur : 8
1 octet réservé
1 u32 LID (Ceci est simplement le numéro d'enregistrement de ce record.)
2 u32 keyid
1 octet algorithme de la clef publique
3 octets réservé
1 u32 hintlist
hintlist contient la liste des enregistrements qui ont des références qui pointent
vers cette clef. Nous utilisons cet élément pour augmenter la vitesse d'accès
des enregistrements de signature qui ne sont pas encore vérifiés. Notez que ces
données ne sont qu'un indice, une indication ("hint") mais les enregistrements actuels
pourraient ne pas détenir d'enregistrement de signature pour la clef, mais le
code du programme saura prendre soin de tout cela.
18 octets réservés
Record Type 10 (table de hachage)
--------------
Comme nous utilisons les fingerprint pour accéder aux clefs, nous devons
implémenter un accès rapide en utilisant des méthodes de hachages simples,
afin d'éviter une surcharge de gdbm. La propriété des fingerprint
est qu'ils permettent un usage direct en tant que valeurs hachées (ils
peuvent être considérés comme des nombres aléatoires cryptographiquement
forts).
Nous utilisons une architecture à multiples niveaux dynamique, qui combine
les tables de hachage, les listes d'enregistrements et les listes
chaînées.
Cet enregistrement est une table de hachages de 256 entrées ; une propriété
spéciale est que tous les enregistrements sont stockés consécutivement
pour produire une grande table. La valeur hachée est simplement le 1er,
2nd.. octet du fingerprint (selon le niveau d'indirection).
Lorsque nous les utilisons pour hacher les enregistrements de répertoires
shadow, une différente table est utilisée, et elle se trouve indexée
par le keyid.
1 octet valeur : 10
1 octet réservé
n u32 recnum; n dépend de la taille de l'enregistrement :
n = (reclen-2)/4 ce qui donne 9 pour la taille actuelle
d'enregistrement de 40 octets.
Le nombre total de ces enregistrements constituant la table est :
m = (256+n-1) / n
ce qui donne 29 pour une taille d'enregistrement de 40.
Pour rechercher une clef, nous utilisons le premier octet du fingerprint
pour obtenir le recnum de la table de hachage et nous étudions l'enregistrement
adressé :
o Si cet enregistrement est une autre table de hachage, nous pouvons
utiliser le second octet pour indexer cette table de hachage et continuer.
o Si cet enregistrement est une liste de hachages, nous pouvons parcourir
toutes les entrées jusqu'à trouver la bonne.
o Si cet enregistrement est un enregistrement de clef, nous comparons
le fingerprint avec celui recherché et nous déterminons s'il s'agit
de la clef recherchée.
Record type 11 (liste hachée)
--------------
Consultez la table hachée pour une explication.
Ceci sera également utilisé à d'autres fins.
1 octet valeur : 11
1 octet réservé
1 u32 next enregistrement de liste hachée suivant
n times n = (reclen-5)/5
1 u32 recnum
Pour la taille actuelle utilisée par les enregistrements (taille 40) nous avons n = 7.
Record type 254 (enregistrement libre)
---------------
Tous ces enregistrements forment une liste chaînée d'enregistrements non-utilisés.
1 octet valeur 254
1 octet réservé (0)
1 u32 next_free
En-têtes de paquets
===================
GnuPG utilise des en-têtes PGP 2 et il est aussi capable de comprendre
les en-têtes de type OpenPGP. C'est une amélioration utilisée sur les anciens
en-têtes de paquets :
Les CTB bits 10, les "packet-length length bits" ont leurs valeurs listées
dans la table suivante :
00 - 1-octet champ packet-length
01 - 2-octets champ packet-length
10 - 4-octets champ packet-length
11 - pas de taille de paquet fournie, taille inconnue
Comme indiqué dans cette table, selon la taille du packet-length les
octets restants (1, 2, 4 ou 0) du champ de structure de paquets sont
un "champ packet-length". Ce champ est une valeur numérique à part entière.
La valeur du champ packet-length est définie par la valeur de la
totalité du champ numérique.
La valeur 11 est actuellement utilisée dans un cas : les données
compressées. C''est à dire qu'un bloc de données compressées
ressemble à : <A3 01 .. .. > où A3 est le binaire "10 1000 11" et
produit ici un paquet de taille non-définie. L'interprétation
correcte en est : "jusqu'à la fin de la structure englobante"
bien qu'en fait la structure englobante soit généralement
le fichier.
+ Ceci sera modifié dans une future version, où la signification de la
+ valeur 11 (voir ci-dessous) aura aussi sa place.
+
+ Une valeur de 11 pour d'autres paquets active un codage spécial
+ de la taille, où la taille du paquet suivant ne pourra pas être
+ déterminée avant l'écriture du paquet, en particulier ceci sera
+ utilisé si de grande quantités de données sont à traiter dans
+ un mode filtre.
+
+ Ceci fonctionne de la manière suivante : après le CTB (qui est un
+ champ de longueur de 11) un champ marqueur sera utilisé, il indiquera
+ alors la taille du bloc de données suivant. C'est un simple champ
+ de deux octets (MSB en premier) contenant la quantité de données qui
+ suivent le champ, sans inclure le champ de taille toutefois. Après
+ ce bloc de données un autre champ de taille suivra, qui donnera la taille
+ du bloc de données suivant. Une valeur de 0 indique une fin de paquet.
+ La taille maximale d'un bloc de données est limitée à 65534, ce qui
+ réserve la valeur 0xffff pour des extensions futures. Ces marqueurs de
+ taille devront être insérés dans le flux de données avant que les
+ données ne soient envoyées en sortie.
+
+ Ce champ de deux octets est largement suffisant, car l'application
+ doit placer en tampon cette quantité de données pour précéder le
+ marqueur de taille avant de produire une sortie. Les blocs de données
+ d'une taille supérieure à 32 Ko n'ont aucun sens. Notez que ceci pourra
+ également être utilisé pour les flux de données compressées, mais
+ nous devrons alors utiliser une autre version de paquet afin de dire à
+ l'application qu'elle ne peut assumer qu'il s'agit du dernier paquet.
Extensions GNU à l'algorithme S2K
=================================
Le S2K mode 101 est utilisé pour identifier ces extensions.
Après l'algorithme de hachage les trois octets "GNU" sont utilisés
pour indiquer clairement qu'il s'agit d'extensions GNU et les octets
qui suivent donnent le mode de protection GNU utilisé : 1000. Les
modes définis sont :
1001 - ne pas conserver du tout de partie secrète
Usage des fichiers gdbm pour les trousseaux de clefs
====================================================
La clef utilisé pour stocker le keyblock est son propre fingerprint,
les autres enregistrements sont utilisés pour les clefs secondaires.
Les fingerprint font toujours 20 octets où 16 bits de fingerprint
sont suivis par 0. Le premier octet de chaque clef indique une
information sur le type de clef :
1 = la clef est un fingerprint de 20 octets (16 octets fpr "paddés" de 0)
les données sont le keyblock
2 = la clef est un keyid complet de 8 octets
les données sont une liste de 20 octets fingerprints
3 = la clef est un keyid court de 4 octets
les données sont une liste de 20 octets fingerprints
4 = la clef est une adresse email
les données sont une liste de 20 octets fingerprints
Les données sont pre-appended (précédées) par un octet de type :
1 = keyblock
2 = liste de 20 octets fingerprints "paddés"
3 = liste de liste de fingerprints ("but how to we key them?")
Pipemode
========
Ce mode est utilisé pour réaliser des opérations multiples avec un
unique appel à gpg. C'est assez pratique lorsqu'il faut pouvoir vérifier
un grand nombre de signatures. Actuellement nous n'avons qu'un support
des signatures détachées. Ce mode est une astuce qui permet d'éviter
de faire fonctionner gpg n en daemon mode et d'utiliser les Unix Domain
Sockets pour lui faire passer les données. Il n'existe aucun moyen
pratique de portabilité de ce concept sous Windows, alors nous utilisons
des pipes simples pour faire fonctionner ce mode sous Windows. Comme nous
n'avons aucun moyen de signaler des EOF multiples dans un pipe nous
devons laisser le contrôle s'insérer dans le flux de données lui-même.
Nous réalisons alors une distinction entre les données du flux et un
état de contrôle. A son lancement, le système se trouve dans un état
de données mais n'acceptera aucune donnée. Il attend en fait une
transition vers un mode de contrôle qui s'obtient en envoyant un simple
caractère '@'. Une fois dans le mode de contrôle, des commandes sont
attendues et ces commandes sont à un octet après lequel le système
revient au mode de données (mais cela n'implique pas qu'il acceptera
des données immédiatement). La commande de contrôle la plus simple
est '@' qui permet d'insérer ce caractère dans le flux de données.
Voici le format que nous utilisons pour les signatures détachées :
"@<" - Début d'un nouveau flux
"@B" - La signature détachée suit.
Ceci émet le paquet de contrôle (1,'B')
<detached_signature>
"@t" - Le texte signé suit.
Ceci émet le paquet de contrôle (2, 'B')
<signed_text>
"@." - Fin de l'opération. Le paquet de contrôle final force la
vérification de la signature.
"@>" - Fin du flux.
Autres notes
============
Dans la version* 3 de version de paquet nous calculons les keyid de cette manière :
RSA : les 64 bits de poids faible de n
ELGAMAL : nous construisons un paquet de clef publique v3 (avec CTB 0x99)
et nous calculons une valeur hachée rmd160 à partir de ce paquet.
Il est utilisé comme fingerprint avec les 64 bits de poids faible
qui produisent le keyid.
* Les certificats de révocation ne comportent qu'un paquet de signature ;
"import" sait comment traiter ces paquets. L'idée derrière ce principe
est de conserver une petite taille de paquet.
Format des messages Keyserver
=============================
Le serveur de clef peut être contacté par un Unix Domain Socket ou via TCP.
Le format des requêtes est :
====
command-tag
"Content-length:" digits
CRLF
=======
Où le command-tag est :
NOOP
GET <user-name>
PUT
DELETE <user-name>
Le format de réponse utilisé est :
======
"GNUPG/1.0" status-code status-text
"Content-length:" digits
CRLF
============
suivi par <digits> octets de données.
Les codes de statut utilisés sont :
o 1xx: Information: requête reçue, traitement en cours.
o 2xx: Succès - L'action a été reçue, comprise et acceptée.
o 4xx: Erreur client : la requête contient une erreur, mauvaise syntaxe
ou demande irréalisable.
o 5xx: Erreur serveur - Le serveur n'a pu traiter une demande
qui semble valide.
Documentation sur HKP (le protocol de serveurs de clefs http)
=============================================================
Un serveur HTTP minimal sur port 11371 reconnaît les requêtes GET
pour /pks/lookup. Les paramètres standard encodés URL de la requête
sont toujours ceux-ci : (toujours key=valeur)
- op=index (comme pgp -kv), op=vindex (comme pgp -kvv) and op=get (comme
pgp -kxa)
- search=<stringlist>. Nous avons ici une liste de mots qui doivent
apparaître dans la clef. Ces mots sont séparés par des espaces,
points, @, etc. Les délimiteurs ne feront pas partie de la
recherche et l'ordre des mots n'a aucune importance (mais consultez
l'option suivante).
- exact=on. Ce switch permet d'indiquer au serveur hkp qu'il ne doit
rechercher que les correspondances exactes. Dans ce cas, les
délimiteurs et l'ordre des mots sera considéré.
- fingerprint=on. Renvoie également les fingerprint, lorsque utilisé
avec 'index' ou 'vindex'
Les serveurs de clefs savent aussi reconnaître le format http-POST vers /pks/add.
Vous utilisez ceci pour envoyer des clefs au serveur.
Le mieux pour produire une requête reste :
/pks/lookup/<gnupg_formatierte_user_id>?op=<operation>
Ceci peut être implémenté en utilisant le mécanisme de traduction Hurd.
Toutefois, nous pensons que les traitements du serveur de clef doivent
faire l'objet d'une refonte.

1111
doc/fr/FAQ
View file

File diff suppressed because it is too large Load diff

10
doc/fr/README.fr
View file

@ -1,10 +0,0 @@
You find here translations to French of some of the documents in
../doc. Those translations are not necessary up-to-date and should
not be used as reference without checking the original English
versions.
Gilbert Fernandes kindly contributed thses translatons.

8
doc/gnupg-w32.reg
View file

@ -1,8 +0,0 @@
REGEDIT4
[HKEY_CURRENT_USER\Software\GNU\GNUPG]
"HomeDir"="C:\\GnuPG"
"gpgProgram"="C:\\GnuPG\\gpg.exe"
[HKEY_CURRENT_USER\Control Panel\Mingw32\NLS]
"MODir"="C:\\GnuPG\\Locale"

14
doc/gnupg.7
View file

@ -1,14 +0,0 @@
.TH GNUPG 7 2002-09-02 GNU "GNU Privacy Guard"
.SH NAME
GnuPG \- The GNU Privacy Guard suite of programs
.SH DESCRIPTION
GnuPG is a set of programs for public key encryption and digital
signatures. The program most users want to use is
the OpenPGP command line tool, named \fBgpg\fP. \fBgpgv\fP
is a stripped down version of \fBgpg\fP to verify signatures
against a trusted keyring. There is also a tool called
\fBgpgsplit\fP to split OpenPGP messages or keyrings into their packets.
.SH "SEE ALSO"
.BR gpg (1),
.BR gpgv (1),

2461
doc/gpg.sgml
View file

File diff suppressed because it is too large Load diff

1531
doc/gpg.texi
View file

File diff suppressed because it is too large Load diff

225
doc/gpgv.sgml
View file

@ -1,225 +0,0 @@
<!-- gpgv.sgml - the man page for GnuPG
Copyright (C) 2000, 2001 Free Software Foundation, Inc.
This file is part of GnuPG.
GnuPG is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
GnuPG is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
-->
<!-- This file should be processed by docbook-to-man to
create a manual page. This program has currently the bug
not to remove leading white space. So this source file does
not look very pretty
FIXME: generated a file with entity (e.g. pathnames) from the
configure scripts and include it here
-->
<!DOCTYPE refentry PUBLIC "-//Davenport//DTD DocBook V3.0//EN" [
<!entity ParmDir "<parameter>directory</parameter>">
<!entity ParmFile "<parameter>file</parameter>">
<!entity OptParmFile "<optional>&ParmFile;</optional>">
<!entity ParmFiles "<parameter>files</parameter>">
<!entity OptParmFiles "<optional>&ParmFiles;</optional>">
<!entity ParmNames "<parameter>names</parameter>">
<!entity OptParmNames "<optional>&ParmNames;</optional>">
<!entity ParmName "<parameter>name</parameter>">
<!entity OptParmName "<optional>&ParmName;</optional>">
<!entity ParmKeyIDs "<parameter>key IDs</parameter>">
<!entity ParmN "<parameter>n</parameter>">
<!entity ParmFlags "<parameter>flags</parameter>">
<!entity ParmString "<parameter>string</parameter>">
<!entity ParmValue "<parameter>value</parameter>">
<!entity ParmNameValue "<parameter>name=value</parameter>">
]>
<refentry id="gpgv">
<refmeta>
<refentrytitle>gpgv</refentrytitle>
<manvolnum>1</manvolnum>
<refmiscinfo class="gnu">GNU Tools</refmiscinfo>
</refmeta>
<refnamediv>
<refname/gpgv/
<refpurpose>signature verification tool</>
</refnamediv>
<refsynopsisdiv>
<synopsis>
<command>gpgv</>
<optional><parameter/options/</optional>
<optional><parameter/signed files/</optional>
</synopsis>
</refsynopsisdiv>
<refsect1>
<title>DESCRIPTION</title>
<para>
<command/gpgv/ is the OpenPGP signature checking tool.
</para>
<para>
This program is a stripped down version of <command/gpg/ which is only
able
to check signatures. It is somewhat smaller than the full blown
<command/gpg/ and uses a different (and more simple way) to check that
the public keys used to made the signature are trustworth. There is
no options files and only very few options are implemented.
</para>
<para>
<command/gpgv/ assumes that all keys in the keyring are trustworty.
It uses by default a keyring named <filename/trustedkeys.gpg/ which is
assumed to be in the home directory as defined by GnuPG or set by an
option or an environment variable. An option may be used to specify
another keyring or even multiple keyrings.
</para>
</refsect1>
<refsect1>
<title>OPTIONS</title>
<para>
<command/gpgv/ recognizes these options:
</para>
<variablelist>
<varlistentry>
<term>-v, --verbose</term>
<listitem><para>
Give more information during processing. If used
twice, the input data is listed in detail.
</para></listitem></varlistentry>
<varlistentry>
<term>-q, --quiet</term>
<listitem><para>
Try to be as quiet as possible.
</para></listitem></varlistentry>
<varlistentry>
<term>--keyring &ParmFile;</term>
<listitem><para>
Add &ParmFile to the list of keyrings.
If &ParmFile begins with a tilde and a slash, these
are replaced by the HOME directory. If the filename
does not contain a slash, it is assumed to be in the
home-directory ("~/.gnupg" if --homedir is not used).
The filename may be prefixed with a scheme:</para>
<para>"gnupg-ring:" is the default one.</para>
<para>It might make sense to use it together with --no-default-keyring.
</para></listitem></varlistentry>
<varlistentry>
<term>--homedir &ParmDir;</term>
<listitem><para>
Set the name of the home directory to &ParmDir; If this
option is not used it defaults to "~/.gnupg". It does
not make sense to use this in a options file. This
also overrides the environment variable "GNUPGHOME".
</para></listitem></varlistentry>
<varlistentry>
<term>--status-fd &ParmN;</term>
<listitem><para>
Write special status strings to the file descriptor &ParmN;.
See the file DETAILS in the documentation for a listing of them.
</para></listitem></varlistentry>
<varlistentry>
<term>--logger-fd &ParmN;</term>
<listitem><para>
Write log output to file descriptor &ParmN; and not to stderr.
</para></listitem></varlistentry>
<varlistentry>
<term>--ignore-time-conflict</term>
<listitem><para>
GnuPG normally checks that the timestamps associated with keys and
signatures have plausible values. However, sometimes a signature seems to
be older than the key due to clock problems. This option makes these
checks just a warning.
</para></listitem></varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>RETURN VALUE</title>
<para>
The program returns 0 if everything was fine, 1 if at least
one signature was bad, and other error codes for fatal errors.
</para>
</refsect1>
<refsect1>
<title>EXAMPLES</title>
<variablelist>
<varlistentry>
<term>gpgv <parameter/pgpfile/</term>
<term>gpgv <parameter/sigfile/ &OptParmFiles;</term>
<listitem><para>
Verify the signature of the file. The second form
is used for detached signatures, where <parameter/sigfile/ is the detached
signature (either ASCII armored or binary) and &OptParmFiles are the signed
data; if this is not given the name of the file holding the signed data is
constructed by cutting off the extension (".asc", ".sig" or ".sign") from
<parameter/sigfile/.
</para></listitem></varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>ENVIRONMENT</title>
<variablelist>
<varlistentry>
<term>HOME</term>
<listitem><para>Used to locate the default home directory.</para></listitem>
</varlistentry>
<varlistentry>
<term>GNUPGHOME</term>
<listitem><para>If set directory used instead of "~/.gnupg".</para></listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>FILES</title>
<variablelist>
<varlistentry>
<term>~/.gnupg/trustedkeys.gpg</term>
<listitem><para>The default keyring with the allowed keys</para></listitem>
</varlistentry>
</variablelist>
</refsect1>
<!-- SEE ALSO not yet needed-->
</refentry>

119
doc/gpgv.texi
View file

@ -1,119 +0,0 @@
\input texinfo
@c This Texinfo document has been automatically generated by
@c docbook2texi from a DocBook documentation. The tool used
@c can be found at:
@c <URL:http://shell.ipoline.com/~elmert/hacks/docbook2X/>
@c Please send any bug reports, improvements, comments,
@c patches, etc. to Steve Cheng <steve@ggi-project.org>.
@setfilename gpgv.info
@dircategory GnuPG
@direntry
* gpgv: (gpgv). GnuPG signature verification tool.
@end direntry
@node top
@top gpgv
@menu
@end menu
@majorheading Name
gpgv ---- signature verification tool
@majorheading Synopsis
@majorheading DESCRIPTION
@code{gpgv} is the OpenPGP signature checking tool.
This program is a stripped down version of @code{gpg} which is only
able
to check signatures. It is somewhat smaller than the full blown
@code{gpg} and uses a different (and more simple way) to check that
the public keys used to made the signature are trustworth. There is
no options files and only very few options are implemented.
@code{gpgv} assumes that all keys in the keyring are trustworty.
It uses by default a keyring named @file{trustedkeys.gpg} which is
assumed to be in the home directory as defined by GnuPG or set by an
option or an environment variable. An option may be used to specify
another keyring or even multiple keyrings.
@majorheading OPTIONS
@code{gpgv} recognizes these options:
@table @asis
@item -v, ---verbose
Give more information during processing. If used
twice, the input data is listed in detail.
@item -q, ---quiet
Try to be as quiet as possible.
@item ---keyring @code{file}
Add @code{file} to the list of keyrings.
If @code{file} begins with a tilde and a slash, these
are replaced by the HOME directory. If the filename
does not contain a slash, it is assumed to be in the
home-directory ("~/.gnupg" if ---homedir is not used).
The filename may be prefixed with a scheme:
"gnupg-ring:" is the default one.
It might make sense to use it together with ---no-default-keyring.
@item ---homedir @code{directory}
Set the name of the home directory to @code{directory} If this
option is not used it defaults to "~/.gnupg". It does
not make sense to use this in a options file. This
also overrides the environment variable "GNUPGHOME".
@item ---status-fd @code{n}
Write special status strings to the file descriptor @code{n}.
See the file DETAILS in the documentation for a listing of them.
@item ---logger-fd @code{n}
Write log output to file descriptor @code{n} and not to stderr.
@item ---ignore-time-conflict
GnuPG normally checks that the timestamps associated with keys and
signatures have plausible values. However, sometimes a signature seems to
be older than the key due to clock problems. This option makes these
checks just a warning.
@end table
@majorheading RETURN VALUE
The program returns 0 if everything was fine, 1 if at least
one signature was bad, and other error codes for fatal errors.
@majorheading EXAMPLES
@table @asis
@item gpgv @code{pgpfile}
@itemx gpgv @code{sigfile} @code{files}
Verify the signature of the file. The second form
is used for detached signatures, where @code{sigfile} is the detached
signature (either ASCII armored or binary) and @code{files} are the signed
data; if this is not given the name of the file holding the signed data is
constructed by cutting off the extension (".asc", ".sig" or ".sign") from
@code{sigfile}.
@end table
@majorheading ENVIRONMENT
@table @asis
@item HOME
Used to locate the default home directory.
@item GNUPGHOME
If set directory used instead of "~/.gnupg".
@end table
@majorheading FILES
@table @asis
@item ~/.gnupg/trustedkeys.gpg
The default keyring with the allowed keys
@end table
@bye

9
doc/gph/ChangeLog
View file

@ -1,9 +0,0 @@
Tue Sep 7 16:18:03 1999 Werner Koch (wk@gnupg.org)
* Makefile.am: Ugly workarounds to do a VPATH build.
Fri Sep 3 13:24:45 1999 Werner Koch (wk@gnupg.org)
* Makefile.am: New

54
doc/gph/Makefile.am
View file

@ -1,54 +0,0 @@
# GPH - GNU Privacy Handbook
PARTS = manual.sgml c1.sgml c2.sgml c3.sgml c4.sgml c5.sgml c6.sgml c7.sgml \
signatures.fig signatures.jpg.asc
EXTRA_DIST = $(PARTS) index.html
#BUILT_SOURCES = index.html
all-local: ./signatures.jpg
./signatures.jpg: $(srcdir)/signatures.jpg.asc
../../g10/gpg --yes --dearmor \
-o ./signatures.jpg $(srcdir)/signatures.jpg.asc
-test -d manual && cp ./signatures.jpg ./manual/signatures.jpg
index.html: $(PARTS)
@set -e; \
for i in $(PARTS); do \
[ -f $$i ] || cat /dev/null $(srcdir)/$$i >./$$i ; \
done
db2html manual.sgml
echo '<html><body>' >index.html
echo '<ul>' >>index.html
echo '<li><a href="manual/book1.html">GnuPG User Manual</a>' >>index.html
echo '</ul>' >>index.html
echo '</body></html>' >>index.html
-rm -r manual.junk
-rm manual/signatures.jpg
## (cd manual; rm -r stylesheet-images; ls | grep -v distfiles >distfiles)
dist-hook: index.html
%.dvi: %.sgml
db2dvi $<
%.ps: %.dvi
dvips -o $@ $<
%/%.html: %.sgml
db2html $<
%.png: %.fig
fig2dev -L png $< $@
%.jpg: %.fig
fig2dev -L jpeg $< $@
%.eps: %.fig
fig2dev -L ps $< $@

627
doc/gph/c1.sgml
View file

@ -1,627 +0,0 @@
<chapter id="intro" xreflabel="1">
<docinfo>
<date>
$Id$
</date>
</docinfo>
<title>
Getting Started
</title>
<para>
&Gnupg; is a tool for secure communication.
This chapter is a quick-start guide that covers the core functionality
of &gnupg;.
This includes keypair creation, exchanging and verifying keys, encrypting
and decrypting documents, and making and verifying signatures.
It does not explain in detail the concepts behind public-key cryptography,
encryption, and digital signatures.
This is covered in Chapter <xref linkend="concepts">.
It also does not explain how to use &gnupg; wisely.
This is covered in Chapters <xref linkend="management"> and
<xref linkend="wise">.
</para>
<para>
&Gnupg; uses public-key cryptography so that users may communicate securely.
In a public-key system, each user has a public/private keypair.
A user's private key is kept secret; it need never be revealed.
The public key may be given to anyone with whom the user wants to
communicate.
&Gnupg; uses a somewhat more sophisticated scheme in which a user has
a primary keypair and then zero or more additional subordinate keypairs.
The primary and subordinate keypairs are bundled to facilitate key
management and the bundle can often be considered simply as one keypair.
</para>
<sect1>
<title>
Generating a new keypair
</title>
<para>
The command-line option <link linkend="gen-key"><option>--gen-key</option></link>
is used to create a new primary keypair.
<screen width="80">
<prompt>alice%</prompt> <userinput>gpg --gen-key</userinput>
gpg (GnuPG) 0.9.4; Copyright (C) 1999 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
Please select what kind of key you want:
(1) DSA and ElGamal (default)
(2) DSA (sign only)
(4) ElGamal (sign and encrypt)
Your selection?
</screen>
<!--
REWRITE
From Thomas Zander (zander@microweb.nl):
In GPG you can create 3 type of keypairs. A keypair is the combination
of a publ ic key and a private key, see chapter X. A DSA keypair can
only be used to sign a message. A ElGamal subordinate keypair can be
used for encryption as well as s igning, but is not as compatible with
former standards.
Option 1 creates 2 keypairs; a DSA (signing) and a ElGamal (Encryption).
Option 2 creates a DSA keypair (Signing)
Option 4 creates a ElGemal keypair (Signing & Encryption).
note: option 3 xxxx
This doesn't quite work, but I agree the following paragraph is rough.
-->
&Gnupg; is able to create several different types of keypairs, but a primary
key must be capable of making signatures.
There are therefore only three options.
Option 1 actually creates two keypairs.
A DSA keypair is the primary keypair usable only for making signatures.
An ElGamal subordinate keypair is also created for encryption.
Option 2 is similar but creates only a DSA keypair.
Option 4<footnote><para>Option 3 is to generate an ElGamal keypair that is
not usable for making signatures.</para></footnote> creates a single ElGamal
keypair usable for both making signatures and performing encryption.
In all cases it is possible to later add additional subkeys for encryption
and signing.
For most users the default option is fine.
</para>
<para>
You must also choose a key size.
The size of a DSA key must be between 512 and 1024 bits, and an ElGamal
key may be of any size.
&Gnupg;, however, requires that keys be no smaller than 768 bits.
Therefore, if Option 1 was chosen and you choose a keysize larger than
1024 bits, the ElGamal key will have the requested size, but the DSA
key will be 1024 bits.
<screen width="80">
About to generate a new ELG-E keypair.
minimum keysize is 768 bits
default keysize is 1024 bits
highest suggested keysize is 2048 bits
What keysize do you want? (1024)
</screen>
The longer the key the more secure it is against brute-force attacks,
but for almost all purposes the default keysize is adequate since
it would be cheaper to circumvent the encryption than try to break it.
Also, encryption and decryption will be slower as the
key size is increased, and a larger keysize may affect signature length.
Once selected, the keysize can never be changed.
</para>
<para>
Finally, you must choose an expiration date.
If Option 1 was chosen, the expiration date will be used for both the
ElGamal and DSA keypairs.
<screen width="80">
Please specify how long the key should be valid.
0 = key does not expire
&lt;n> = key expires in n days
&lt;n>w = key expires in n weeks
&lt;n>m = key expires in n months
&lt;n>y = key expires in n years
Key is valid for? (0)
</screen>
For most users a key that does not expire is adequate.
The expiration time should be chosen with care, however,
since although it is possible to change the expiration date after the key
is created, it may be difficult to communicate a change
to users who have your public key.
</para>
<para>
You must provide a user ID in addition to the key parameters.
The user ID is used to associate the key being created with a real
person.
<screen width="80">
You need a User-ID to identify your key; the software constructs the user id
from Real Name, Comment and Email Address in this form:
"Heinrich Heine (Der Dichter) &lt;heinrichh@duesseldorf.de>"
Real name:
</screen>
Only one user ID is created when a key is created, but it is possible
to create additional user IDs if you want to use the key in two or
more contexts, &eg;, as an employee at work and a political activist
on the side.
A user ID should be created carefully since it cannot be edited after
it is created.
</para>
<para>
&Gnupg; needs a passphrase to protect the primary and subordinate
private keys that you keep in your possession.
<screen width="80">
You need a Passphrase to protect your private key.
Enter passphrase:
</screen>
There is no limit on the length of a passphrase, and it should be
carefully chosen.
From the perspective of security, the passphrase to unlock the private
key is one of the weakest points in &gnupg; (and other public-key
encryption systems as well) since it is the only protection you
have if another individual gets your private key.
Ideally, the passphrase should not use words from a dictionary and
should mix the case of alphabetic characters as well as use
non-alphabetic characters.
A good passphrase is crucial to the secure use of &gnupg;.
</para>
<sect2 id="revocation">
<title>
Generating a revocation certificate
</title>
<para>
After your keypair is created you should immediately generate a revocation
certificate for the primary public key using the option
<link linkend="gen-revoke"><option>--gen-revoke</option></link>.
If you forget your passphrase or if your private key is compromised
or lost, this revocation certificate may be published to notify others
that the public key should no longer be used.
A revoked public key can still be used to verify signatures made
by you in the past, but it cannot be used to encrypt future messages
to you.
It also does not affect your ability to decrypt messages sent to
you in the past if you still do have access to the private key.
<screen width="80">
<prompt>alice%</prompt> <userinput>gpg --output revoke.asc --gen-revoke mykey</userinput>
[...]
</screen>
The argument <userinput>mykey</userinput> must be a <emphasis>key
specifier</emphasis>,
either the key ID of your primary keypair or any part of a user ID
that identifies your keypair.
The generated certificate will be left in the file
<parameter>revoke.asc</parameter>.
If the <link linkend="output"><option>--output</option></link> option is
omitted, the result will be placed on standard output.
Since the certificate is short, you may wish to print a hardcopy of
the certificate to store somewhere safe such as your safe deposit box.
The certificate should not be stored where others can access it since
anybody can publish the revocation certificate and render the
corresponding public key useless.
</para>
</sect2>
</sect1>
<sect1>
<title>
Exchanging keys
</title>
<para>
To communicate with others you must exchange public keys.
To list the keys on your public keyring use the command-line
option <link linkend="list-keys"><option>--list-keys</option></link>.
</para>
<screen width="80">
<prompt>alice%</prompt> <userinput>gpg --list-keys</userinput>
/users/alice/.gnupg/pubring.gpg
---------------------------------------
pub 1024D/BB7576AC 1999-06-04 Alice (Judge) &lt;alice@cyb.org>
sub 1024g/78E9A8FA 1999-06-04
</screen>
<sect2>
<title>
Exporting a public key
</title>
<para>
To send your public key to a correspondent you must first export it.
The command-line option <link linkend="export"><option>--export</option></link>
is used to do this.
It takes an additional argument identifying the public key to export.
As with the <option>--gen-revoke</option> option, either the key ID or any part of
the user ID may be used to identify the key to export.
</para>
<screen width="80">
<prompt>alice%</prompt> <userinput>gpg --output alice.gpg --export alice@cyb.org</userinput>
</screen>
<para>
The key is exported in a binary format, but this can be inconvenient
when the key is to be sent though email or published on a web page.
&Gnupg; therefore supports a command-line option
<link linkend="armor"><option>--armor</option></link><footnote>
<para>Many
command-line options that are frequently used can also be set in a
<link linkend="optionsfile">configuration file</link>.
</para>
</footnote>
that that
causes output to be generated in an ASCII-armored format similar to
uuencoded documents.
In general, any output from &gnupg;, &eg;, keys, encrypted documents, and
signatures, can be ASCII-armored by adding the <option>--armor</option> option.
</para>
<screen width="80">
<prompt>alice%</prompt> <userinput>gpg --armor --export alice@cyb.org</userinput>
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v0.9.7 (GNU/Linux)
Comment: For info see http://www.gnupg.org
[...]
-----END PGP PUBLIC KEY BLOCK-----
</screen>
</sect2>
<sect2>
<title>
Importing a public key
</title>
<para>
A public key may be added to your public keyring with the
<link linkend="import"><option>--import</option></link> option.
</para>
<screen width="80">
<prompt>alice%</prompt> <userinput>gpg --import blake.gpg</userinput>
gpg: key 9E98BC16: public key imported
gpg: Total number processed: 1
gpg: imported: 1
<prompt>alice%</prompt> <userinput>gpg --list-keys</userinput>
/users/alice/.gnupg/pubring.gpg
---------------------------------------
pub 1024D/BB7576AC 1999-06-04 Alice (Judge) &lt;alice@cyb.org>
sub 1024g/78E9A8FA 1999-06-04
pub 1024D/9E98BC16 1999-06-04 Blake (Executioner) &lt;blake@cyb.org>
sub 1024g/5C8CBD41 1999-06-04
</screen>
<para>
Once a key is imported it should be validated.
&Gnupg; uses a powerful and flexible trust model that does not require
you to personally validate each key you import.
Some keys may need to be personally validated, however.
A key is validated by verifying the key's fingerprint and then signing
the key to certify it as a valid key.
A key's fingerprint can be quickly viewed with the
<link linkend="fingerprint"><option>--fingerprint</option></link>
command-line option, but in order to certify the key you must edit it.
<screen width="80">
<prompt>alice%</prompt> <userinput>gpg --edit-key blake@cyb.org</userinput>
pub 1024D/9E98BC16 created: 1999-06-04 expires: never trust: -/q
sub 1024g/5C8CBD41 created: 1999-06-04 expires: never
(1) Blake (Executioner) &lt;blake@cyb.org>
<prompt>Command></prompt> <userinput>fpr</userinput>
pub 1024D/9E98BC16 1999-06-04 Blake (Executioner) &lt;blake@cyb.org>
Fingerprint: 268F 448F CCD7 AF34 183E 52D8 9BDE 1A08 9E98 BC16
</screen>
Key verification is a weak point in public-key cryptography, so you
must be sure that the fingerprint is correct.
The fingerprint displayed should be checked with the key's owner.
This may be done in person or over the phone or through any other means
as long as you can guarantee that you are communicating with the key's
true owner.
Once verified you may sign the key to validate it.
</para>
<screen width="80">
<prompt>Command></prompt> <userinput>sign</userinput>
pub 1024D/9E98BC16 created: 1999-06-04 expires: never trust: -/q
Fingerprint: 268F 448F CCD7 AF34 183E 52D8 9BDE 1A08 9E98 BC16
Blake (Executioner) &lt;blake@cyb.org>
Are you really sure that you want to sign this key
with your key: "Alice (Judge) &lt;alice@cyb.org>"
Really sign?
</screen>
<para>
Once signed you can check the key to list the signatures on it and
see the signature that you have added.
Every user ID on the key will have one or more self-signatures as well
as a signature for each user that has validated the key.
</para>
<screen width="80">
<prompt>Command></prompt> <userinput>check</userinput>
uid Blake (Executioner) &lt;blake@cyb.org>
sig! 9E98BC16 1999-06-04 [self-signature]
sig! BB7576AC 1999-06-04 Alice (Judge) &lt;alice@cyb.org>
</screen>
</sect2>
</sect1>
<sect1>
<title>
Encrypting and decrypting documents
</title>
<para>
To encrypt a document the option
<link linkend="encrypt"><option>--encrypt</option></link> is used.
You must have the public keys of the intended recipients.
The software expects the name of the document to encrypt as input or, if
omitted, on standard input.
The encrypted result is placed on standard output or as specified using
the option <option>--output</option>.
The document is compressed for additional security in addition to
encrypting it.
<screen width="80">
<prompt>alice%</prompt> <userinput>gpg --output doc.gpg --encrypt --recipient blake@cyb.org doc</userinput>
</screen>
The <link linkend="recipient"><option>--recipient</option></link> option
is used once for each recipient and takes an extra argument specifying
the public key to which the document should be encrypted.
The encrypted document can only be decrypted by someone with a private
key that complements one of the recipients' public keys.
In particular, you cannot decrypt a document encrypted by you unless
you included your own public key in the recipient list.
</para>
<para>
To decrypt a message the option
<link linkend="decrypt"><option>--decrypt</option></link> is used.
You need the private key to which the message was encrypted.
Similar to the encryption process, the document to decrypt is
input, and the decrypted result is output.
</para>
<screen width="80">
<prompt>blake%</prompt> <userinput>gpg --output doc --decrypt doc.gpg</userinput>
You need a passphrase to unlock the secret key for
user: "Blake (Executioner) &lt;blake@cyb.org>"
1024-bit ELG-E key, ID 5C8CBD41, created 1999-06-04 (main key ID 9E98BC16)
Enter passphrase:
</screen>
<para>
Documents may also be encrypted without using public-key cryptography.
Instead, only a symmetric cipher is used to encrypt the document.
The key used to drive the symmetric cipher is derived from a passphrase
supplied when the document is encrypted, and for good security, it
should not be the same passphrase that you use to protect your private key.
Symmetric encryption is useful for securing documents when the
passphrase does not need to be communicated to others.
A document can be encrypted with a symmetric cipher by using the
<link linkend="symmetric"><option>--symmetric</option></link> option.
</para>
<screen width="80">
<prompt>alice%</prompt> <userinput>gpg --output doc.gpg --symmetric doc</userinput>
Enter passphrase:
</screen>
</sect1>
<sect1>
<title>
Making and verifying signatures
</title>
<para>
A digital signature certifies and timestamps a document.
If the document is subsequently modified in any way, a verification
of the signature will fail.
A digital signature can serve the same purpose as a hand-written signature
with the additional benefit of being tamper-resistant.
The &gnupg; source distribution, for example, is signed so that users can
verify that the source code has not been modified since it was packaged.
</para>
<para>
Creating and verifying signatures uses the public/private keypair
in an operation different from encryption and decryption.
A signature is created using the private key of the signer.
The signature is verified using the corresponding public key.
A consequence is that it is difficult to deny that you made a digital
signature since that would imply your private key had been compromised.
</para>
<para>
The command-line option <link linkend="sign"><option>--sign</option></link> is
used to make a digital signature.
The document to sign is input, and the signed document is output.
<screen width="80">
<prompt>alice%</prompt> <userinput>gpg --output doc.sig --sign doc</userinput>
You need a passphrase to unlock the private key for
user: "Alice (Judge) &lt;alice@cyb.org>"
1024-bit DSA key, ID BB7576AC, created 1999-06-04
Enter passphrase:
</screen>
The document is compressed before signed, and the output is in binary
format.
</para>
<para>
Given a signed document, you can either check the signature or
check the signature and recover the original document.
To check the signature use the
<link linkend="verify"><option>--verify</option></link> option.
To verify the signature and extract the document use the
<option>--decrypt</option>
option.
The signed document to verify and recover is input and the recovered
document is output.
</para>
<screen width="80">
<prompt>blake%</prompt> <userinput>gpg --output doc --decrypt doc.sig</userinput>
gpg: Signature made Fri Jun 4 12:02:38 1999 CDT using DSA key ID BB7576AC
gpg: Good signature from "Alice (Judge) &lt;alice@cyb.org>"
</screen>
<sect2>
<title>
Clearsigned documents
</title>
<para>
A common use of digital signatures is to sign usenet postings or
email messages.
In such situations it is undesirable to compress the document while
signing it.
The option
<link linkend="clearsign"><option>--clearsign</option></link>
causes the document to be wrapped in an ASCII-armored signature but
otherwise does not modify the document.
</para>
<screen width="80">
<prompt>alice%</prompt> <userinput>gpg --clearsign doc</userinput>
You need a passphrase to unlock the secret key for
user: "Alice (Judge) &lt;alice@cyb.org>"
1024-bit DSA key, ID BB7576AC, created 1999-06-04
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[...]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.7 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAjdYCQoACgkQJ9S6ULt1dqz6IwCfQ7wP6i/i8HhbcOSKF4ELyQB1
oCoAoOuqpRqEzr4kOkQqHRLE/b8/Rw2k
=y6kj
-----END PGP SIGNATURE-----
</screen>
</sect2>
<sect2>
<title>
Detached signatures
</title>
<para>
A signed document has limited usefulness.
Other users must recover the original document from the signed
version, and even with clearsigned documents, the signed document
must be edited to recover the original.
Therefore, there is a third method for signing a document that
creates a detached signature.
A detached signature is created using the
<link linkend="detach-sig"><option>--detach-sig</option></link>
option.
</para>
<screen width="80">
<prompt>alice%</prompt> <userinput>gpg --output doc.sig --detach-sig doc</userinput>
You need a passphrase to unlock the secret key for
user: "Alice (Judge) &lt;alice@cyb.org>"
1024-bit DSA key, ID BB7576AC, created 1999-06-04
Enter passphrase:
</screen>
<para>
Both the document and detached signature are needed to verify
the signature.
The <option>--verify</option> option can be to check the
signature.
</para>
<screen width="80">
<prompt>blake%</prompt> <userinput>gpg --verify doc.sig doc</userinput>
gpg: Signature made Fri Jun 4 12:38:46 1999 CDT using DSA key ID BB7576AC
gpg: Good signature from "Alice (Judge) &lt;alice@cyb.org>"
</screen>
</sect2>
</sect1>
</chapter>
<!--
In the "Getting Started" chapter, it would be interesting to provide
a checklist of assumptions that the reader can consult to determine
whether or not she fits the "most users" profile. Perhaps put this
at the end of the chapter (perhaps w/ forward pointer?). You could
include cross references for each item on the list. For example:
23. Your use of public key encryption has property X with attribute Y.
(see Section 3.4.1 for a more detailed discussion of other
attributes of property X)
What prompted this was wondering, as I read through the generating keypair
section, "under what circumstances would these defaults be inappropriate?"
The notion of using the same key with different user IDs "as an employee at
work and a political activist on the side" is interesting. Knowing one,
could you be traced to the other? (Are they separate numeric ids, and is
that enough?) (seems someone could just match the public keys)
It's a very nice touch that you don't cover every single prompt that the
system throws at you, but instead treat them functionally. For example,
I can imagine other books going through the "Comment:" and "Email Address:"
prompts.
-->
<!--
"Key verification is a weak point in public-key cryptography ..."
Saying "weak point" makes it sound like a slam on public key stuff.
Although we've talked about weaknesses of the trust model, I'm guessing
the point here is that communication is only secure if you verify the
identity of the key's owner.
Key verification can be done through any means "as long as you can
guarantee that you are communicating with the key's true owner".
I suspect we'd also like to prevent leaking information that an
interceptor could use to pose as us in a key verification step with
another party. I suppose the notion of bootstrapping may not be widely
appreciated as an analogy.
I'm almost inclined to want to see a section in the Getting Started
guide called "Why you should read the rest of this book". Failing
that, or perhaps better yet, maybe it would work to have some margin
notes that point to other sections of the book for more information
("a discussion of trust models begins on p. 95").
-->

345
doc/gph/c2.sgml
View file

@ -1,345 +0,0 @@
<chapter id="concepts" xreflabel="2">
<docinfo>
<date>
$Id$
</date>
</docinfo>
<title>
Concepts
</title>
<para>
&Gnupg; makes uses of several cryptographic concepts including
<firstterm>symmetric ciphers</firstterm>,
<firstterm>public-key ciphers</firstterm>, and
<firstterm>one-way hashing</firstterm>.
You can make basic use &gnupg; without fully understanding these concepts,
but in order to use it wisely some understanding of them is necessary.
</para>
<para>
This chapter introduces the basic cryptographic concepts used in GnuPG.
Other books cover these topics in much more detail.
A good book with which to pursue further study is
<ulink url="http://www.counterpane.com/schneier.html">Bruce
Schneier</ulink>'s
<ulink url="http://www.counterpane.com/applied.html">"Applied
Cryptography"</ulink>.
</para>
<sect1>
<title>
Symmetric ciphers
</title>
<para>
A symmetric cipher is a cipher that uses the same key for both encryption
and decryption.
Two parties communicating using a symmetric cipher must agree on the
key beforehand.
Once they agree, the sender encrypts a message using the key, sends it
to the receiver, and the receiver decrypts the message using the key.
As an example, the German Enigma is a symmetric cipher, and daily keys
were distributed as code books.
Each day, a sending or receiving radio operator would consult his copy
of the code book to find the day's key.
Radio traffic for that day was then encrypted and decrypted using the
day's key.
Modern examples of symmetric ciphers include 3DES, Blowfish, and IDEA.
</para>
<para>
A good cipher puts all the security in the key and none in the algorithm.
In other words, it should be no help to an attacker if he knows which
cipher is being used.
Only if he obtains the key would knowledge of the algorithm be needed.
The ciphers used in &gnupg; have this property.
</para>
<para>
Since all the security is in the key, then it is important that it be
very difficult to guess the key.
In other words, the set of possible keys, &ie;, the <emphasis>key
space</emphasis>, needs
to be large.
While at Los Alamos, Richard Feynman was famous for his ability to
crack safes.
To encourage the mystique he even carried around a set of tools
including an old stethoscope.
In reality, he used a variety of tricks to reduce the number of
combinations he had to try to a small number and then simply guessed
until he found the right combination.
In other words, he reduced the size of the key space.
</para>
<para>
Britain used machines to guess keys during World War 2.
The German Enigma had a very large key space, but the British built
speciailzed computing engines, the Bombes, to mechanically try
keys until the day's key was found.
This meant that sometimes they found the day's key within hours of
the new key's use, but it also meant that on some days they never
did find the right key.
The Bombes were not general-purpose computers but were precursors
to modern-day computers.
</para>
<para>
Today, computers can guess keys very quickly, and this is why key
size is important in modern cryptosystems.
The cipher DES uses a 56-bit key, which means that there are
<!-- inlineequation -->
2<superscript>56</superscript> possible keys.
<!-- inlineequation -->
2<superscript>56</superscript> is 72,057,594,037,927,936 keys.
This is a lot of keys, but a general-purpose computer can check the
entire key space in a matter of days.
A specialized computer can check it in hours.
On the other hand, more recently designed ciphers such as 3DES,
Blowfish, and IDEA
<!-- inlineequation -->
all use 128-bit keys, which means there are 2<superscript>128</superscript>
possible keys.
This is many, many more keys, and even if all the computers on the
planet cooperated, it could still take more time than the age of
the universe to find the key.
</para>
</sect1>
<sect1>
<title>
Public-key ciphers
</title>
<para>
The primary problem with symmetric ciphers is not their security but
with key exchange.
Once the sender and receiver have exchanged keys, that key can be
used to securely communicate, but what secure communication channel
was used to communicate the key itself?
In particular, it would probably be much easier for an attacker to work
to intercept the key than it is to try all the keys in the key space.
Another problem is the number of keys needed.
<!-- inlineequation -->
If there are <emphasis>n</emphasis> people who need to communicate, then
<!-- inlineequation -->
<emphasis>n(n-1)/2</emphasis> keys
are needed for each pair of people to communicate privately.
This may be ok for a small number of people but quickly becomes unwieldly
for large groups of people.
</para>
<para>
Public-key ciphers were invented to avoid the key-exchange problem
entirely.
A public-key cipher uses a pair of keys for sending messages.
The two keys belong to the person receiving the message.
One key is a <emphasis>public key</emphasis> and may be given to anybody.
The other key is a <emphasis>private key</emphasis> and is kept
secret by the owner.
A sender encrypts a message using the public key and once encrypted,
only the private key may be used to decrypt it.
</para>
<para>
This protocol solves the key-exchange problem inherent with symmetric
ciphers.
There is no need for the sender and receiver to agree
upon a key.
All that is required is that some time before secret communication the
sender gets a copy of the receiver's public key.
Furthermore, the one public key can be used by anybody wishing to
communicate with the receiver.
<!-- inlineequation -->
So only <emphasis>n</emphasis> keypairs are needed for <emphasis>n</emphasis>
people to communicate secretly
with one another,
</para>
<para>
Public-key ciphers are based on one-way trapdoor functions.
A one-way function is a function that is easy to compute,
but the inverse is hard to compute.
For example, it is easy to multiply two prime numbers together to get
a composite, but it is difficult to factor a composite into its prime
components.a
A one-way trapdoor function is similar, but it has a trapdoor.
That is, if some piece of information is known, it becomes easy
to compute the inverse.
For example, if you have a number made of two prime factors, then knowing
one of the factors makes it easy to compute the second.
Given a public-key cipher based on prime factorization, the public
key contains a composite number made from two large prime factors, and
the encryption algorithm uses that composite to encrypt the
message.
The algorithm to decrypt the message requires knowing the prime factors,
so decryption is easy if you have the private key containing one of the
factors but extremely difficult if you do not have it.
</para>
<para>
As with good symmetric ciphers, with a good public-key cipher all of the
security rests with the key.
Therefore, key size is a measure of the system's security, but
one cannot compare the size of a symmetric cipher key and a public-key
cipher key as a measure of their relative security.
In a brute-force attack on a symmetric cipher with a key size of 80 bits,
<!-- inlineequation -->
the attacker must enumerate up to 2<superscript>81</superscript>-1 keys to
find the right key.
In a brute-force attack on a public-key cipher with a key size of 512 bits,
the attacker must factor a composite number encoded in 512 bits (up to
155 decimal digits).
The workload for the attacker is fundamentally different depending on
the cipher he is attacking.
While 128 bits is sufficient for symmetric ciphers, given today's factoring
technology public keys with 1024 bits are recommended for most purposes.
</para>
</sect1>
<sect1>
<title>
Hybrid ciphers
</title>
<para>
Public-key ciphers are no panacea.
Many symmetric ciphers are stronger from a security standpoint,
and public-key encryption and decryption are more expensive than the
corresponding operations in symmetric systems.
Public-key ciphers are nevertheless an effective tool for distributing
symmetric cipher keys, and that is how they are used in hybrid cipher
systems.
</para>
<para>
A hybrid cipher uses both a symmetric cipher and a public-key cipher.
It works by using a public-key cipher to share a key for the symmetric
cipher.
The actual message being sent is then encrypted using the key and sent
to the recipient.
Since symmetric key sharing is secure, the symmetric key used is different
for each message sent.
Hence it is sometimes called a session key.
</para>
<para>
Both PGP and &gnupg; use hybrid ciphers.
The session key, encrypted using the public-key cipher, and the message
being sent, encrypted with the symmetric cipher, are automatically
combined in one package.
The recipient uses his private-key to decrypt the session key and the
session key is then used to decrypt the message.
</para>
<para>
A hybrid cipher is no stronger than the public-key cipher or symmetric
cipher it uses, whichever is weaker.
In PGP and &gnupg;, the public-key cipher is probably the weaker of
the pair.
Fortunately, however, if an attacker could decrypt a session key it
would only be useful for reading the one message encrypted with that
session key.
The attacker would have to start over and decrypt another session
key in order to read any other message.
</para>
</sect1>
<sect1>
<title>
Digital signatures
</title>
<para>
A hash function is a many-to-one function that maps its input to a
value in a finite set.
Typically this set is a range of natural numbers.
<!-- inlineequation -->
A simple ehash function is <emphasis>f</emphasis>(<emphasis>x</emphasis>) = 0
for all integers <emphasis>x</emphasis>.
A more interesting hash function is
<emphasis>f</emphasis>(<emphasis>x</emphasis>) = <emphasis>x</emphasis>
<emphasis>mod</emphasis> 37, which
maps <emphasis>x</emphasis> to the remainder of dividing <emphasis>x</emphasis> by 37.
</para>
<para>
A document's digital signature is the result of applying a hash
function to the document.
To be useful, however, the hash function needs to satisfy two
important properties.
First, it should be hard to find two documents that hash to the
same value.
Second, given a hash value it should be hard to recover the document
that produced that value.
</para>
<para>
Some public-key ciphers<footnote><para>
The cipher must have the property that the actual public key or private
key could be used by the encryption algorithm as the public key.
RSA is an example of such an algorithm while ElGamal is not an example.
</para>
</footnote> could be used to sign documents.
The signer encrypts the document with his <emphasis>private</emphasis> key.
Anybody wishing to check the signature and see the document simply
uses the signer's public key to decrypt the document.
This algorithm does satisfy the two properties needed from a good hash
function, but in practice, this algorithm is too slow to be useful.
</para>
<para>
An alternative is to use hash functions designed to satisfy these
two important properties.
SHA and MD5 are examples of such algorithms.
Using such an algorithm, a document is signed by hashing it, and
the hash value is the signature.
Another person can check the signature by also hashing their copy of the
document and comparing the hash value they get with the hash value of
the original document.
If they match, it is almost certain that the documents are identical.
</para>
<para>
Of course, the problem now is using a hash function for digital
signatures without permitting an attacker to interfere with signature
checking.
If the document and signature are sent unencrypted, an attacker could
modify the document and generate a corresponding signature without the
recipient's knowledge.
If only the document is encrypted, an attacker could tamper with the
signature and cause a signature check to fail.
A third option is to use a hybrid public-key encryption to encrypt both
the signature and document.
The signer uses his private key, and anybody can use his public key
to check the signature and document.
This sounds good but is actually nonsense.
If this algorithm truly secured the document it would also
secure it from tampering and there would be no need for the signature.
The more serious problem, however, is that this does not protect either
the signature or document from tampering.
With this algorithm, only the session key for the symmetric cipher
is encrypted using the signer's private key.
Anybody can use the public key to recover the session key.
Therefore, it is straightforward for an attacker to recover the session
key and use it to encrypt substitute documents and signatures to send
to others in the sender's name.
</para>
<para>
An algorithm that does work is to use a public key algorithm to
encrypt only the signature.
In particular, the hash value is encrypted using the signer's private
key, and anbody can check the signature using the public key.
The signed document can be sent using any other encryption algorithm
including none if it is a public document.
If the document is modified the signature check will fail, but this
is precisely what the signature check is supposed to catch.
The Digital Signature Standard (DSA) is a public key signature
algorithm that works as just described.
DSA is the primary signing algorithm used in &Gnupg;.
</para>
</sect1>
</chapter>

885
doc/gph/c3.sgml
View file

@ -1,885 +0,0 @@
<chapter id="management" xreflabel="3">
<docinfo>
<date>
$Id$
</date>
</docinfo>
<title>
Key Management
</title>
<para>
Key tampering is a major security weakness with public-key cryptography.
An eavesdropper may tamper with a user's keyrings or forge a
user's public key and post it for others to download and use.
For example, suppose Chloe wants to monitor the messages that Alice
sends to Blake.
She could mount what is called a <firstterm>man in the
middle</firstterm> attack.
In this attack, Chloe creates a new public/private keypair.
She replaces Alice's copy of Blake's public key with the new public key.
She then intercepts the messages that Alice sends to Blake.
For each intercept, she decrypts it using the new private key, reencrypts
it using Blake's true public key, and forwards the reencrypted
message to Blake.
All messages sent from Alice to Blake can now be read by Chloe.
</para>
<para>
Good key management is crucial in order to ensure not just the integrity
of your keyrings but the integrity of other users' keyrings as well.
The core of key management in &gnupg; is the notion of signing keys.
Key signing has two main purposes: it permits you to detect tampering
on your keyring, and it allows you to certify that a key truly belongs
to the person named by a user ID on the key.
Key signatures are also used in a scheme known as the <firstterm>web of
trust</firstterm> to extend certification to keys not directly signed by you
but signed by others you trust.
Responsible users who practice good key management can defeat key
tampering as a practical attack on secure communication with &gnupg;.
</para>
<sect1>
<title>
Managing your own keypair
</title>
<para>
A keypair has a public key and a private key.
A public key consists of
the public portion of the master signing key,
the public portions of the subordinate signing and encryption subkeys, and
a set of user IDs used to associate the public key with a real person.
Each piece has data about itself.
For a key, this data includes its ID, when it was created, when it
will expire, etc.
For a user ID, this data includes the name of the real person it identifies,
an optional comment, and an email address.
The structure of the private key is similar, except that it contains only
the private portions of the keys, and there is no user ID information.
</para>
<para>
The command-line option
<link linkend="edit-key"><option>--edit-key</option></link>
may be used to view a keypair.
For example,
<screen width="80">
<prompt>chloe%</prompt> <userinput>gpg --edit-key chloe@cyb.org</userinput>
Secret key is available.
pub 1024D/26B6AAE1 created: 1999-06-15 expires: never trust: -/u
sub 2048g/0CF8CB7A created: 1999-06-15 expires: never
sub 1792G/08224617 created: 1999-06-15 expires: 2002-06-14
sub 960D/B1F423E7 created: 1999-06-15 expires: 2002-06-14
(1) Chloe (Jester) &lt;chloe@cyb.org>
(2) Chloe (Plebian) &lt;chloe@tel.net>
<prompt>Command></prompt>
</screen>
The public key is displayed along with an indication of whether
or not the private key is available.
Information about each component of the public key is then listed.
The first column indicates the type of the key.
The keyword <literal>pub</literal> identifies the public master signing key,
and the keyword <literal>sub</literal> identifies a public subordinate key.
The second column indicates the key's bit length, type, and ID.
The type is <literal>D</literal> for a DSA key, <literal>g</literal> for an
encryption-only
ElGamal key, and <literal>G</literal> for an ElGamal key that may be used for
both encryption and signing.
The creation date and expiration date are given in columns three and four.
The user IDs are listed following the keys.
</para>
<para>
More information about the key can be obtained with interactive commands.
The command <link linkend="toggle"><command>toggle</command></link>
switches between the public and private
components of a keypair if indeed both components are available.
<screen width="80">
<prompt>Command></prompt> <userinput>toggle</userinput>
sec 1024D/26B6AAE1 created: 1999-06-15 expires: never
sbb 2048g/0CF8CB7A created: 1999-06-15 expires: never
sbb 1792G/08224617 created: 1999-06-15 expires: 2002-06-14
sbb 960D/B1F423E7 created: 1999-06-15 expires: 2002-06-14
(1) Chloe (Jester) &lt;chloe@cyb.org>
(2) Chloe (Plebian) &lt;chloe@tel.net>
</screen>
The information provided is similar to the listing for the public-key
component.
The keyword <literal>sec</literal> identifies the private master signing key,
and the keyword <literal>sbb</literal> identifies the private subordinates keys.
The user IDs from the public key are also listed for convenience.
</para>
<sect2>
<title id="integrity">
Key integrity
</title>
<para>
When you distribute your public key, you are distributing the public
components of your master and subordinate keys as well as the user IDs.
Distributing this material alone, however, is a security risk since
it is possible for an attacker to tamper with the key.
The public key can be modified by adding or substituting keys, or by
adding or changing user IDs.
By tampering with a user ID, the attacker could change the user ID's email
address to have email redirected to himself.
By changing one of the encryption keys, the attacker would
also be able to decrypt the messages redirected to him.
</para>
<para>
Using digital signatures is a solution to this problem.
When data is signed by a private key, the corresponding public key
is bound to the signed data.
In other words, only the corresponding public key can be used to
verify the signature and ensure that the data has not been modified.
A public key can be protected from tampering by using its corresponding
private master key to sign the public key components and user IDs, thus
binding the components to the public master key.
Signing public key components with the corresponding private master
signing key is called <firstterm>self-signing</firstterm>, and a public key that has
self-signed user IDs bound to it is called a <firstterm>certificate</firstterm>.
</para>
<!--
%\begin{figure}
%Blank
%\caption{This should depict how self-signatures bind information to
%a public key.}\label{fig:selfsignedkey}
%\end{figure}
%
%As an example, Figure~\ref{fig:selfsignedkey} illustrates Chloe's public
%key, which has been self-signed to bind the user IDs and public subkeys
%to the public master key.
%The signatures on the user IDs can be checked with the \texttt{check}
%command from the key edit menu.
-->
<para>
As an example, Chloe has two user IDs and three subkeys.
The signatures on the user IDs can be checked with the command
<link linkend="check"><command>check</command></link> from the key edit menu.
<screen width="80">
<prompt>chloe%</prompt> <userinput>gpg --edit-key chloe</userinput>
Secret key is available.
pub 1024D/26B6AAE1 created: 1999-06-15 expires: never trust: -/u
sub 2048g/0CF8CB7A created: 1999-06-15 expires: never
sub 1792G/08224617 created: 1999-06-15 expires: 2002-06-14
sub 960D/B1F423E7 created: 1999-06-15 expires: 2002-06-14
(1) Chloe (Jester) &lt;chloe@cyb.org>
(2) Chloe (Plebian) &lt;chloe@tel.net>
<prompt>Command></prompt> <userinput>check</userinput>
uid Chloe (Jester) &lt;chloe@cyb.org>
sig! 26B6AAE1 1999-06-15 [self-signature]
uid Chloe (Plebian) &lt;chloe@tel.net>
sig! 26B6AAE1 1999-06-15 [self-signature]
</screen>
As expected, the signing key for each signature is the master signing
key with key ID <literal>0x26B6AAE1</literal>.
The self-signatures on the subkeys are present in the public key, but
they are not shown by the &gnupg; interface.
</para>
</sect2>
<sect2>
<title>
Adding and deleting key components
</title>
<para>
Both new subkeys and new user IDs may be added to your keypair after
it has been created.
A user ID is added using the command
<link linkend="adduid"><command>adduid</command></link>.
You are prompted for a real name, email address, and comment just
as when you create an initial keypair.
A subkey is added using the command
<link linkend="addkey"><command>addkey</command></link>.
The interface is similar to the interface used when creating an initial
keypair.
The subkey may be a DSA signing key, and encrypt-only ElGamal
key, or a sign-and-encrypt ElGamal key.
When a subkey or user ID is generated it is self-signed using your
master signing key, which is why you must supply your passphrase
when the key is generated.
</para>
<para>
Additional user IDs are useful when you need multiple identities.
For example, you may have an identity for your job and an identity
for your work as a political activist.
Coworkers will know you by your work user ID.
Coactivists will know you by your activist user ID.
Since those groups of people may not overlap, though, each group
may not trust the other user ID.
Both user IDs are therefore necessary.
</para>
<para>
Additional subkeys are also useful.
The user IDs associated with your public master key are validated by
the people with whom you
communicate, and changing the master key therefore requires recertification.
This may be difficult and time consuming if you communicate with
many people.
On the other hand, it is good to periodically change encryption subkeys.
If a key is broken, all the data encrypted with that key will be
vulnerable.
By changing keys, however, only the data encrypted with the one broken
key will be revealed.
</para>
<para>
Subkeys and user IDs may also be deleted.
To delete a subkey or user ID you must first select it using the
<link linkend="key"><command>key</command></link> or
<link linkend="uid"><command>uid</command></link> commands respectively.
These commands are toggles.
For example, the command <command>key <parameter>2</parameter></command>
selects the second subkey,
and invoking <command>key <parameter>2</parameter></command> again
deselects it.
If no extra argument is given, all subkeys or user IDs are deselected.
Once the user IDs to be deleted are selected, the command
<link linkend="deluid"><command>deluid</command></link>
actually deletes the user IDs from your key.
Similarly, the command <link linkend="delkey"><command>delkey</command></link>
deletes all selected subkeys from both your public and private keys.
</para>
<para>
For local keyring management, deleting key components is a good way
to trim other people's public keys of unnecessary material.
Deleting user IDs and subkeys on your own key, however, is not always
wise since it complicates key distribution.
By default, when a user imports your updated public key it will be merged
with the old copy of your public key on his ring if it exists.
The components from both keys are combined in the merge, and this
effectively restores any components you deleted.
To properly update the key, the user must first delete the old version
of your key and then import the new version.
This puts an extra burden on the people with whom you communicate.
Furthermore, if you send your key to a keyserver, the merge will
happen regardless, and anybody who downloads your key from a keyserver
will never see your key with components deleted.
Consequently, for updating your own key it is better to revoke key
components instead of deleting them.
</para>
</sect2>
<sect2>
<title>
Revoking key components
</title>
<para>
To revoke a subkey it must be selected.
Once selected it may be revoked with the
<link linkend="revkey"><command>revkey</command></link> command.
The key is revoked by adding a revocation self-signature to the key.
Unlike the command-line option <option>--gen-revoke</option>, the effect of
revoking a subkey is immediate.
</para>
<screen width="80">
<prompt>Command></prompt> <userinput>revkey</userinput>
Do you really want to revoke this key? y
You need a passphrase to unlock the secret key for
user: "Chloe (Jester) &lt;chloe@cyb.org>"
1024-bit DSA key, ID B87DBA93, created 1999-06-28
pub 1024D/B87DBA93 created: 1999-06-28 expires: never trust: -/u
sub 2048g/B7934539 created: 1999-06-28 expires: never
sub 1792G/4E3160AD created: 1999-06-29 expires: 2000-06-28
rev! subkey has been revoked: 1999-06-29
sub 960D/E1F56448 created: 1999-06-29 expires: 2000-06-28
(1) Chloe (Jester) &lt;chloe@cyb.org>
(2) Chloe (Plebian) &lt;chloe@tel.net>
</screen>
<para>
A user ID is revoked differently.
Normally, a user ID collects signatures that attest that the user ID
describes the person who actually owns the associated key.
In theory, a user ID describes a person forever, since that person will
never change.
In practice, though, elements of the user ID such as the email address
and comment may change over time, thus invalidating the user ID.
</para>
<para>
The OpenPGP
<comment>First reference to OpenPGP</comment>
specification does not support user ID revocation, but
a user ID can effectively be revoked by revoking the self-signature
on the user ID.
For the security reasons described
<link linkend="integrity">previously</link>,
correspondents will not trust a user ID with no valid self-signature.
</para>
<para>
A signature is revoked by using the command
<link linkend="revsig"><command>revsig</command></link>.
Since you may have signed any number of user IDs, the user interface
prompts you to decide for each signature whether or not to revoke it.
</para>
<screen width="80">
<prompt>Command></prompt> <userinput>revsig</userinput>
You have signed these user IDs:
Chloe (Jester) &lt;chloe@cyb.org>
signed by B87DBA93 at 1999-06-28
Chloe (Plebian) &lt;chloe@tel.net>
signed by B87DBA93 at 1999-06-28
user ID: "Chloe (Jester) &lt;chloe@cyb.org>"
signed with your key B87DBA93 at 1999-06-28
Create a revocation certificate for this signature? (y/N)n
user ID: "Chloe (Plebian) &lt;chloe@tel.net>"
signed with your key B87DBA93 at 1999-06-28
Create a revocation certificate for this signature? (y/N)y
You are about to revoke these signatures:
Chloe (Plebian) &lt;chloe@tel.net>
signed by B87DBA93 at 1999-06-28
Really create the revocation certificates? (y/N)y
You need a passphrase to unlock the secret key for
user: "Chloe (Jester) &lt;chloe@cyb.org>"
1024-bit DSA key, ID B87DBA93, created 1999-06-28
pub 1024D/B87DBA93 created: 1999-06-28 expires: never trust: -/u
sub 2048g/B7934539 created: 1999-06-28 expires: never
sub 1792G/4E3160AD created: 1999-06-29 expires: 2000-06-28
rev! subkey has been revoked: 1999-06-29
sub 960D/E1F56448 created: 1999-06-29 expires: 2000-06-28
(1) Chloe (Jester) &lt;chloe@cyb.org>
(2) Chloe (Plebian) &lt;chloe@tel.net>
</screen>
<para>
A revoked user ID is indicated by the revocation signature on
the ID when the signatures on the key's user IDs are listed.
</para>
<screen width="80">
<prompt>Command></prompt> <userinput>check</userinput>
uid Chloe (Jester) &lt;chloe@cyb.org>
sig! B87DBA93 1999-06-28 [self-signature]
uid Chloe (Plebian) &lt;chloe@tel.net>
rev! B87DBA93 1999-06-29 [revocation]
sig! B87DBA93 1999-06-28 [self-signature]
</screen>
<para>
Revoking both subkeys and self-signatures on user IDs adds revocation
self-signatures to the key.
Since signatures are being added and no material is deleted, a
revocation will always be visible to others when your updated public
key is distributed and merged with older copies of it.
Revocation therefore guarantees that everybody has a consistent
copy of your public key.
</para>
</sect2>
<sect2>
<title>
Updating a key's expiration time
</title>
<para>
The expiration time of a key may be updated with the command
<link linkend="expire"><command>expire</command></link> from the key edit menu.
If no key is selected the expiration time of the primary key
is updated.
Otherwise the expiration time of the selected subordinate key
is updated.
</para>
<para>
A key's expiration time is associated with the key's self-signature.
The expiration time is updated by deleting the old self-signature
and adding a new self-signature.
Since correspondents will not have deleted the old self-signature, they
will see an additional self-signature on the key when they update
their copy of your key.
The latest self-signature takes precedence, however, so all correspondents
will unambiguously know the expiration times of your keys.
</para>
</sect2>
</sect1>
<sect1>
<title>
Validating other keys on your public keyring
</title>
<para>
In Chapter <xref linkend="intro"> a procedure was given to validate your
correspondents' public keys: a correspondent's key is validated by
personally checking his key's fingerprint and then signing his public
key with your private key.
By personally checking the fingerprint you can be sure that the
key really does belong to him, and since you have signed they key, you
can be sure to detect any tampering with it in the future.
Unfortunately, this procedure is awkward when either you must validate
a large number of keys or communicate with people whom you do not
know personally.
</para>
<para>
&Gnupg; addresses this problem with a mechanism popularly known
as the <firstterm>web of trust</firstterm>.
In the web of trust model, responsibility for validating public
keys is delegated to people you trust.
For example, suppose
<itemizedlist spacing="compact">
<listitem>
<para>
Alice has signed Blake's key, and
</para>
</listitem>
<listitem>
<para>
Blake has signed Chloe's key and Dharma's key.
</para>
</listitem>
</itemizedlist>
If Alice trusts Blake to properly validate keys that he signs, then
Alice can infer that Chloe's and Dharma's keys are valid without
having to personally check them.
She simply uses her validated copy of Blake's public key to
check that Blake's signatures on Chloe's and Dharma's are good.
In general, assuming that Alice fully trusts everybody to properly
validate keys they sign, then any key signed by a valid key is also
considered valid.
The root is Alice's key, which is axiomatically assumed to be valid.
</para>
<sect2>
<title>
Trust in a key's owner
</title>
<para>
In practice trust is subjective.
For example, Blake's key is valid to Alice since she signed it, but she
may not trust Blake to properly validate keys that he signs.
In that case, she would not take Chloe's and Dharma's key as valid
based on Blake's signatures alone.
The web of trust model accounts for this by associating with each
public key on your keyring an indication of how much you trust the
key's owner.
There are four trust levels.
<variablelist>
<varlistentry>
<term>
unknown
</term>
<listitem>
<para>
Nothing is known about the owner's judgement in key signing.
Keys on your public keyring that you do not own initially have
this trust level.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
none
</term>
<listitem>
<para>
The owner is known to improperly sign other keys.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
marginal
</term>
<listitem>
<para>
The owner understands the implications of key signing and
properly validates keys before signing them.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
full
</term>
<listitem>
<para>
The owner has an excellent understanding of key signing,
and his signature on a key would be as good as your own.
</para>
</listitem>
</varlistentry>
</variablelist>
A key's trust level is something that you alone assign to the
key, and it is considered private information.
It is not packaged with the key when it is exported; it is even
stored separately from your keyrings in a separate database.
</para>
<para>
The &gnupg; key editor may be used to adjust your trust in a key's owner.
The command is <link linkend="trust"><command>trust</command></link>.
In this example Alice edits her trust in Blake and then updates
the trust database to recompute which keys are valid based on her new
trust in Blake.
<screen width="80">
<prompt>alice%</prompt> <userinput>gpg --edit-key blake</userinput>
pub 1024D/8B927C8A created: 1999-07-02 expires: never trust: q/f
sub 1024g/C19EA233 created: 1999-07-02 expires: never
(1) Blake (Executioner) &lt;blake@cyb.org>
<prompt>Command></prompt> <userinput>trust</userinput>
pub 1024D/8B927C8A created: 1999-07-02 expires: never trust: q/f
sub 1024g/C19EA233 created: 1999-07-02 expires: never
(1) Blake (Executioner) &lt;blake@cyb.org>
Please decide how far you trust this user to correctly
verify other users' keys (by looking at passports,
checking fingerprints from different sources...)?
1 = Don't know
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
s = please show me more information
m = back to the main menu
<prompt>Your decision?</prompt> <userinput>3</userinput>
pub 1024D/8B927C8A created: 1999-07-02 expires: never trust: m/f
sub 1024g/C19EA233 created: 1999-07-02 expires: never
(1) Blake (Executioner) &lt;blake@cyb.org>
<prompt>Command></prompt> <userinput>quit</userinput>
[...]
</screen>
Trust in the key's owner and the key's validity are indicated to the
right when the key is displayed.
Trust in the owner is displayed first and the key's validity is
<!-- HERE, need to fix quotation marks -->
second<footnote>
<para>
&Gnupg; overloads the word "trust" by using it to mean
trust in an owner and trust in a key.
This can be confusing.
Sometimes trust in an owner is referred to as
<firstterm>owner-trust</firstterm> to
distinguish it from trust in a key.
<!-- HERE, need to fix quotation marks -->
Throughout this manual, however, "trust" is used to
mean trust in a key's
<!-- HERE, need to fix quotation marks -->
owner, and "validity" is used to mean trust that a key
belongs to the human associated with the key ID.
</para>
</footnote>.
The four trust/validity levels are abbreviated: unknown (<literal>q</literal>),
none (<literal>n</literal>), marginal (<literal>m</literal>), and
full (<literal>f</literal>).
In this case, Blake's key is fully valid since Alice signed it herself.
She initially has an unknown trust in Blake to properly sign other keys
but decides to trust him marginally.
</para>
</sect2>
<sect2>
<title>
Using trust to validate keys
</title>
<para>
The web of trust allows a more elaborate algorithm to be used to
validate a key.
Formerly, a key was considered valid only if you signed it personally.
<!-- HERE, math -->
A more flexible algorithm can now be used: a key <emphasis>K</emphasis> is considered valid
if it meets two conditions:
<orderedlist spacing="compact">
<listitem>
<para>
it is signed by enough valid keys, meaning
<itemizedlist spacing="compact">
<listitem>
<para>
you have signed it personally,
</para>
</listitem>
<listitem>
<para>
it has been signed by one fully trusted key, or
</para>
</listitem>
<listitem>
<para>
it has been signed by three marginally trusted keys; and
</para>
</listitem>
</itemizedlist>
</para>
</listitem>
<listitem>
<para>
<!-- HERE, math -->
the path of signed keys leading from <emphasis>K</emphasis> back
to your own key is five steps or shorter.
</para>
</listitem>
</orderedlist>
The path length, number of marginally trusted keys required, and number
of fully trusted keys required may be adjusted.
The numbers given above are the default values used by &gnupg;.
</para>
<para>
<xref linkend="wot-examples"> shows a web of trust rooted at Alice.
The graph illustrates who has signed who's keys.
The table shows which keys Alice considers valid based on her
trust in the other members of the web.
<comment>Potential bug: <option>--completes-needed</option> on command
line seems to be ignored when combined with <option>--update-trustdb</option>.
Value is taken correctly if put in options file, however.</comment>
This example assumes that two marginally-trusted keys or one
fully-trusted key is needed to validate another key.
The maximum path length is three.
</para>
<para>
When computing valid keys in the example, Blake and Dharma's are
always considered fully valid since they were signed directly
by Alice.
The validity of the other keys depends on trust.
In the first case, Dharma is trusted fully, which implies
that Chloe's and Francis's keys will be considered valid.
In the second example, Blake and Dharma are trusted marginally.
Since two marginally trusted keys are needed to fully validate a
key, Chloe's key will be considered fully valid, but Francis's
key will be considered only marginally valid.
In the case where Chloe and Dharma are marginally trusted,
Chloe's key will be marginally valid since Dharma's key is
fully valid.
Francis's key, however, will also be considered marginally
valid since only a fully valid key can be used to validate
other keys, and Dharma's key is the only fully valid key
that has been used to sign Francis's key.
When marginal trust in Blake is added, Chloe's key becomes
fully valid and can then be used to fully validate Francis's
key and marginally validate Elena's key.
Lastly, when Blake, Chloe, and Elena are fully trusted, this is
still insufficient to validate Geoff's key since the maximum
certification path is three, but the path length from Geoff
back to Alice is four.
</para>
<para>
The web of trust model is a flexible approach to the problem of safe
public key exchange.
It permits you to tune &gnupg; to reflect how you use it.
At one extreme you may insist on multiple, short paths from your
<!-- HERE, math -->
key to another key <emphasis>K</emphasis> in order to trust it.
On the other hand, you may be satisfied with longer paths and
<!-- HERE, math -->
perhaps as little as one path from your key to the other
key <emphasis>K</emphasis>.
<!-- HERE, math -->
Requiring multiple, short paths is a strong guarantee
that <emphasis>K</emphasis> belongs to whom your think it does.
The price, of course, is that it is more difficult to validate keys
since you must personally sign more keys than if you accepted fewer
and longer paths.
</para>
<figure id="wot-examples" float=1>
<title>
A hypothetical web of trust
</title>
<!--
The graph indicates who has signed who's keys.
The table, in which names have been abbreviated, shows which keys are
valid depending on how Alice trusts other members in the web.
Alice considers different keys valid depending on how she trusts
the members of the web.
-->
<graphic fileref="signatures.jpg"></graphic>
<informaltable frame="all">
<tgroup cols="4" rowsep="1" colsep="1">
<colspec colname="one" colnum="1">
<colspec colname="two" colnum="2">
<colspec colname="three" colnum="3">
<colspec colname="four" colnum="4">
<spanspec spanname="lefthalf" namest="one" nameend="two" align="center">
<spanspec spanname="righthalf" namest="three" nameend="four" align="center">
<thead>
<colspec
<row>
<entry spanname="lefthalf">trust</entry>
<entry spanname="righthalf">validity</entry>
</row>
<row>
<entry align="center">marginal</entry>
<entry align="center">full</entry>
<entry align="center">marginal</entry>
<entry align="center">full</entry>
</row>
</thead>
<tbody>
<row>
<entry></entry>
<entry>Dharma</entry>
<entry></entry>
<entry>Blake, Chloe, Dharma, Francis</entry>
</row>
<row>
<entry>Blake, Dharma</entry>
<entry></entry>
<entry>Francis</entry>
<entry>Blake, Chloe, Dharma</entry>
</row>
<row>
<entry>Chloe, Dharma</entry>
<entry></entry>
<entry>Chloe, Francis</entry>
<entry>Blake, Dharma</entry>
</row>
<row>
<entry>Blake, Chloe, Dharma</entry>
<entry></entry>
<entry>Elena</entry>
<entry>Blake, Chloe, Dharma, Francis</entry>
</row>
<row>
<entry></entry>
<entry>Blake, Chloe, Elena</entry>
<entry></entry>
<entry>Blake, Chloe, Elena, Francis</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</figure>
</sect2>
</sect1>
<sect1>
<title>
Distributing keys
</title>
<para>
Ideally, you distribute your key by personally giving it to your
correspondents.
In practice, however, keys are often distributed by email or some
other electronic communication medium.
Distribution by email is good practice when you have only a few
correspondents, and even if you have many correspondents, you can use
an alternative means such as posting your public key on your World Wide
Web homepage.
This is unacceptable, however, if people who need your public key do
not know where to find it on the Web.
</para>
<para>
To solve this problem public key servers are used to collect
and distribute public keys.
A public key received by the server is either added to the server's
database or merged with the existing key if already present.
When a key request comes to the server, the server consults its
database and returns the requested public key if found.
</para>
<para>
A keyserver is also valuable when many people are frequently signing other
people's keys.
Without a keyserver, when Blake sign's Alice's key then Blake would send
Alice a copy of her public key signed by him so that Alice could
add the updated key to her ring as well as distribute it to all of her
correspondents.
Going through this effort fulfills Alice's and Blake's responsibility
to the community at large in building tight webs of trust and thus
improving the security of PGP.
It is nevertheless a nuisance if key signing is frequent.
</para>
<para>
Using a keyserver makes the process somewhat easier.
When Blake signs Alice's key he sends the signed key to the key server.
The key server adds Blake's signature to its copy of Alice's key.
Individuals interested in updating their copy of Alice's key then consult
the keyserver on their own initiative to retrieve the updated key.
Alice need never be involved with distribution and can retrieve signatures
on her key simply by querying a keyserver.
<comment><option>--keyserver</option> must come before
<option>--send-key</option> or <option>--recv-key</option>.
This appears to be a bug.</comment>
</para>
<para>
One or more keys may be sent to a keyserver using the command-line
option <link linkend="send-keys"><option>--send-keys</option></link>.
The option takes one or more key specifiers and sends the specified
keys to the key server.
The key server to which to send the keys is specified with the
command-line option <link linkend="keyserver"><option>--keyserver</option></link>.
Similarly, the option
<link linkend="recv-keys"><option>--recv-keys</option></link> is used
to retrieve keys from a keyserver, but the option <option>--recv-keys</option>
requires a key ID be used to specify the key.
In the following example Alice sends her public key to the keyserver
<parameter>certserver.pgp.com</parameter> and then updates her copy
of Blake's key from the same keyserver.
<screen width="80">
<prompt>alice%</prompt> <userinput>gpg --keyserver certserver.pgp.com --recv-key 0xBB7576AC</userinput>
gpg: requesting key BB7576AC from certserver.pgp.com ...
gpg: key BB7576AC: 1 new signature
gpg: Total number processed: 1
gpg: new signatures: 1
<prompt>alice%</prompt> <userinput>gpg --keyserver certserver.pgp.com --send-key blake@cyb.org</userinput>
gpg: success sending to 'certserver.pgp.com' (status=200)
</screen>
There are several popular keyservers in use around the world.
The major keyservers synchronize themselves, so it is fine to
pick a keyserver close to you on the Internet and then use it
regularly for sending and receiving keys.
</para>
</sect1>
</chapter>

433
doc/gph/c4.sgml
View file

@ -1,433 +0,0 @@
<chapter id="wise" xreflabel="4">
<docinfo>
<date>
$Id$
</date>
</docinfo>
<title>
Daily use of &Gnupg;
</title>
<para>
&Gnupg; is a complex tool with technical, social, and legal issues
surrounding it.
Technically, it has been designed to be used in situations having
drastically different security needs.
This complicates key management.
Socially, using &gnupg; is not strictly a personal decision.
To use &gnupg effectively both parties communicating must use it.
Finally, as of 1999, laws regarding digital encryption, and in particular
whether or not using &gnupg; is legal, vary from country to country and
is currently being debated by many national governments.
</para>
<para>
This chapter addresses these issues.
It gives practical advice on how to use &gnupg; to meet your security needs.
It also suggests ways to promote the use of &gnupg; for secure
communication between yourself and your colleagues when your colleagues
are not currently using &gnupg;.
Finally, the legal status of &gnupg; is outlined given the current status
of encryption laws in the world.
</para>
<sect1>
<title>
Defining your security needs
</title>
<para>
&Gnupg; is a tool you use to protect your privacy.
Your privacy is protected if you can correspond with others without
eavesdroppers reading those messages.
</para>
<para>
How you should use &gnupg; depends on the determination and resourcefulness
of those who might want to read your encrypted messages.
An eavesdropper may be an unscrupulous system administrator casually
scanning your mail, it might be an industrial spy trying to collect
your company's secrets, or it might be a law enforcement agency trying
to prosecute you.
Using &gnupg; to protect against casual eavesdropping is going to be
different than using &gnupg; to protect against a determined adversary.
Your goal, ultimately, is to make it more expensive to recover the
unencrypted data than that data is worth.
</para>
<para>
Customizing your use of &gnupg; revolves around three issues:
<itemizedlist spacing="compact">
<listitem>
<para>
the key size of your public/private keypair,
</para>
</listitem>
<listitem>
<para>
protecting your private key, and
</para>
</listitem>
<listitem>
<para>
managing your web of trust.
</para>
</listitem>
</itemizedlist>
A well-chosen key size protects you against brute-force attacks on
encrypted messages.
Protecting your private key prevents an attacker from simply using your
private key to decrypt encrypted messages and sign messages in your name.
Correctly managing your web of trust prevents attackers from masquarading
as people with whom you communicate.
Ultimately, addressing these issues with respect to your own security
needs is how you balance the extra work required to use &gnupg; with
the privacy it gives you.
</para>
<sect2>
<title>
Choosing a key size
</title>
<para>
Selecting a key size depends on the key.
In OpenPGP, a public/private keypair usually has multiple keys.
At the least it has a master signing key, and it probably has one or
more additional subkeys for encryption.
Using default key generation parameters with &gnupg;, the master
key will be a DSA key, and the subkeys will be ElGamal keys.
</para>
<para>
DSA allows a key size up to 1024 bits.
This is not especially good given today's factoring technology, but
that is what the standard specifies.
Without question, you should use 1024 bit DSA keys.
</para>
<para>
ElGamal keys, on the other hand, may be of any size.
Since &gnupg; is a hybrid public-key system, the public key is used
to encrypt a 128-bit session key, and the private key is used to
decrypt it.
Key size nevertheless affects encryption and decryption speed
since the cost of these algorithms is exponential in the size of
the key.
Larger keys also take more time to generate and take more space
to store.
Ultimately, there are diminishing returns on the extra security
a large key provides you.
After all, if the key is large enough to resist a brute-force
attack, an eavesdropper will merely switch to some other method for
obtaining your plaintext data.
Examples of other methods include robbing your home or office
and mugging you.
1024 bits is thus the recommended key size.
If you genuinely need a larger key size then you probably already
know this and should be consulting an expert in data security.
</para>
</sect2>
<sect2>
<title>
Protecting your private key
</title>
<para>
Protecting your private key is the most important job you have to
use &gnupg; correctly.
If someone obtains your private key, then all data encrypted to
the private key can be decrypted and signatures can be made in your name.
If you lose your private key, then you will no longer be able to
decrypt documents encrypted to you in the future or in the past,
and you will not be able to make signatures.
Losing sole possession of your private key is catastrophic.
</para>
<para>
Regardless of how you use &gnupg; you should store the public
key's <link linkend="revocation">revocation certificate</link>
and a backup of your private key on write-protected media in a safe place.
For example, you could burn them on a CD-ROM and store them in your
safe deposit box at the bank in a sealed envelope.
Alternatively, you could store them on a floppy and hide it in your
house.
Whatever you do, they should be put on media that is safe to store
for as long as you expect to keep the key, and you should store
them more carefully than the copy of your private key you use daily.
</para>
<para>
To help safeguard your key, &Gnupg; does not store your raw
private key on disk.
Instead it encrypts it using a symmetric encryption algorithm.
That is why you need a passphrase to access the key.
Thus there are two barriers an attacker must cross to access your private
key: (1) he must actually acquire the key, and (2) he must get past
the encryption.
</para>
<para>
Safely storing your private key is important, but there is a cost.
Ideally, you would keep the private key on a removable, write-protected disk
such as a floppy disk, and you would use it on a single-user machine
not connected to a network.
This may be inconvenient or impossible for you to do.
For example, you may not own your own machine and must use a computer
at work or school, or it may mean you have to physically disconnect
your computer from your cable modem every time you want to use &gnupg;
</para>
<para>
This does not mean you cannot or should not use &gnupg;.
It means only that you have decided that the data you are protecting is
important enough to encrypt but not so important as to take extra
steps to make the first barrier stronger.
It is your choice.
</para>
<para>
A good passphrase is absolutely critical when using &gnupg;.
Any attacker who gains access to your private key must bypass the
encryption on the private key.
Instead of brute-force guessing the key, an attacker will almost
certainly instead try to guess the passphrase.
</para>
<para>
The motivation for trying passphrases is that most people choose
a passphrase that is easier to guess than a random 128-bit key.
If the passphrase is a word, it is much cheaper to try all the
words in the dictionaries of the world's languages.
Even if the word is permuted, &eg, k3wldood, it is still easier
to try dictionary words with a catalog of permutations.
The same problem applies to quotations.
In general, passphrases based on natural-language utterances
are poor passphrases since there is little randomness and lots
of redundancy in natural language.
You should avoid natural language passphrases if you can.
</para>
<para>
A good passphrase is one that you can remember but is hard for
someone to guess.
It should include characters from the whole range of printable characters
on your keyboard.
This includes uppercase alphabetics characters, numbers, and special
characters such as <literal>}</literal> and <literal>|</literal>.
Be creative and spend a little time considering your passphrase; a
good choice is important to ensure your privacy.
</para>
</sect2>
<!--
<sect2>
<title>
Reacting to a compromised private key
</title>
<para>
Despite your precautions you may lose sole access to your private key.
For example, you may forget the passphrase, or someone who you think
can bypass the encryption gets access to it.
In that case then you need to spread the word that your key is no
longer valid.
To do that you use the key revocation certificate you should have generated
when you created the key.
Importing it onto your public keyring will revoke the public key
of the keypair you no longer wish to use.
It is then up to you to distribute the revoked public key to all
those who may encrypt documents to you.
</para>
<para>
A revoked public key only prevents future use of the private key.
Others will neither be able to encrypt documents to the key nor will
they be able to check signatures made with the private key.
Documents signed in the past can still be checked, however, and
documents encrypted in the past can still be decrypted.
</para>
<para>
It is important that you protect the revocation certificate carefully.
Anybody can add the certificate to your public key and distribute it,
and there is no way to revoke a revocation certificate.
Therefore, you should store the revocation certificate in a safe
place such as with the backup of your private key.
</para>
</sect2>
-->
<sect2>
<title>
Managing your web of trust
</title>
<para>
As with protecting your private key, managing your web of trust is
another aspect of using &gnupg; that requires balancing security against
ease of use.
If you are using &gnupg; to protect against casual eavesdropping and
forgeries then you can afford to be relatively trusting of other
people's signatures.
On the other hand, if you are concerned that there may be a determined
attacker interested in invading your privacy, then
you should be much less trusting of other signatures and spend more time
personally verifying signatures.
</para>
<para>
Regardless of your own security needs, through, you should
<emphasis>always be careful</emphasis> when signing other keys.
It is selfish to sign a key with just enough confidence in the key's
validity to satisfy your own security needs.
Others, with more stringent security needs, may want to depend on
your signature.
If they cannot depend on you then that weakens the web of trust
and makes it more difficult for all &gnupg; users to communicate.
Use the same care in signing keys that you would like others to use when
you depend on their signatures.
</para>
<para>
In practice, managing your web of trust reduces to assigning trust to
others and tuning the options
<link linkend="marginals-needed"><option>--marginals-needed</option></link>
and
<link linkend="completes-needed"><option>--completes-needed</option></link>.
Any key you personally sign will be considered valid, but except for small
groups, it will not be practical to personally sign the key of every person
with whom you communicate.
You will therefore have to assign trust to others.
</para>
<para>
It is probably wise to be accurate when assigning trust and then
use the options to tune how careful &gnupg; is with key validation.
As a concrete example, you may fully trust a few close friends that
you know are careful with key signing and then marginally
trust all others on your keyring.
From there, you may set <option>--completes-needed</option> to
<literal>1</literal> and <option>--marginals-needed</option> to
<literal>2</literal>.
If you are more concerned with security you might choose values of
<literal>1</literal> and <literal>3</literal> or <literal>2</literal>
and <literal>3</literal> respectively.
If you are less concerned with privacy attacks and just want some
reasonable confidence about validity, set the values to <literal>1</literal>
and <literal>1</literal>.
In general, higher numbers for these options imply that more people
would be needed to conspire against you in order to have a key validated
that does not actually belong to the person whom you think it does.
</para>
</sect2>
</sect1>
<sect1>
<title>
Building your web of trust
</title>
<para>
Wanting to use &gnupg; yourself is not enough.
In order to use to communicate securely with others you must have
a web of trust.
At first glance, however, building a web of trust is a daunting task.
The people with whom you communicate need to use
&gnupg;<footnote><para>In this section, &gnupg; refers to the
&gnupg; implementation of OpenPGP as well as other implementations
such as NAI's PGP product.</para></footnote>, and there needs to be enough
key signing so that keys can be considered valid.
These are not technical problems; they are social problems.
Nevertheless, you must overcome these problems if you want to
use &gnupg;.
</para>
<para>
When getting started using &gnupg; it is important to realize that you
need not securely communicate with every one of your correspondents.
Start with a small circle of people, perhaps just yourself and
one or two others who also want to exercise their right
to privacy.
Generate your keys and sign each other's public keys.
This is your initial web of trust.
By doing this you will appreciate the value of a small, robust
web of trust and will be more cautious as you grow your web
in the future.
</para>
<para>
In addition to those in your initial web of trust, you may want to
communicate securely with others who are also using &gnupg;.
Doing so, however, can be awkward for two reasons:
(1) you do not always know when someone uses or is willing to use
&gnupg;, and (2) if you do know of someone who uses it, you may still have
trouble validating their key.
The first reason occurs because people do not always advertise that
they use &gnupg;.
The way to change this behavior is to set the example and advertise
that you use &gnupg;.
There are at least three ways to do this: you can sign messages you mail
to others or post to message boards, you can put your public key on your
web page, or, if you put your key on a keyserver, you can put your key
ID in your email signature.
If you advertise your key then you make it that much more acceptable
for others to advertise their keys.
Furthermore, you make it easier for others to start communicating
with you securely since you have taken the initiative and made it clear
that you use &gnupg;.
</para>
<para>
Key validation is more difficult.
If you do not personally know the person whose key you want to sign,
then it is not possible to sign the key yourself.
You must rely on the signatures of others and hope to find a chain
of signatures leading from the key in question back to your own.
To have any chance of finding a chain, you must take the intitive
and get your key signed by others outside of your intitial web of trust.
An effective way to accomplish this is to participate in key
signing parties.
If you are going to a conference look ahead of time for a key
signing party, and if you do not see one being held, offer to
<ulink url="http://www.herrons.com/kb2nsx/keysign.html">hold one</ulink>.
You can also be more passive and carry your fingerprint with you
for impromptu key exchanges.
In such a situation the person to whom you gave the fingerprint
would verify it and sign your public key once he returned home.
</para>
<para>
Keep in mind, though, that this is optional.
You have no obligation to either publically advertise your key or
sign other people's keys.
The power of &gnupg; is that it is flexible enough to adapt to your
security needs whatever they may be.
The social reality, however, is that you will need to take the initiative
if you want to grow your web of trust and use &gnupg; for as much of
your communication as possible.
</para>
</sect1>
<sect1>
<title>
Using &Gnupg; legally
</title>
<para>
The legal status of encryption software varies from country to country,
and law regarding encryption software is rapidly evolving.
<ulink url="http://cwis.kub.nl/~frw/people/koops/bertjaap.htm">Bert-Japp
Koops</ulink> has an excellent
<ulink url="http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm">Crypto
Law Survey</ulink> to which you should refer for the legal status of
encryption software in your country.
</para>
</sect1>
</chapter>

38
doc/gph/c5.sgml
View file

@ -1,38 +0,0 @@
<chapter id="Modules" xreflabel="5">
<docinfo>
<date>
$Id$
</date>
</docinfo>
<title>
Programming with &Gnupg;
</title>
<para>...</para>
<sect1>
<title>
Using &gpg in batch mode
</title>
<para>...</para>
<sect2>
<title>
Invoking &gpg from mail clients
</title>
<para>...</para>
</sect2>
</sect1>
<sect1>
<title>
Writing extension modules
</title>
<para>...</para>
</sect1>
</chapter>

804
doc/gph/c6.sgml
View file

@ -1,804 +0,0 @@
<reference>
<docinfo>
<date>
$Id$
</date>
</docinfo>
<title>
Command Reference
</title>
<partintro>
<sect1>
<title>
Key specifiers
</title>
<para>
Many commands and options require a <firstterm>key specifier</firstterm>.
A key specifier is the key ID or any portion of ther user ID of
a key.
Consider the following example.
<screen width="80">
<prompt>alice%</prompt> <userinput>gpg --list-keys chloe</userinput>
pub 1024D/B87DBA93 1999-06-28 Chloe (Jester) &lt;chloe@cyb.org>
uid Chloe (Plebian) &lt;chloe@tel.net>
sub 2048g/B7934539 1999-06-28
</screen>
For this key, <literal>0xB87DBA93</literal>,
<literal>Chloe</literal>,
<literal>Plebian</literal>, and
<literal>oe@tel</literal>
are all examples of key specifiers that match the above key.
</para>
</sect1>
</partintro>
<refentry id="send-keys">
<refnamediv>
<refname>
send-keys
</refname>
<refpurpose>
send keys to a key server
</refpurpose>
</refnamediv>
<refsynopsisdiv>
<synopsis>
send-keys <replaceable class="parameter">key</replaceable>
</synopsis>
</refsynopsisdiv>
<refsect1>
<title>
Description
</title>
<para>
This command sends a public key to a keyserver.
The parameter <replaceable class="parameter">key</replaceable> specifies
the public key that should be uploaded.
The command requires the option
<link linkend="keyserver"><option>keyserver</option></link> to specify
to which keyserver &gpg; should send the keys.
</para>
</refsect1>
</refentry>
<refentry id="recv-keys">
<refnamediv>
<refname>
recv-keys
</refname>
<refpurpose>
retrieve keys from a key server
</refpurpose>
</refnamediv>
<refsynopsisdiv>
<synopsis>
<option>recv-keys</option> <replaceable class="parameter">key-id key-id ...</replaceable>
</synopsis>
</refsynopsisdiv>
<refsect1>
<title>
Description
</title>
<para>
This command downloads one or more public keys from a keyserver.
Each <replaceable class="parameter">key-id</replaceable> is a key ID.
The command requires the option
<link linkend="keyserver"><option>keyserver</option></link> to
specify from which keyserver &gpg; should download the keys.
</para>
</refsect1>
</refentry>
<refentry id="encrypt">
<refnamediv>
<refname>
encrypt
</refname>
<refpurpose>
encrypt a document
</refpurpose>
</refnamediv>
<refsynopsisdiv>
<synopsis>
<option>encrypt</option> <replaceable class="parameter">filename</replaceable>
</synopsis>
</refsynopsisdiv>
<refsect1>
<title>
Description
</title>
<para>
This command encrypts the document
<replaceable class="parameter">filename</replaceable> to
recipients specified using the
option <link linkend="recipient"><option>recipient</option></link>.
If the parameter <replaceable class="parameter">filename</replaceable>
is omitted, then the document to encrypt is taken from standard input.
If the option <option>recipient</option> is omitted,
&gpg; will prompt for a recipient.
If the option <link linkend="output"><option>output</option></link> is used,
&gpg; will output the encrypted information to the specified file.
</para>
</refsect1>
</refentry>
<refentry id="decrypt">
<refnamediv>
<refname>
decrypt
</refname>
<refpurpose>
decrypt an encrypted document
</refpurpose>
</refnamediv>
<refsynopsisdiv>
<synopsis>
<option>decrypt</option> <replaceable class="parameter">filename</replaceable>
</synopsis>
</refsynopsisdiv>
<refsect1>
<title>
Description
</title>
<para>
This command decrypts <replaceable class="parameter">filename</replaceable>
and puts the result on standard output.
If the parameter <replaceable class="parameter">filename</replaceable>
is omitted, then the document to decrypt is taken from standard input.
Use the option <link linkend="output"><option>output</option></link>
to output the decrypted message to a file instead.
</para>
</refsect1>
</refentry>
<refentry id="clearsign">
<refnamediv>
<refname>
clearsign
</refname>
<refpurpose>
make a cleartext signature
</refpurpose>
</refnamediv>
<refsynopsisdiv>
<synopsis>
<option>clearsign</option> <replaceable class="parameter">filename</replaceable>
</synopsis>
</refsynopsisdiv>
<refsect1>
<title>
Description
</title>
<para>
This command signs a message that can be verified to ensure that the
original message has not been changed.
Verification of the signed message is done using the command
<link linkend="verify"><option>verify</option></link>.
</para>
</refsect1>
</refentry>
<refentry id="fingerprint">
<refnamediv>
<refname>
fingerprint
</refname>
<refpurpose>
display key fingerprints
</refpurpose>
</refnamediv>
<refsynopsisdiv>
<synopsis>
<option>fingerprint</option> <replaceable class="parameter">name ...</replaceable>
</synopsis>
</refsynopsisdiv>
<refsect1>
<title>
Description
</title>
<para>
This command prints the fingerprints of the specified public keys.
The parameter <replaceable class="parameter">name</replaceable> is a
key specifier.
If no parameter <replaceable class="parameter">name</replaceable> is
provided, &gpg; will print the fingerprints of all the keys on
your public keyring.
</para>
</refsect1>
</refentry>
<refentry id="detach-sig">
<refnamediv>
<refname>
detach-sig
</refname>
<refpurpose>
make a detached signature
</refpurpose>
</refnamediv>
<refsynopsisdiv>
<synopsis>
<option>detach-sig</option> <replaceable class="parameter">filename</replaceable>
</synopsis>
</refsynopsisdiv>
<refsect1>
<title>
Description
</title>
<para>
This command creates a signature file that can be used
to verify that the orginal file
<replaceable class="parameter">filename</replaceable> has not
been changed.
Verification of the file using a detached signature is done using the
command <link linkend="verify"><option>verify</option></link>.
</para>
</refsect1>
</refentry>
<refentry id="gen-key">
<refnamediv>
<refname>
gen-key
</refname>
<refpurpose>
generate a new keypair
</refpurpose>
</refnamediv>
<refsynopsisdiv>
<synopsis>
<option>gen-key</option>
</synopsis>
</refsynopsisdiv>
<refsect1>
<title>
Description
</title>
<para>
This command generates a private/public key pair for use in encrypting,
decrypting, and signing of messages.
You will br prompted for the kind of key you wish to create, the key
size, and the key's expiration date.
</para>
</refsect1>
</refentry>
<refentry id="symmetric">
<refnamediv>
<refname>
symmetric
</refname>
<refpurpose>
encrypt a document using only a symmetric encryption algorithm
</refpurpose>
</refnamediv>
<refsynopsisdiv>
<synopsis>
<option>symmetric</option> <replaceable class="parameter">filename</replaceable>
</synopsis>
</refsynopsisdiv>
<refsect1>
<title>
Description
</title>
<para>
This command encrypts a document using a symmetric algorithm with
a key derived from a passphrase supplied by you during execution.
The key should be selected to make it difficult to randomly guess the key.
To decrypt a document encrypted in this manner use the command.
<link linkend="decrypt"><option>decrypt</option></link>.
</para>
</refsect1>
</refentry>
<refentry id="list-keys">
<refnamediv>
<refname>
list-keys
</refname>
<refpurpose>
list information about the specified keys
</refpurpose>
</refnamediv>
<refsynopsisdiv>
<synopsis>
<option>list-keys</option> <replaceable class="parameter">key ...</replaceable>
</synopsis>
</refsynopsisdiv>
<refsect1>
<title>
Description
</title>
<para>
This command lists the public key specified by the key specifiers on the
command line.
If no key specifier is given, &gpg; will print all of the keys on the
public keyring.
</para>
</refsect1>
</refentry>
<refentry id="import">
<refnamediv>
<refname>
import
</refname>
<refpurpose>
import keys to a local keyring
</refpurpose>
</refnamediv>
<refsynopsisdiv>
<synopsis>
<option>import</option> <replaceable class="parameter">filename</replaceable>
</synopsis>
</refsynopsisdiv>
<refsect1>
<title>
Description
</title>
<para>
This command imports one or more public keys onto the user's public
keyring from the file <replaceable class="parameter">filename</replaceable>.
</para>
</refsect1>
</refentry>
<refentry id="verify">
<refnamediv>
<refname>
verify
</refname>
<refpurpose>
verify a signed document
</refpurpose>
</refnamediv>
<refsynopsisdiv>
<synopsis>
<option>verify</option> <replaceable class="parameter">signature document</replaceable>
</synopsis>
</refsynopsisdiv>
<refsect1>
<title>
Description
</title>
<para>
This command verifies a document against a signature
to ensure that the document has not been altered since the signature
was created.
If <replaceable class="parameter">signature</replaceable> is omitted,
&gpg; will look in <replaceable class="parameter">document</replaceable>
for a clearsign signature.
</para>
</refsect1>
</refentry>
<refentry id="gen-revoke">
<refnamediv>
<refname>
gen-revoke
</refname>
<refpurpose>
generate a revocation certificate for a public/private keypair
</refpurpose>
</refnamediv>
<refsynopsisdiv>
<synopsis>
<option>gen-revoke</option> <replaceable class="parameter">key</replaceable>
</synopsis>
</refsynopsisdiv>
<refsect1>
<title>
Description
</title>
<para>
This command generates a revocation certificate for a public/private
key pair.
The parameter <replaceable class="parameter">key</replaceable> is
a key specifier.
</para>
</refsect1>
</refentry>
<refentry id="export">
<refnamediv>
<refname>
export
</refname>
<refpurpose>
export keys from a local keyring
</refpurpose>
</refnamediv>
<refsynopsisdiv>
<synopsis>
<option>export</option> <replaceable class="parameter">key key ...</replaceable>
</synopsis>
</refsynopsisdiv>
<refsect1>
<title>
Description
</title>
<para>
This command exports the public keys components of the keys specified
by the key specifiers <replaceable class="parameter">key key ...</replaceable>.
The export command by default sends its output to standard output.
This key file can later be imported into another keyring using the command
<link linkend="import"><option>import</option></link>.
</para>
</refsect1>
</refentry>
<refentry id="edit-key">
<refnamediv>
<refname>
edit-key
</refname>
<refpurpose>
presents a menu for operating on keys
</refpurpose>
</refnamediv>
<refsynopsisdiv>
<synopsis>
<option>edit-key</option> <replaceable class="parameter">key</replaceable>
</synopsis>
</refsynopsisdiv>
<refsect1>
<title>
Description
</title>
<para>
This command presents a menu which enables you to perform
key-related taskes.
The key specifier <replaceable class="parameter">key</replaceable>
specifies the key pair to be edited.
If the specifier matches more than one key pair, &gpg; issues
an error and exits.
</para>
<para>
Key listings displayed during key editing show the key with its
secondary keys and all user ids.
Selected keys or user ids are indicated by an asterisk.
The trust and validity values are displayed with the primary key:
the first is the assigned trust and the second is the
calculated validity.
Letters are used for the values:
<informaltable>
<tgroup cols="2" rowsep="1" colsep="1">
<thead>
<row>
<entry>Letter</entry>
<entry>Meaning</entry>
</row>
</thead>
<tbody>
<row>
<entry>
-
</entry>
<entry>
No ownertrust assigned / not yet calculated.
</entry>
</row>
<row>
<entry>
e
</entry>
<entry>
Trust calculation has failed.
</entry>
</row>
<row>
<entry>
q
</entry>
<entry>
Not enough information for calculation.
</entry>
</row>
<row>
<entry>
n
</entry>
<entry>
Never trust this key.
</entry>
</row>
<row>
<entry>
m
</entry>
<entry>
Marginally trusted.
</entry>
</row>
<row>
<entry>
f
</entry>
<entry>
Fully trusted.
</entry>
</row>
<row>
<entry>
u
</entry>
<entry>
Ultimately trusted.
</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
<para>
The following lists each key editing command and a description
of its behavior.
</para>
<refsect2 id="sign">
<title>
sign
</title>
<para>
Makes a signature on the current key.
If th key is not yet signed by the default user or the user
given with the option
<link linkend="local-user"><option>local-user</option></link>,
the program displays the information of the key again, together with
its fingerprint and asks whether it should be signed.
This question is repeated for all users specified with the option
<option>local-user</option>.
</para>
</refsect2>
<refsect2 id="lsign">
<title>
lsign
</title>
<para>
Same as <link linkend="sign">sign</link>, but the signature is
marked as non-exportable and will therefore never be used by others.
This may be used to make keys valid only in the local environment.
</para>
</refsect2>
<refsect2 id="revsig">
<title>
revsig
</title>
<para>
Revoke a signature.
Asks for each signature makde by a one of the private keys whether
a revocation certificate should be generated.
</para>
</refsect2>
<refsect2 id="trust">
<title>
trust
</title>
<para>
Change the owner trust value.
This updates the trust database immediately and no save is required.
</para>
</refsect2>
<refsect2 id="disable">
<title>
disable
</title>
<para>
Disable the key.
A disabled key cannot normally be used for encryption.
</para>
</refsect2>
<refsect2 id="enable">
<title>
enable
</title>
<para>
Enable a key that has been previously
<link linkend="disable">disabled</link>.
</para>
</refsect2>
<refsect2 id="adduid">
<title>
adduid
</title>
<para>
Add a new user id to the current key.
</para>
</refsect2>
<refsect2 id="deluid">
<title>
deluid
</title>
<para>
Delete a user id from the current key.
</para>
</refsect2>
<refsect2 id="addkey">
<title>
addkey
</title>
<para>
Add a new subkey to the current key.
</para>
</refsect2>
<refsect2 id="delkey">
<title>
delkey
</title>
<para>
Delete a subkey from the current key.
</para>
</refsect2>
<refsect2 id="revkey">
<title>
revkey
</title>
<para>
Revoke a subkey of the current key.
</para>
</refsect2>
<refsect2 id="expire">
<title>
expire
</title>
<para>
Change a key expiration time.
If a subkey is selected, the time of that key will be changed.
With no selection the expiration time of the current primary key is changed.
</para>
</refsect2>
<refsect2 id="key">
<title>
key n
</title>
<para>
Toggle selection of subkey with index n.
Use 0 to deselect all.
</para>
</refsect2>
<refsect2 id="uid">
<title>
uid n
</title>
<para>
Toggle selection of user id with index n.
Use 0 to deselect all.
</para>
</refsect2>
<refsect2 id="passwd">
<title>
toggle
</title>
<para>
Change the passphrase of the private key of the selected key pair.
</para>
</refsect2>
<refsect2 id="toggle">
<title>
toggle
</title>
<para>
Toggle between public and private key listings.
</para>
</refsect2>
<refsect2 id="check">
<title>
check
</title>
<para>
Check all selected user ids.
</para>
</refsect2>
<refsect2 id="pref">
<title>
pref
</title>
<para>
List preferences.
</para>
</refsect2>
<refsect2 id="save">
<title>
save
</title>
<para>
Save all changes to the current key and quit.
</para>
</refsect2>
<refsect2 id="quit">
<title>
save
</title>
<para>
Quit without updating the current key.
</para>
</refsect2>
</refsect1>
</refentry>
</reference>

251
doc/gph/c7.sgml
View file

@ -1,251 +0,0 @@
<reference>
<docinfo>
<date>
$Id$
</date>
</docinfo>
<title>
Options Reference
</title>
<partintro>
<sect1 id="optionsfile">
<title>
Setting options
</title>
<para>
Options may be specified on the command line or in an options file.
The default location of the options file is
<literal>~/.gnupg/options</literal>.
When specifying options in the options file, omit the leading two
dashes and instead use simply the option name followed by any
arguments.
Lines in the file with a hash (<literal>#</literal>) as the
first non-white-space character are ignored.
</para>
</sect1>
</partintro>
<refentry id="keyserver">
<refnamediv>
<refname>
keyserver
</refname>
<refpurpose>
specify the keyserver to use to locate keys
</refpurpose>
</refnamediv>
<refsynopsisdiv>
<synopsis>
<option>keyserver</option> <replaceable class="parameter">server-name</replaceable>
</synopsis>
</refsynopsisdiv>
<refsect1>
<title>
Description
</title>
<para>
This option is used in conjunction with either
<link linkend="recv-keys"><option>recv-keys</option></link> or
<link linkend="send-keys"><option>send-keys</option></link> to specify a
keyserver to manage public key distribution.
</para>
</refsect1>
</refentry>
<refentry id="output">
<refnamediv>
<refname>
output
</refname>
<refpurpose>
specify the file in which to place output
</refpurpose>
</refnamediv>
<refsynopsisdiv>
<synopsis>
<option>output</option> <replaceable class="parameter">file-name</replaceable>
</synopsis>
</refsynopsisdiv>
<refsect1>
<title>
Description
</title>
<para>
This is a description.
</para>
</refsect1>
</refentry>
<refentry id="recipient">
<refnamediv>
<refname>
recipient
</refname>
<refpurpose>
specify the recipient of a public-key encrypted document
</refpurpose>
</refnamediv>
<refsynopsisdiv>
<synopsis>
</synopsis>
</refsynopsisdiv>
<refsect1>
<title>
Description
</title>
<para>
This is a description.
</para>
</refsect1>
</refentry>
<refentry id="armor">
<refnamediv>
<refname>
armor
</refname>
<refpurpose>
ASCII-armor encrypted or signed output
</refpurpose>
</refnamediv>
<refsynopsisdiv>
<synopsis>
</synopsis>
</refsynopsisdiv>
<refsect1>
<title>
Description
</title>
<para>
This is a description.
</para>
</refsect1>
</refentry>
<refentry id="no-greeting">
<refnamediv>
<refname>
no-greeting
</refname>
<refpurpose>
suppress the opening copyright notice but do not enter batch mode
</refpurpose>
</refnamediv>
<refsynopsisdiv>
<synopsis>
</synopsis>
</refsynopsisdiv>
<refsect1>
<title>
Description
</title>
<para>
This is a description.
</para>
</refsect1>
</refentry>
<refentry id="local-user">
<refnamediv>
<refname>
local-user
</refname>
<refpurpose>
specifies a user id to use for signing
</refpurpose>
</refnamediv>
<refsynopsisdiv>
<synopsis>
<option>localuser</option> <replaceable class="parameter">name</replaceable>
</synopsis>
</refsynopsisdiv>
<refsect1>
<title>
Description
</title>
<para>
Use <replaceable class="parameter">name</replaceable> as the user ID to sign.
This option is silently ignored for the list commands, so that it can be
used in an options file.
</para>
</refsect1>
</refentry>
<refentry id="completes-needed">
<refnamediv>
<refname>
completes-needed
</refname>
<refpurpose>
specifies the number of fully-trusted people needed to validate a new key.
</refpurpose>
</refnamediv>
<refsynopsisdiv>
<synopsis>
<option>completes-needed</option> <replaceable class="parameter">n</replaceable>
</synopsis>
</refsynopsisdiv>
<refsect1>
<title>
Description
</title>
<para>
A public key on your keyring is validated using those signatures on
the key that were made by other valid keys on your keyring.
The option specifies the number of signatures needed if you fully
trust the owners of the keys that made the signatures.
Your trust in a key's owner is set with the command
<link linkend="edit-key"><option>edit-key</option></link>.
</para>
</refsect1>
</refentry>
<refentry id="marginals-needed">
<refnamediv>
<refname>
marginals-needed
</refname>
<refpurpose>
specifies the number of marginally-trusted people needed to validate
a new key.
</refpurpose>
</refnamediv>
<refsynopsisdiv>
<synopsis>
<option>marginals-needed</option> <replaceable class="parameter">n</replaceable>
</synopsis>
</refsynopsisdiv>
<refsect1>
<title>
Description
</title>
<para>
A public key on your keyring is validated using those signatures on
the key that were made by other valid keys on your keyring.
The option specifies the number of signatures needed if you marginally
trust the owners of the keys that made the signatures.
Your trust in a key's owner is set with the command
<link linkend="edit-key"><option>edit-key</option></link>.
</para>
</refsect1>
</refentry>
</reference>

71
doc/gph/manual.sgml
View file

@ -1,71 +0,0 @@
<!--
ToDo
- acknowledge Joergen Grahn for his xfig version of Figure 3.1
- 'inlineequation' marks places where formatting is ok now but not
semantically correct.
- need some story for formatting math
From Tom Goulet (tomg@iaw.on.ca):
> and the <SUP> tag doesn't seem to do much under Lynx, consider just
> using a ^ to show powers.
-->
<!DOCTYPE BOOK PUBLIC "-//Davenport//DTD DocBook V3.0//EN" [
<!--ArborText, Inc., 1988-1995, v.4001-->
<!NOTATION drw SYSTEM "DRW">
<!ENTITY gpg "<application>gpg</application>">
<!ENTITY gnupg "GnuPG">
<!ENTITY Gnupg "GnuPG">
<!ENTITY eg "e.g.">
<!ENTITY ie "i.e.">
<!ENTITY chapter1 SYSTEM "c1.sgml">
<!ENTITY chapter2 SYSTEM "c2.sgml">
<!ENTITY chapter3 SYSTEM "c3.sgml">
<!ENTITY chapter4 SYSTEM "c4.sgml">
<!ENTITY chapter5 SYSTEM "c5.sgml">
<!ENTITY chapter6 SYSTEM "c6.sgml">
<!ENTITY chapter7 SYSTEM "c7.sgml">
]>
<book>
<bookinfo>
<title>The GNU Privacy Handbook</title>
<date>
August 25, 1999
</date>
<copyright>
<year>1999</year>
<holder>Free Software Foundation</holder>
</copyright>
<abstract>
<para>
Please direct questions, bug reports, or suggesstions concerning
this manual to the maintainer, Mike Ashley (<email>jashley@acm.org</email>).
Contributors to this manual also include Matthew Copeland and
Joergen Grahn.
</para>
<para>
This manual may be redistributed under the terms of the
<ulink url="http://www.gnu.org/copyleft/gpl.html">GNU General Public
License</ulink>.
</para>
<para> <!-- I have added this note (wk 06.09.99) -->
PLEASE NOTE, THAT THIS IS A DRAFT VERSION OF THE MANUAL AND NOT A COMPLETE
AND CORRECT MANUAL. CONSIDER IT AS WORK IN PROGRESS. The latest draft of
the manual should be available online;
<ulink url="http://www.gnupg.org/docs.html">www.gnupg.org</ulink> has a link
to it.
</para>
</abstract>
</bookinfo>
<toc></toc>
&chapter1
&chapter2
&chapter3
&chapter4
&chapter5
&chapter6
&chapter7
</book>

44
doc/gph/signatures.fig
View file

@ -1,44 +0,0 @@
#FIG 3.2
Landscape
Center
Inches
Letter
100.00
Single
-2
1200 2
6 600 300 9450 2625
6 1500 300 9450 2625
2 1 0 3 0 7 100 0 -1 0.000 0 0 -1 1 0 2
1 1 3.00 90.00 180.00
1575 1050 2475 1950
2 1 0 3 0 7 100 0 -1 0.000 0 0 -1 1 0 2
1 1 3.00 90.00 180.00
3675 1950 4575 1050
2 1 0 3 0 7 100 0 -1 0.000 0 0 -1 1 0 2
1 1 3.00 90.00 180.00
5775 1050 6675 1050
2 1 0 3 0 7 100 0 -1 0.000 0 0 -1 1 0 2
1 1 3.00 90.00 180.00
7875 1050 8475 1050
2 1 0 3 0 7 100 0 -1 0.000 0 0 -1 1 0 2
1 1 3.00 90.00 180.00
3600 525 4500 1050
2 1 0 3 0 7 100 0 -1 0.000 0 0 -1 1 0 2
1 1 3.00 90.00 180.00
3675 1950 5100 2550
2 1 0 3 0 7 100 0 -1 0.000 0 0 -1 1 0 2
1 1 3.00 90.00 180.00
5175 1200 5625 2325
4 0 0 100 0 14 18 0.0000 4 180 825 6825 1125 Elena\001
4 0 0 100 0 14 18 0.0000 4 180 825 8625 1125 Geoff\001
4 0 0 100 0 14 18 0.0000 4 180 825 4725 1125 Chloe\001
4 0 0 100 0 14 18 0.0000 4 180 825 2625 525 Blake\001
4 0 0 100 0 14 18 0.0000 4 180 990 2550 2025 Dharma\001
4 0 0 100 0 14 18 0.0000 4 180 1155 5175 2625 Francis\001
-6
2 1 0 3 0 7 100 0 -1 0.000 0 0 -1 1 0 2
1 1 3.00 90.00 180.00
1575 1050 2475 450
4 0 0 100 0 14 18 0.0000 4 180 825 600 1125 Alice\001
-6

232
doc/gph/signatures.jpg.asc
View file

@ -1,232 +0,0 @@
-----BEGIN PGP ARMORED FILE-----
Version: GnuPG v0.9.11 (GNU/Linux)
Comment: For info see http://www.gnupg.org
Comment: Use "gpg --dearmor" for unpacking
/9j/4AAQSkZJRgABAQEAUABQAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkS
Ew8UHRofHh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJ
CQwLDBgNDRgyIRwhMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
MjIyMjIyMjIyMjIyMjL/wAARCACxAogDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEA
AAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIh
MUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6
Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZ
mqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx
8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA
AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAV
YnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp
anN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPE
xcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3
+iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiub8Z+MrbwRpaan
f6bqV1Zl9kktlGjiEnG3fudSAScA8jPBwSM5+i/Emx1bxBa6LcaH4g0i7vEka1/t
Sx8lZig3MqnceQvPpx1yQCAdpRXH6V4y1G7+Id74U1HQPsHk2kl7b3X2xZftEIlE
atsC/Lu5OCcjGMV0Gp67o+ieV/a2q2Nh52fL+13CRb8YzjcRnGR09RQBoUVyfi7x
NfWfgO78Q+EhpuqmBDN5jT7ovKQnzGUqcOQFPG4dDySNpuaF4x0fW7XTF/tCxh1O
+tIrn+zvtaNMm+ISbdvDHCnOcDjmgDoKKy9S8S6Do1wtvqmt6bYzsgdY7q6SJiuS
MgMQcZBGfY1qUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF
FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF
FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF
FFABRRRQAVz/AIk8ceGvCPljXNXgtJJMFYcNJIQc4bYgLbflI3YxkYzmjxZ400Lw
Vpy3mtXflebuEEKKXkmZRkhVH4DJwoJGSMivnTxl4Z8X/EB5/Htr4TktLS6SDZbw
ytNPOu3YJQnUj5V6KvylSAw3PQB29/8AHy+1zVLPSfAnh2S5vLhwoOoDlj82VCI2
AAMNvL4ADZAAzXsmh2+o2mh2UGr3v23UliX7TOAoDyHltoVVG0HIHAOAM85Ncn8M
/hnY+ANLLuY7nWrhALq7A4A6+XHnkID36sRk9AF7ygDzf41zXlx4EuNDsNF1XUbr
Utux7G1MyReXLG58wjlcjOODnBrj/B2j6jL8XNI1a1s/GUlnFaTR3lx4qtlLxLtb
b5Up9WYDaoDD5uSrNj3iigDxf/hMLz/haf8AwlH/AAg/jL7D/Yn9n+X/AGSfM8zz
/MzjdjbjvnOe1SfFZtc1PWdHNrpF3Popsmljnh8ORalOJmYZR45sGIbQh6Kc5BBx
8vslFAHgfhNtS0n4UeNtKufDfiD7Xe3E4tUXRmiM32iLYpEacIF2EsB8qgqASSBR
4A0G58I+ILCDxD4Ru9bfUreyuLbVhYPLJpr4VRDJv4iEeOqkEBVyDwE98ooA+ZNZ
8JeKbbVNYg16DWdQnvLiVhfWvhi21EzxH5FcSl90JwvEYI2DGMZr2/4aWs1j8PNI
tJ21IvCkiD+0rcwThRIwUNGWbaAuAoyflA6dB1lFAGXrniPSPDVvbXGs30dnBcXC
20ckgO3zGBIBIGFGFJ3HAGOSK0IJ4bq3iuLeWOaCVA8ckbBldSMggjggjnNU9Z0P
S/EOnPYavYQXtq2TsmTO0kEblPVWwThhgjPBryufwV43+G1vLd+BdZk1bSYULtou
oqZGAA/5Z7cZO5nchPLJwB854oA9korh/B3xS0Lxdef2UVn0zXU3LLpt4hVwyAbw
p6Ng7hg4b5WJUAV3FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUVz/izx
poXgrTlvNau/K83cIIUUvJMyjJCqPwGThQSMkZFAHQV5P4i+LFxq2oyeGvhxZ/2z
q7xSFr1SBDalTgsC4Cv3wxITJTBfO2stNN8afGZEm1dpPDfg6ZIporOMrJLd4bOS
2AcHkgsNv+rIRvvV6xoHhzSPC2lrpui2MdpaBy+xSWLMepZmJLHoMkngAdAKAOL8
J/Ce307WG8S+Kbz+3fEskq3H2iQERwOFxhFzhsHoSBgKm1UxXpFFFABRRRQAUUUU
AFFFFABRRRQAUUUUAFFFFAHJ+M/hz4c8dIjavbSLdxJsivLd9kqLuBxnBDDrwwON
zYwTmuHGpeP/AIWXDrrC3fi/wuqKft0Y/wBItuS0jMCWYgAN94lcbPnTla9kooAw
/C/i7RfGOlpf6PexzAorSwFgJYCcjbImcqcq3scZBI5rcrzPxR8G9IvnfVfC0knh
3Xo0YwTWMhhiLbQuGVfuAqCMpj7xJDdDn2fxQ1rwdqkGi/EzTo7QSI/kazaAvFOE
wMlFBOSQScYI3plFBzQB65RXPt458LLqOmWA16xkuNT3fYxFKHWXBK/eXKjLAqMk
ZYEDJGK6CgAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA
KKKKACiiigAqnqt+2maXcXyWN3fGBN/2e0VWlcd9oYgE45xnJxgZOAblcf8AE7Vd
Y0vwNe/2BYX15qd1/osP2KF5Hh3A7pPkIZcKGww6MVoAj8D/ABP0Hx9cXlvpcd3B
PaortHdhFZ1JIyoV2JAIAJ7bl9aku/GWo2PxH07wxc6BssdS837JqX2xT5nlw+Y/
7oLkYJ28kZ6ivLLHTPEfw88S+FdYtLfWdetH0z7Pc2dtoP2d7W1Y71Rtu5TLvZnI
yGymGbDZro/FfiW8k+Jnh3UYfB3iua10CW+iuJItMLCbzEEatEQcMuRnJxwRQB6Z
4h1y28PaNPf3E1ojqjCCO6ukt1nl2krGHc4BbHXtye1WNJvW1LRrG/eKOJ7m3jma
OOZZlUsoOA68OBn7w4PUVwfxB1q31fwCsR8H65qU2p2k5tov7JLvYzhCqtKrcxsC
5wwBzhiCRgk8J6pf618PG8MW+k65omr2uiLaxXOoWclvGZRF5e5JBnGGwezYOQDg
4AOsn8aeFbW4lt7jxLo0M8TlJI5L+JWRgcEEFsgg8Yq5qeu6Ponlf2tqtjYedny/
tdwkW/GM43EZxkdPUV4fYabo48IW3hnUPhLrjazFshluILJAk8ySA5N4eVjcj5mH
CqxCnABpnjbw34ph8eavqF/FqWo2d26iwmt/DttqoWJRny9jtmEKX25wPMIZjzQB
7/BPDdW8VxbyxzQSoHjkjYMrqRkEEcEEc5qSvO/gxpk2j+CprKX+2Qkd7IYk1axN
o6KVQ4RN7/JuLHIIyS3Hc7nxC8LXHjPwXfaJa332Oaba6sygpIVIYI/BIUkDleRg
HkZUgHH+IvixcatqMnhr4cWf9s6u8Uha9UgQ2pU4LAuAr98MSEyUwXztrQ8J/Ce3
07WG8S+Kbz+3fEskq3H2iQERwOFxhFzhsHoSBgKm1UxWX8G/EVjptvJ4C1DS49E8
Q2DsZID/AMvhxkyAknc+3BIyQVAK/LwvrlABRRRQAUUUUAFFFFABRRRQAUUUUAFF
FFABRRRQAUUUUAFFFFABVe+sLPU7OSzv7SC7tZMb4Z4xIjYIIyp4OCAfwqxRQB8c
eMPh54p0u8uNRfwdPpmmvvkSG1lN2lvGgGd8gZiOOSzYB5wABger/B74w/2r9n8M
+Jrn/iYcR2V9I3/Hz6RyH/np6N/F0Pzff9wrj/H9h4G/sd9R8aWlj9n+SAXMsZ87
725URk/edcnC9t2eM0AdhRXl/gXx1qnjrxGBotlPZeEdNiCvc3i+ZPdS7MCIuXOM
bg5I3N8g3MPMxXqFAHn9/wDFjTv9JXw9oeueJPJ3x/aNMsmktvOGf3Zl/wC+TuUM
MMCM1n3/AMVrhYPCev2OnQJ4V1i7NpdXN9MI5oH3sgJAJVVGxnzlsgEHZwTn+Dtc
134caDB4V1rwVrl59i3mC90eIXcdwrSyMScbdnUYBO4jkheMx+Pr6bVPD/hC2XwR
rPkQ6nDfzabDpxmWKzjLosbhRsDshB8r+HkNjjIB6xpurabrNu1xpeoWl9ArlGkt
ZllUNgHBKkjOCDj3Fc34N8Zaj4j1jW9J1bQP7GvtJ8jzIvti3G7zVZhyqgDgA8E9
e2K5PwncL4a+IfjloPCWs2mmzpG1kttpTLFKbaNw6ptG3LnJToGz1BIBr+G/FlzZ
fEPxPrF14N8XRWetPZLC50hyYRFGUdpACTjJz8u44HTPFAHqmp67o+ieV/a2q2Nh
52fL+13CRb8YzjcRnGR09RVj7fZ/2d/aP2uD7D5Xn/afMHl+Xjdv3dNuOc9MV5P4
j07+yfihqes+IPBl94p0y/tIo9Pe0tvtv2PYAHjMTfKu5stu+uM7nxzk/gnxoPhl
ZpaW93aWJ1iTUG0JQt08FmQrorJKR5hRkY+TzvMgLAMCAAe56Zruj635v9k6rY3/
AJOPM+yXCS7M5xnaTjOD19DWhXz/APDvRL23+Jmm6lJbeI7X91LDIH8Lx6bbOmxy
BI0Um372CMqckKOwx9AUAFFZ+t6V/bejz6d9vvrDztv+k2E3lTJhg3ytg4zjB9ia
4/8A4VZ/1Pvjn/wcf/YUAegUV5//AMKs/wCp98c/+Dj/AOwo/wCFWf8AU++Of/Bx
/wDYUAegUV5//wAKs/6n3xz/AODj/wCwo/4VZ/1Pvjn/AMHH/wBhQBqJ8TfBbazd
6S/iC0t7y0d0mW63QKrI21gHcBSc9gTnkjgV1EE8N1bxXFvLHNBKgeOSNgyupGQQ
RwQRzmvli6+CfjTVvFWofZ7WQWD3twI9R1O5XdIquwDuBlyWxnOzncD0Oa7fwl8A
dS0a4ivbvxhd2M7IyXEejFomK54AmJBxkISCnbHoaAPdK5vxn4ytvBGlpqd/pupX
VmX2SS2UaOIScbd+51IBJwDyM8HBIzsaVYNpml29i99d3xgTZ9ou2VpXHbcVABOO
M4ycZOTkng/jXNeXHgS40Ow0XVdRutS27HsbUzJF5csbnzCOVyM44OcGgC5ofxV0
3XPEFhow0LxBYT3zzJBJf2ixRs0IYyDO8nKlSpABweDirmleMtRu/iHe+FNR0D7B
5NpJe2919sWX7RCJRGrbAvy7uTgnIxjFcH8OJtS0fxPa6XaeH/ED2d9e3t1eapr2
lNFPErxoVQShyCWaEb2IG47eAak/4TC8/wCFp/8ACUf8IP4y+w/2J/Z/l/2SfM8z
z/MzjdjbjvnOe1AHrmpatpujW63GqahaWMDOEWS6mWJS2CcAsQM4BOPY1H/buj/2
P/a/9q2P9mf8/v2hPJ+9t+/nb97jr14rxv4l6J4kv/GMOuompX2gy2SLaRRaFDft
au2CyG2mYFSdm4yFQRkIelUPD+lzaX8PvHFpNpHie9Opoot7G48PG3UXDiTDxRI7
qApCMSAoXYgGTtFAHt+m+JdB1m4a30vW9Nvp1Qu0drdJKwXIGSFJOMkDPuKjvvFn
hvTLySzv/EGlWl1HjfDPexxuuQCMqTkZBB/GvH9Esv7P8R/DK6tPBGq2cltaSRap
PHpXlkyOn2cNKw9GVnJbkI4bqSKyPHlh4n1PxH4k+1aDfGR5ZIrQ2XhSC7SaEIFi
Y3RPmKxGMkZKdsEbQAfR9Fc38P3mb4faAlxZXdlPBZR28kF3EY5FaMeWSVPIBK5H
qCDXSUAFFcfrfgD+29Yn1H/hLfFdh523/RrDUvKhTChflXacZxk+5NZ//CrP+p98
c/8Ag4/+woA9Ark0+JvgttZu9JfxBaW95aO6TLdboFVkbawDuApOewJzyRwKy/8A
hVn/AFPvjn/wcf8A2FeKXXwT8aat4q1D7PayCwe9uBHqOp3K7pFV2AdwMuS2M52c
7gehzQB9TwTw3VvFcW8sc0EqB45I2DK6kZBBHBBHOakrwvwl8AdS0a4ivbvxhd2M
7IyXEejFomK54AmJBxkISCnbHoa9o0qwbTNLt7F767vjAmz7RdsrSuO24qACccZx
k4ycnJIBl+K/GOl+D7O3lv8Az57i6lENrZWieZPcOSBhEyM4yM89wOpAOHpHxPh1
PxZZaDceGfEGlvfoxtZtRtRCJGRWeQYJ6BQuCM5LcgYBJ48sNXi8T+FfFOm6ZJqc
Givdfa7WBwJzHLGFLRqeHICn5Qck7QOpI5PTtV+IfiTxp9msr7xHpekT/aZXfUfD
9vbizXB8lVZt3m4YqCOGIBPqVAPVJvEug22qDS59b02LUC6oLR7pFlLNjaNhOcnI
wMc5FWNS1bTdGt1uNU1C0sYGcIsl1MsSlsE4BYgZwCcexr5gn8H+IVsJdM17TPEB
vHcvcy2nha3vmZmffkXgkDuTkZOeMlegr0PXNKvLfWPCGv614d1XxTo0OiJaSWrQ
GW5guiu4zS2zEgswwrZJwRycqmQD1yHVtNudLOqQahaS6eEZzdpMrRBVzuO8HGBg
5OeMGvN/DnxfvPFOs2drpvhu0NpdXBRHk123W4WIMQ0ht/v5CgttGeBwSOar+DdK
Wx0vxjrGo+E7u28N6hcRzWXh17Vp5SUyGb7NghS7bCB0XaOQiq1U/hAlnplno2lX
/gHVbTXY/P36xPo4jRcmRhmY/MMoQnTvjpQB0njP4pxeGfEqaDYafaaheLb/AGi4
NxqsNkkIJAVd0nBcj5tvBwVIyCcdh4c1O71nw/Z6je2MdjPcIX8iO6S5ULk7SJE+
Vgy4bI9a8j1yPS7b4v3upS/DrVdU0kae1tJ5Gg+Yk12Zt7TAMAG4JXf1PbIIJ9k0
l4ZNGsXt7KSxga3jMdpJEImgXaMIUHClRxjtjFAFyiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooA4f4ifDu38a2cV3aTfYPENjh7G/QlSpB3BGI5255BHKnkd
w2f8O/iJcaveS+FPFcP2DxZY5SSNwFF2AM71xxuxyQOCPmX5chfSK4f4ifDu38a2
cV3aTfYPENjh7G/QlSpB3BGI5255BHKnkdwwB3FFeb/Dv4iXGr3kvhTxXD9g8WWO
UkjcBRdgDO9ccbsckDgj5l+XIX0igAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiio554bW3luLiWOGCJC8kkjBVRQMkkngADnNAEd/N9n065n+0wWvlxO
/n3AzHFgE7nGV+UdTyOB1HWviTUrvWvF3ipYrjUZNY1C5uBbQSs5CyFnO0JvC7EL
NkDCgZ6Cvc76+1T4465JpWlST2HgWxlAu7wLte9cYIVQfwIU/d4dhnYg9csPDei6
Xb6dBZ6XaRJpqMlmfKBaAMMNtY8gt/Ec5bvmgCn4L8J2fgrwva6LZv5vlZeacoEa
aRjlmIH4AZyQoUZOM10FFFABRRRQAVy/j/xZceCfC765BpX9pRwyok6faBD5aMcB
8kHPzFRgD+LPQGuoqnq2mw6zo19pdw0iwXtvJbyNGQGCupUkZBGcH0NAElhfW+p6
dbX9nJ5lrdRJNC+0jcjAFTg8jII61Yryv4H6lNDomreD7tYzd+G72S3aSEHY6s7n
IJOSd6ydhxt75r1SgAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigAooooAKKKKAOH+Inw7t/GtnFd2k32DxDY4exv0JUqQdwRiO
dueQRyp5HcNn/Dv4iXGr3kvhTxXD9g8WWOUkjcBRdgDO9ccbsckDgj5l+XIX0iuH
+Inw7t/GtnFd2k32DxDY4exv0JUqQdwRiOdueQRyp5HcMAdxRXm/w7+Ilxq95L4U
8Vw/YPFljlJI3AUXYAzvXHG7HJA4I+ZflyF9IoAKKKKACiiigAooooAKKKKACiii
gAooooAKKKjnnhtbeW4uJY4YIkLySSMFVFAySSeAAOc0AE88Nrby3FxLHDBEheSS
RgqooGSSTwABzmvE76+1T4465JpWlST2HgWxlAu7wLte9cYIVQfwIU/d4dhnYgL6
+1T4465JpWlST2HgWxlAu7wLte9cYIVQfwIU/d4dhnYg9k0rSrHQ9Lt9M0y2jtrO
3TZFEnRR/MknJJPJJJOSaADStKsdD0u30zTLaO2s7dNkUSdFH8ySckk8kkk5Jq5R
RQAUUUUAFFFFABRRRQB4/wCLv+KI+NuieLW/caRrMX9n6jMOQJMYUuz/ACxrxCcg
g4ic4659gri/ir4XXxZ8PtRtFjke7tkN5aCNGdjLGCQoUEbiylk7/ezgkCrHw28U
N4v8B6bqs8kbXmww3e11J81DtJYAAKWAD7cDAcdsGgDrKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK
ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA4f4i
fDu38a2cV3aTfYPENjh7G/QlSpB3BGI5255BHKnkdw2f8O/iJcaveS+FPFcP2DxZ
Y5SSNwFF2AM71xxuxyQOCPmX5chfSK8H/aH0XVNR+wXtl4b8+1tIi0+qw/PIo+Ym
NlU5EahSxZgQC3BXncAe4WN/Z6nZx3lhdwXdrJnZNBIJEbBIOGHBwQR+FWK+aPgD
46TR9Yk8K3xxa6nL5lrIWVVjn24IOcE7wqqOT8yqAPmJH0vQAUUVX+32f9o/2d9r
g+3eV5/2bzB5nl5279vXbnjPTNAFiiiigAooooAKKKKACiio554bW3luLiWOGCJC
8kkjBVRQMkkngADnNABPPDa28txcSxwwRIXkkkYKqKBkkk8AAc5rxO+vtU+OOuSa
VpUk9h4FsZQLu8C7XvXGCFUH8CFP3eHYZ2IC+vtU+OOuSaVpUk9h4FsZQLu8C7Xv
XGCFUH8CFP3eHYZ2IPZNK0qx0PS7fTNMto7azt02RRJ0UfzJJySTySSTkmgA0rSr
HQ9Lt9M0y2jtrO3TZFEnRR/MknJJPJJJOSauUUUAFFFFABRRRQAUUUUAFFFFABXj
/gr/AIoX4w6/4Qn+Sx1r/iZaWqfLGv3iyLGuQvAZcnbkQDjlQPYK8n+NtjcaXZ6P
460mPbqeh3aCSQMFDQOcbXxhmXeVXaD0lfjkkAHrFFV7C+t9T062v7OTzLW6iSaF
9pG5GAKnB5GQR1qxQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR
QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR
QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB5X4z+CWkaw6al4YaPw/rEL+aj26lYn
ZVGz5VI8shlU7kHGWJDEjHcaXbavf+DlsdekktdUe3e2ubizmG4sMp50bBQFLACQ
cDbuAxxW5Ve/tft2nXNn9ont/PieLzrd9kke4EbkbswzkHsaAPC/D+ja1ffB/wD4
TZPHHiePVre3uLxY5L4y25MEj/KY26grHjkkZPII4NzXEv7/AMY/DXxPoVnpUHib
WdPmlne5EiwSEWyH5gpLcK7gHr90EkAY6SD4JaLDYRaY/iHxPPpKOGbTZNQAt3Af
ftKKg4Lc8YOeQQea3L/4d2F/4o0rXf7V1W2bSdgsbK1ljitoEUAFFQJnawGG55HG
cAAAGfonjq/ufA3iTUtaOlWGpaJd3VjJNuk+yNLGBtbH39pZlXAyx7ckKOb8FfFz
VNd8b6doV3ceH9QgvkmHmaXFdRNAyIXBbz1AYEKRgfXIxg9JZfCPR7XR9a0mbWNc
vbHWPnuoru5Rv324MJgQgIkyAckkNgbg2BgtvhPZwa5purzeKvFd7dadL5tv9r1A
SAZxuXlM7WAwwBGRxQBl6r4t+I1t4/uPC2naV4fvHlt/tlpLvkQQW5n2B5ssNxCg
5VBnLAjOCpk1nxJ8R9M1zw1oaR+FGv8AV4rjc5W4MSyRbnODnIUxmPHBO7d0GK0L
/wCE9nfeIbnXP+Eq8V299PvXfb6gE8uNnL+Uh2ZEYJ4XOBWpqfgK21bxLomvXWta
z9s0hFWERzoiSEHLs6hMZcfK+3aCABgCgDg/Cvxe1vUrG+l1xNDslbRJdUsrkeas
cZSZoAsq5YtucDAQ5xgDJbAk8FfFzVNd8b6doV3ceH9QgvkmHmaXFdRNAyIXBbz1
AYEKRgfXIxg6i/Arw35EdvLquuS28Vo9msRuI0Xy2dpADsjBbEjeYNxI3BcggYrQ
tvhPZwa5purzeKvFd7dadL5tv9r1ASAZxuXlM7WAwwBGRxQB6BXz/wDEfxV/wlHx
FHgXWtT/AOEc8O2sqfapHOXvGO1lyVyqqdwI3EKv3m5AQfQFZ+s6HpfiHTnsNXsI
L21bJ2TJnaSCNynqrYJwwwRng0AGh2Ol6dodla6JHBHpiRKbYQNuQoeQwbndnOd2
TnOcnNaFeT3Pwj1Tw9uufh74rvtKk815fsF5J5toxbC9MHGFzyyuTheQRmo4Pit4
j8L3EUHxH8KyadBO4Eeo2A8yBNxwFYBmGQFkY4YtgDCd6APXKKx/D3irQvFdmbrQ
9TgvY1++EJDx5JA3IcMudpxkDOMjitigAooooAKKKKACiiigAooooAKp6tpsOs6N
faXcNIsF7byW8jRkBgrqVJGQRnB9DVyigDyv4H6lNDomreD7tYzd+G72S3aSEHY6
s7nIJOSd6ydhxt75r1SvF/G99b/D3426N4rnk8jTNYtHtdQMamR2KADcVPRRm3Py
c/u24Ofm9Y0TW9O8R6PBq2k3H2ixn3eXLsZN21ip4YAjkEcigDQooooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooA871v4N+HL6//ALU0WS78Oaoi
OI7jSpPKUMU2glBwAB1CFN25snnNYf8AaHxa8C/ubrToPGGkQdLmAlbtk+4ikD5i
wwrMdkn3jlz1HsFFAHD+GPi34O8VSw21rqf2W+m4W0vV8pyd20KDyjMSRhVYk56c
HHcVzfivwH4c8Z25TWdOjknCbY7uP5J4+GxhxyQCxO05XPJBrh5vBfj/AMDuJ/BP
iCTWtPRFQaPrD7iqqoVQjEgADczYUx8Ko+bpQB65RXlem/Gi00+4bS/HmlXfhzVI
kJZmieSCbBC7k2gtgsHxgMuF++a9Msb+z1OzjvLC7gu7WTOyaCQSI2CQcMODggj8
KALFFFFABRRRQAUUUUAfP/7QPgD/AJnTTo/7sephpf8AdSJ1U/gpwf7px941ufs3
zwt4F1O3WWMzpqbO8YYblVoowpI6gEqwB77T6V7BPBDdW8tvcRRzQSoUkjkUMrqR
ggg8EEcYrzf4deCz4E8a+KbCJJDp9+kF1YusMmxIw0oMTOcjeu5RgsSwIb1AAPTK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAr
31hZ6nZyWd/aQXdrJjfDPGJEbBBGVPBwQD+FeZ3nwaXSXnvvAniDUvD94zpILfz2
ktZCinarg/MQW5JYuACw2kHFeqUUAeP/APCxPHPgj/kffDH2nTE/d/2rpWG+78u9
1ztG9imM+V1OAfuiSP8AaC8LnxZNp0qSLo4TMWrLvYM20HDRbA6jO5cjPIHGDkeu
V88az+zjrEu+6s/FMF/fTSl5jfQPFuzksxcM5LZx1HOSc+oB9BwTw3VvFcW8sc0E
qB45I2DK6kZBBHBBHOakrw/wj4S+KPw22/ZvsPiHTGzG2lR37J5edzB0aVVVPmPO
M7t3I6MvsF9Zf25oclrM99p7XMQyYJ/KngY4PDoSAwPoSpxjkHkA0KK+YPAq+JPG
9wNLi8WeK7O/fTxeLdT6jIIDtuvLkKJ1kXyyMfMv7xGBODx6n408W+OtA8Z2OlaP
pWjalb6qkw0+Eu6T7o4gzGRmYIAGbOB1UYyCc0AemUVwer+I/EvhbwHe6l4kvvDF
pqwuFS1dRcNaspK8MoBkZ8eYcKDwAegNY/w2+J2oeLfFV3ot7Jo12iWX2uO60tLi
NVIcIUZZgCT8wORgDHfPAB6pRXibfEn4g2Wia1r15Z+GJdP0PUzp97DD9oSWVldE
byySQAd4wT7/AC9j2ninxT4gj8W2XhTwpY2MupyWhv7i51JmEEUAYoOEO4sXAHHT
I4OSVAO4org9Kv8A4lXNv4gtb2x8Pw6haPAmn3AWcWs5YBpc5O8hVIAIAG7I5wcS
fCC4iu/hbo08NlBZRt5+IIC5RMTyDguzNz15J6+nFAHcUV4f4q+LnivRvEOo2EVr
odj5V2YLK01OG5Sa5j37BMJPlhEbHccllAAPJxk+4UAFFFFABRRRQAUUUUAFFFFA
BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA
BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA
BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVn63pX9t6PPp32++sPO2/6TYTe
VMmGDfK2DjOMH2JrQooA5PwZ4CtvA6PBp+tazc2bJtWzvZ0kijO4tuQBAVOS2cHB
zyCQCKfiH4ZWfiPxGNcm8R+I7S6j/wCPdLO+EaW2UCN5QKEpuA+bB5ya7iigDl9V
8D2et+F7LRNR1TVZmsZY57fUftAW7SRCdr7woBYAkZKk9/vfNWXpfwuttK8QLrie
KfE9xqCW72yy3d6k3yMDwd0fIVjvAORuAJBrvKKAPN/+FM6O2h6hpEniDxHJa6hd
peXO+8QmSRd2SfkwdxYFsgklEOflrY1r4c6XrkWkyS3+q22p6ZEIYdWtbnZeOm0q
Q8mDuzkk8dScY3MD2FFAHDp8M7ePTprdfFPisXU0sbyah/aZ+0siBwsW7bjywZHb
GOp68CpPCXw4tvBlxE2neIfEEtpGjILC6uke3wxycJsG07ucrg5z2JB7SigDzf8A
4UtoXkfYf7b8R/2N5vmf2R/aJ+ybd+/Zt2525993fOea9IoooAKKKKACiiigAooo
oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo
oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo
oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo
oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo
oAKKKKACiiigAooooAKKKKACiiigAooooA//2Q==
=ao7I
-----END PGP ARMORED FILE-----

624
doc/samplekeys.asc
View file

@ -1,624 +0,0 @@
pub 1024D/621CC013 1998-07-07 Werner Koch <wk@gnupg.org>
uid Werner Koch <werner.koch@guug.de>
sub 1536g/ADF6A6E1 1999-02-20 [expires: 2002-11-01]
pub 1024D/5B0358A2 1999-03-15 Werner Koch <wk@gnupg.org>
pub 4096R/99242560 2002-01-28 David M. Shaw <dshaw@jabberwocky.com>
sub 2048g/1643B926 2002-01-28 [expires: 2012-01-26]
pub 1024D/B2D7795E 2001-01-04
uid Philip R. Zimmermann <prz@mit.edu>
uid Philip R. Zimmermann <prz@acm.org>
uid [image of size 3457]
sub 3072g/A8E92834 2001-01-04
pub 1024D/57548DCD 1998-07-07 Werner Koch (gnupg sig) <dd9jn@gnu.org>
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.6e-cvs (GNU/Linux)
mQGiBDWiIPMRBAC2D3tFzbD48fop00PiM8+du2SZ6HOgYVopP+Gtm2WBDUjkFwDC
kw0DL9pS3iNIunHgfeuzDbm4R3lXTXjlmBxUjNVBkX4ZmRESEoaN26fsFWb1RvBg
VcKcN+DyY4GFP9LQ8JyWifAc1+o9HnE0k40D52lBLXSf7v4JhvY9NtfE8wCg4oXT
aCiRFPSClIko3RqJkrnpv1cEAKx32rnEog5mPPs8mW1Sy5yulCTKrbCL9S7wINtM
cF6FJNm2PB97Vy+FGfGHKEl2KM8AC6t3CKOVGSdKvTn+9ZiPFiytohUmFaZaU19F
jApQHZBrdx4FW+8bToRrdZhCnkUIzWdi7XlEK0Qw/TE0Pl8XLxDdCKQI+JASXvW0
eh8wA/4nnAphsEpR1GWa4Kls7+/KO/V8Q3XLi3ZeItny+5MBDn/Y7A3u4RrNu8q3
SRJgBvUBfUzhfSyRZhNQqpIFvhKSsbGNNVo5tARSQdUe4j1GlLRUWcWKn4F2q5j4
6pdogYvnFYy8xrvuAUqI1QD4D/4YXJyKMH+DOHnT4iAjD9RlY7QaV2VybmVyIEtv
Y2ggPHdrQGdudXBnLm9yZz6IRgQQEQIABgUCOdeQqgAKCRBd4kmWWwNYouphAKDJ
YHGt9SdQTwe0FODk/1aOJap13QCdF/Y83Ku5blk0l7p9H8cicg+JPySIVwQTEQIA
FwUCOhpQtgULBwoDBAMVAwIDFgIBAheAAAoJEGx+4bhiHMATm7kAoMBBag8scWbt
Xcs7lhrjQOIzd2onAJ4oIuIPWnArE+6EOQBk8vceoMb/lbQhV2VybmVyIEtvY2gg
PHdlcm5lci5rb2NoQGd1dWcuZGU+iQFfAwUQNaInDgNvEbj/PqoLEAMH3AUfSLqa
afqtZgoV6kmFfKETjBapE8kCe9+iJZSe0OnhohDKzqU5GKBVchajiThIr8Ufn1if
MXvnvyqtNlb9FwDRsiomrOpqqw51NgQVrj1wKO8ucFbg55smUtNSz+eeZTQVYpbw
7DAv6kK7x3t8tJKeCAGytRDBt6m7DRwmhy0U8DPlPWdAmJ5ApWwdoI3AvZ27Rd58
6AXm6MHWMrWrenhTKwX2ERwFH2W0TdMev6K/iO1leYLU/hq31bksVaxi7CvRTfIl
xopIqnS//AYRZ7Yn+AVBnSEHX7flGsJk+CJawS/zsIdobpe1D7ceGKsEImxiGY6K
RUqgRqfo+FRVHWqVcTK2kC3fz1MGe/Jx4BfyFwc4Td2K4a8gsSBh6zeDDezlmYzt
tRfeObYGtfxZyF7FQVRAi4pbZwvfv0wVdHxNvGlXGuxFgT/iMdkFiQB1AwUQNaN3
FB0Z9MEMmFelAQE98wL/RzGj7jFhUCmUU7SchjKNCA/sPw7S5/M+wjAXeS9vtvkU
02N+n4MCE3obQc4iCQvcaxa0J8flQdqWL6a00UgoOlO2v4X+U+lk/c4/POwtlLiF
hOqYyzU78AKrxrEqACKViEYEEBECAAYFAjvjfbkACgkQH+0kqpJl+vsaiQCdF17S
Tq6vDmL904W0mD0m3m66ZOkAnjXUF+7U4s14zHRn+oR/DTG+yKI8iEYEEBECAAYF
AjnPUbEACgkQNfZhfFE679kjigCfcLUFU4HwC2iqbCUxcIHoCg2xFPcAn2x8nlUi
2uXjwgT2OA5sifc3XQq2iEYEEBECAAYFAjlqZ8EACgkQRxYpGYKVe2ahiACdHELx
vEtYuKiUAuP7N2p6PB+s6R8AniXxK1c1qIsyN8S3D4hv5ygXQApOiEYEEBECAAYF
Ajiy8lYACgkQSBf5O8XogRIOMACgpDCmckpZHGgzyzgdGb/q+YrAtPEAnjDbzLSt
tKJxIQDqVQwZf/qZOF9HiEYEEBECAAYFAjbtTgsACgkQXeJJllsDWKJ8mgCgsSwb
LXqFX8J+YOS7oPUIFQjFe+kAn0YECl0L/c5eKDuwGtUJY5vcxDNwiD8DBRA3blnc
ZKpl/bHMA6oRAulaAJ9dQ/nN1j/mr7DdbZiVjg70OC1cSwCgsn1NrNKqoCoCU3TP
mcjvDFxoWS+IWwQTEQIAGwUCNs8JNwUJCCCxRAMLCgMDFQMCAxYCAQIXgAAKCRBs
fuG4YhzAE2kgAJ92JKU+YcYHoRhX51+4s3fnPIyNEgCfaiWeoyb15xgdO6etGiD2
MYCWy5m5AY0ENs8HCBAGAPc1hCpuXmaTDAUbIqS9CFHkihMnilIwAV+L2Dbq5eOP
toemPKx5+6xtZfzzY9/VCVwZCxY9Y5PEN9r/twUA478L/FOXv5E4BpX+4R91klt/
EZGcNfDl2Ar56FpGJ3iLg4+vxx9m1TV5k2nNOUZAVD1L+MoapWhaZFXLMChrhDUc
bo7/1Fr1Rfv9j/LkkIJJhqf3G8HzE5AvCQVSywUayYZdbmqdiY2bklZJVFAXs1X9
zSTGoFc8eOxz6i1ZeMq+GwADBgX/T7o5R+SOTlJ72ac/g121f1kFX1dbRkQq2pCI
95qTehp1AxdSwG3ur2slFCfi8ZDNUqkFXJrsv5mh1yfqq7zS5T6lGT5lOXCDZbAO
2wqNZY1VKeeCdcvD2VMeh8XxJfy8y1ZK/iE1p8qnokYpA3nFH+JIsdrXk5ceiN3n
Kk+aDamUkV1sJzeEm5F7QHe60oBKbVGIUF4EhGq6daVyeCeK4KhWuPYyiEgyaq5/
xJZbR3uRcdW6X5AiGJWJOOQoGvWziEwEGBECAAwFAjbPBwgFCQbzyQAACgkQbH7h
uGIcwBN5FQCggakIOYzLX3lNq2WWgcAkSNm7kpoAnA69b3z2E5vxyD3bhggVUDX7
j8hrmQGiBDbtSOkRBACURhKnGIFyXIeX61GAY9hJA5FgG4UalV55ohdz4whBgDzD
GLE3XYlO8HCn4ggKilll6MOwY0yZeg6PEU9Y3SqTzpQSV6qj2M7MgcS8xOpi6bNC
u0iyZUik0KklUXMdI8e/CVmBpQJT9CofbD1dsP6z4dC6z3jil0+5Wbfw6yIXzwCg
y/7Fagq5mN0H760/JEiiXILS1n0D/3H26lTaxo1vGput9Td1FQN7Vn6YDP0/To5i
psOODROV3zyUwF5QleY+8zTFJA3qD5KxRfA726WELOF1mB6Mw44UdkPniOoGdMH5
oSx6qnNnlVZBBu3U+e1qfQwLQjHu0WX4Z2q00DKpWLThGv7Loh5NKi6OfTbMhfHo
evCAzQnmA/wKc6J8GqthENThKXxZaei3Ep0t+PlBmbUzuAYCXZhI6/0KyD6emyQ7
LYIaPv9qEfMkMLhxicG0v/AAwOCBRKS3bkqc6wAYaO0bjUHJvem3HkWPux82t83+
6YPyRnVjm/mwt0uEyKSvt7Md2DVrO3lEcKRkRHiYuf0nonPhl5Rs5bQaV2VybmVy
IEtvY2ggPHdrQGdudXBnLm9yZz6IWwQTEQIAGwUCNxrPkAUJDMl8gAMLCgMDFQMC
AxYCAQIXgAAKCRBd4kmWWwNYol3CAJ47+zjeQIsMwiwcJvYfcsLn1yULlQCfUTKu
paT6pw5culAis/pBrdBKZciIRgQQEQIABgUCNxrRPQAKCRBsfuG4YhzAE4X0AJ43
A7wbYbR6LTfPSD+fdBkimNvO8QCdFoSpfY+4FsKVagg/qH3KtGUARtSJAHUDBRA3
GtFjHRn0wQyYV6UBAdGuAv9AM0o9XkmBbOLLNse8Qp9MjD8TC/oSXYxp1W9AjyRs
83iqQ+vaZlbA/O5z2ud4I9DV4vwA50Lz5nLFbPHa+yuT8VxTl2icw5u9rZy3iSok
3rGXzGOzENMmEFIVFqIEmPGIRgQQEQIABgUCNxrRowAKCRBot6uJV1SNzS34AKCE
rfsfa9Nh5deJ40nxpmSI8lK17gCfRYcU6i1B1Nbg2Zkkr5SqTnBtaWCIRgQQEQIA
BgUCN08fXQAKCRD27t8gGEvE2S2+AJ4udDl47EAnP4K+RvsWcv8qjqpzlgCeOFZZ
blzWjeie8oQfYl7bBBrxPqKIRgQQEQIABgUCN6cm/gAKCRCYNGXbIUOUIn7JAJ9L
LXMt+0R8u4gdmxQeKz1TQyWoswCfYQh/tMjUzk4rKxBy4UtELnwJ9x+IRQQQEQIA
BgUCN+FBMwAKCRA2Z2DxfS7XiHnnAJ93k5kJXcvwCGLhBb8mhdRT5kHQzQCY97a7
DtZgMs7O/jwfvq2bpzL3nohGBBARAgAGBQI4KmIPAAoJEOPyWFQSjw55Gx0An0Ue
6lGJsE8ba3/hcOoX7GIwsv/wAJ9XkXZJHQhMTiT8L6xxLWcnUplQNYhGBBARAgAG
BQI4PoQFAAoJEDy4klAvo7wt7aQAn0CBYasE7gZZZ7lDpIDGuq7pV/v2AKCpZLWB
dON2nqkq1MOIkvxNo+I8BIhGBBARAgAGBQI46dJKAAoJEE3WcVrMxTeC+m8AoMKb
rmutaoALaWkjmB1+31rex+O5AKCp/Ki0pDcTZBmCDd3jd9cE6u0qjIhGBBARAgAG
BQI5Kja7AAoJEIG908QOH5t5ZekAn2uNClagsId37o8FesrYI0S8x+gNAJ93DOXd
KR8kjoD7ft0rs04pj9rlE4hGBBARAgAGBQI5KnG3AAoJED4gT8kqkIcsTW8AoNSH
nitUbZpwTUzEHSxC+nfZRvIGAJ9bPJqRoloYIvsBZWiN5Log3A4zH4hGBBARAgAG
BQI5LjG8AAoJED2K8bIJrApqqE0AoL3BDQMJ3/ZQwwQq3I4qZvlGOFYcAJwNEQDy
LsZGAt3GHJeBpJGwAxm+v4g/AwUQOS4q0J6y5PNpFshzEQLgTACgilmE66iRYTSJ
nkJZPl+W9cXNaGsAmgM6Uf8sn9EnYbnThlMHgGx5E6KfiEYEEBECAAYFAjksKEYA
CgkQs+2ENZ0bx8g7MwCfX/8HTK842/fulLtfElcW0RW9a8wAn18MUa7KTA79a6EV
Krqa3qNLt2v1iQEcBBABAQAGBQI5Kv6BAAoJEAWcfuLwhsu1Iz8H/3KXi/WE7Oe1
Huw2h0A1JGyl+zKI23po+RenuSKC1NX821NRyrIN1U6CKzyBdMKeiWd4/bNaD9vQ
Ft3SKK4CgjRqs694TV1ue1c5+iY3TtjTSR2vAyxACScl6csIm4TAJXuSMDSeuE17
1QsXSJa5CEXBSnHTOPd5B+47hAr+0G16fgWFH9WLjZNA8s3JBZNg69hQSDiZC1FI
oP0SuBUJk47hmZpjIzNGKGRxWzfK82tAk3eS1smnq+V1LvDLWJXkG/XVJeX5SsT6
WyIBcXsq9eMk/t8mDyVxE5SbCFu7TNIMEL8f49bEQk77xf+t/5nzDOY1iA/q2H1l
o/0ncauofCyJARUDBRA5Lpn1EcKB1QApK4EBARqvB/9Nk6Edg2z5stFyag8CqlOc
iVURGdZpH/kR/OtlZkIHva4fgF9chC2F/wd2rMfoG/Begl1jvt4aOAR2Eq/qECHl
kWeMIMr4yWVJqhYg7WT+dir2MsZOcS5FRpzMyVDuauY/KmBQKE7Eg1J7mVI9CgRZ
TvkkQusDh85pUhOla7b2n4QLCrbicLpC/MBlHE1nfcxDEiYxwA+rJSTnLg8wI+7q
OX6fqjd3zV3LgKd9HwFZ7ws8Hgaog35HJpIFfev/cOpcFMOl42cQxZII45wcQT4j
I32lwSjAOMWYMbAUSIEjDs1Sfowkcu0cvtTZTDly0UvTJjQ+OjDe0+oJOofrmKuf
iQCVAwUQOUX4pCt4HizjmvPpAQE86gP/Yf56qY6Qe5nCOa1ex73/ZMPvOELl7yKT
ohPZRxPWHsy63Ff/CyC6A6dPZfNiUdfxYO4BsitGh76unRmeFjf/awwWjfOqvx62
bYpWMb7E4QQt2KesNjgK/yNaVHPGtsKa4E2gWo/+rWQHgfq14igx8w+KOoyqRhUZ
N019GyLMN+qJAJUDBRA5LpoJe390GVLRyrEBAUxgA/0dWRrv3KBVNJXHtYjDlHH1
zBh+x7i8TI2aAPEN2bz3zWI9XWiknNudVm7xtsp61iMJ/xXvlD0Jasxhk8/JHRPa
wNO8kWR3UfKYsnIR7WBxrlNNBic3MTMrUCyRszLqGA2d8nJqHQ5HBNkhT3sZJFzm
0EshmypsmN5bbkTquvTYiYhGBBARAgAGBQI5Mb/DAAoJEL1YtpICkSxThskAoKv3
X28MpPW09UhfjuQ9rexmubuRAJ9EJLu2mUpM7BdXKi10HmC0ui4m/ohMBBARAgAM
BQI5Ln4fBQMJZ1MAAAoJENeMvOVmp0sxywsAoLtChkYFfkT2YJGGmfrW24orSShr
AJ97CvRlJ3C5VFlnME/r3feAmv4Di4hGBBARAgAGBQI5So3XAAoJEFy3t/Kgqlwe
CicAoO+D5CGVRJIto2n33aXYU1yuxhiEAKC++kE+wyq5BAbi8YX0BAUxfRXtmokA
lQMFEDljXQjvbYJB8IEZXQEB1d0D/iNMwOG2MJMrziMiIokV6UvbgqtG3AEltb5E
8CGTS3wO8cbqrx+yIv3ZKLn3HAR8vt5KRkQe7qxi/hFaIpPuMXky85TrbXyZGvib
Y0siHFyrAem/jP/EVU04Bl59nLbBRF3vU6nQP8MRn6v49p66oDtAAPNRQcmFjz+s
XGMZfFBAiEYEEBECAAYFAjlqA18ACgkQh9ag3dpKERaGCQCguc0ldTZL7+j6Avlp
5VIV1Cn+DC0AoI6PBkWkwmfFeNbWPgRZxOuQ+uZoiEYEEBECAAYFAjnKOwoACgkQ
K7tDpvCerwpRBACdF1rqU4MpphmY3GWtamI9yWKCEs0An2weHB1LSl/xnAeK+Lfs
mOobg2vKiEYEEBECAAYFAjnL/fEACgkQMsNbgEe6k1dzowCfQuX1VDigeNBsCcxK
vdmPU54QyhwAoKqychYr/hLHqQgfVU2sETcOY/YTiEYEEBECAAYFAjnKnW8ACgkQ
NfZhfFE679nDAQCcD20GISMXSvMu1f95S7nZipLmUbEAn3LITRjm7w/b3uqAgmgj
KeAQqH9OiEYEEBECAAYFAjnLMiYACgkQUaz2rXW+gJep8gCgvcTvQjtCjp2vPCQ+
9LvriWkgryYAoLWJ/1lhi6jPLY6Nlm4NVrFG+WzviEYEEBECAAYFAjnM3EcACgkQ
3nqvbpTAnH+xDgCfU3V2BpK9VFMI8d0P/RQ7qDPU5a0AniMxEJFV0F7OySIez+aX
KlFLHYIFiEYEEBECAAYFAjnPDvUACgkQC2MP3CMjttIBqACfc9B562R+9fgL+PV+
VGjASJzP85MAn1rJQVVVQSLrP6SdHHbxtbPr41HGiEYEEBECAAYFAjnPykwACgkQ
E9QuGvaKeLzbXQCgokt9SjQxh7tIOg9oJ+LckPQ6ua0An0cbFCxj+1YPvMXEG2Sb
wMe7XmeuiEYEEBECAAYFAjnKizMACgkQF6ZBbfeUj9otwQCfUxI+VUJNs6D4216e
mqnxhvYn3N4AoJFV214unHmOO+IieX463D7tMG0niQEVAwUQOcqYWBpPhku+30gx
AQEmKQgAmnTtDlJoTHIJVpMR3WXl5aiRmy+FOlUvrXjrtWhYM9YZS91t4QIgnMB2
AptITQYBcQ4FJ7jYRbpk8zig0i0GyYDjD3lmrE2+XgluhxO9qSAGuXsOUQsuq6/f
Q0WqbnBtUQZ/CJW0CydpFfE5x8uA1TC8wrGCfPRcmfVrc8e93UtKSwWWgo4xOkiJ
QXT0s5V/iR09pUduScTpgjLjZonAzR2NKojay2Php27GHBO/HU6Rb2ZGOVZfIsdd
Fj9M9YNwO8L/qjnUNv48igA1yxYxybO/iDaK/6M0LjKWckPOJhUI2bDU12jpe7jA
ui2/FwdRBLCZK9L86AcKigUfSSGXiohGBBARAgAGBQI5zFCsAAoJECDmcbCsS9oo
iBoAmweFLJPySJaIGv2aMspXbPlppl2aAJ9faAb7oaICLW2zdvqraYpRo+09BohG
BBARAgAGBQI50N/bAAoJEG8ji8JP2loMxJMAnRXmIq/pekWpI5w7hJg9NU6yUCrg
AJ0XyfLgd6v6nGyRwQpx6Aza7iuIfIhGBBARAgAGBQI50gqvAAoJEL/hIGVrIUia
opoAnjLR00eLkd2TWTNleRoUY6qQTgRsAKCQoNcdBZYYtsfF+uGIjkNwuDXQhYhG
BBARAgAGBQI5zndTAAoJEOFd2FexXDfRWIIAn2Jx1qya4qH5U6r8drlhAPhXAOh3
AJ9i0WYu9oGWjEAcmN7qVtzqamIKOohGBBARAgAGBQI5yjg1AAoJEPC/nJckksmN
3fcAn07g5lMJoyO8DmpDm8oTuasN5YZCAJ0UnrVLSJw4GM71RFkRKixzIObuj4hG
BBARAgAGBQI51EpUAAoJECnvS20UZCjxm9wAn24zywUnORPNEQlnivNU4un91BQW
AJ4u7ej3KRtOXR6QfKTeN5ZY4Cm4lYhGBBARAgAGBQI51EpaAAoJEH6Lq0fkCp16
ShoAnj9kolr8EMCMutP7vkv8MS/wsiH7AKCzbC4C1+igyQ0Lm3I9FyCl0VVbxYhG
BBARAgAGBQI51EpYAAoJEPz0IFPX+kUSTLcAoIGt9RQkhVgz3lEUA1zn5D9W0cYt
AJ9iyirYXCX63tNY3cqMg6gWQA0+cYhGBBARAgAGBQI54GWRAAoJEJ/Oxj5lCIC0
w4IAnjVo0u/3WFb53v2pVwetMugjH9qeAJ4u1VsvgSUTtkS/8o6+Bx7sDjs5dohG
BBARAgAGBQI5z6dKAAoJEJFazEWo9ML9kc4AniStFstXJoQolnooDIMzDzS+ADr3
AKCkE4tq6WjxfLSV0MHIFLvXg7If2YhGBBARAgAGBQI52lYiAAoJECYzIbZBaZVr
nfEAoPSPjJ2qNNhaTN5bz2omXssehuDrAJ4x3M0HsV3vg3YI6xToTg8bTiuBBohG
BBARAgAGBQI5zvUmAAoJEHMKa4Nqhe7d53MAoLQ4MuRp2VN91lOciN2/oIppP/P4
AKDDSwJvp04Dml0S4+9D/xcBwqKVY4kAlQMFEDnQ+N2248PGUGh5LQEBw1cD/0XW
PC0AvGn5xQpjCUFSYvpx4EuUnnOMukKEYnqzFs2wtKCO8Pbb3IyHJ6VGUftYCemM
L1OL8NQgw6AdiHqWm/lKXhbe1vbO+3+EoHbDyIdne4RFK4mulRBUFx/yovwkg9z5
EWJVsrzS/fUuAg5kX/c+hdRtdDi8QYQjPSIwLWrkiEYEEBECAAYFAjgUDgoACgkQ
YAeQgHPH80+3bgCfWl/hh0/ZW4u4OEW1KtIOiU7OjosAnRIisuZdS0ht51jdjrbI
Uq7lRXDhiEYEEBECAAYFAjrBCNIACgkQt1anjIgqbEvnSACbBze4BqULiimEcIUM
4lkErCnDocwAn18tJqdhoZgyD0B0ouLbfgJCJplKiEYEEBECAAYFAjrB0SMACgkQ
0vCiU5+ISsi/SgCfar7RT9JPw/V1MO0rREx2SfDSIfoAoNcgtmpLWgU3kbf8wb4A
ESQIu30xiQEVAwUQOS2iwwFVuuKglNolAQH1NggAjNw4Cg/0z+6FqCv5b/opI0E3
oc2Z1wh+ovL6jsA9hKiq2MiQ0bdd2GmjgiojVNE5wYYm1DYjAnLVUMgKuMNQDCSn
pFe7jghGHJZgnyT3CG2X0TdiN1FNGt1MQwyetIUH/KSIHWPf70OHQvw9BRvkHZa0
9bk9N+WTrDzyhKuZmbLBN2O+wC19O4s64bk39+SsZZ8iDUuMONCg8HTJ2JF1aRH2
i1wpXoWpQ6UXnVPXIWmA31PdzsJ6j/mDgnlVbH0rL24po9kB3ig2IA16rKrMC8H5
mKnM9lvA2VDBr/0WX7LGlscRKD9NXlNjoL7a+CSO7TxLnAdq3+Yi+sQJPINro4kB
GQQQAQEABgUCOS2T2gAKCRCVYGGm3ZNBOfDAB+MGwzHvzV0zSoFSWevq9l+prNU0
yHKdv39AAONHvo8e/AsNTltPk3LKiXdkKxkGl6e7UkHawJoOgd+8DCmUStVv3Srd
POSovqqce6KC9UfsmbLOf18mx7bP5OYpeTleF1fvBMvFhW9jrmTKFpO22uLScpmo
qXmz0J4/dOnrPmPP71gi4Y04AZE8DYtnARVUScEYiZCiLP00+QocjtkIJRLhNTYM
NW91oAW4KYz5Sz1wxyczyfSq03mLBBan9vr3G9WGzUCWpBDic45dpoX2osgImPjn
bRf/yQJ6+GKRT7UlMRFI5rWbK3JSBXOGvjNZlKQcG5uA5OM8zEpW0xbwiEYEEBEC
AAYFAjr1eYkACgkQ7A6vcTZ3gCW+HQCeM7uVjDTOpJequ0Z3BVeKA9V3OFcAnRZV
ML+f+ZmH5tx+BV1TgSlXOA2TiEYEEBECAAYFAjr1mvgACgkQLBigKrTF83/VqACe
M0Aik+REDgVsgu0cyR+2oXw808EAoJM0ojjxIgtWFWsCJUh/nyHQsleJiEYEEBEC
AAYFAjssp/UACgkQlTDIHyPR99S8oQCfdIzgvLTu4E2h5iZ6eSzt99ASFP4AnieH
MW2mdukyzJuddTiu1II1NksPiQEVAwUQO0HCUNImKUTOasbBAQFLZwgAkgMC/xim
skOjL/CxghgdkSWkDFdpEr3XYhzUdLesWgN4AM28mGZZKA9la7dXXRrKYkxhX8mp
L4C3Q9LnrafP+Zn1c8mTuNIxX86j7iZAIksoZ4D2csN8NSMYT9pKK6jZP1IOckCF
BBI0W/yMGUGulDitWj4TwIArf2xQkV73zMKYJFhW5mSjWDx//F1zrn+x1B0pNoZW
CPQ0gDLdEtnWO2x/aiocqkEorHwNfkWusHvEmx4MkarXPDZuLqumEWOpW6v4xOl4
49Z9au384FST6xf9c6QjXngaSQAc3VcwC6AuTjbmiQ6+H6WGwjss5GzRNRg/LD8L
uqaKb12tkfrZmIhGBBARAgAGBQI7RW00AAoJEOd14yTbQbOHdAsAmwXs1mCo2SJL
911EsKPE7/sgZJw4AJwO96IG44Gh+XlQnsqM0J2GnD8qp4hGBBARAgAGBQI7SxcH
AAoJEA6nVrUUSEP1OCcAn3HchOcEeuCeLzCYi1U7JwjsC9iEAKCoelaC999gohQn
O/x50vgUsskGJ4hGBBARAgAGBQI7Rdj9AAoJECP6tfsIFswbylQAnR3Ea24SlXoM
JbSnEOamFTuesu+CAJ0XOHaDol1jnHssyX917HZ8bZ94NohGBBARAgAGBQI7RfEO
AAoJECeGwkR/ikAX5soAn1tP8xYpXSQTPrTrcwaXK3m7wqLZAJ9G3yh6wapy2NZL
D5ZgeEPwDrGggohGBBARAgAGBQI7ScGaAAoJEFCP02O8k2g5qqQAnjyt7fxDX7sa
l/ppjksajqFlOCmBAKDHqKC5h3R0jNUR95ZhwwVrynKFJYhGBBARAgAGBQI7TBe1
AAoJENcNX1hgPNB4c0wAn0/S027VD6x7S2FBGyiD3GP4FC+iAJwNtcPDbyiugiNn
SDQnSmSxSBbubYhGBBARAgAGBQI7SCdaAAoJENdZXTdLcpYlWi8AnRLlddW/rueL
z6igUbjJq5ATAX1kAJ4l9Ej4Mw3WpASDoEQS8SNMpaj1AYhGBBARAgAGBQI7ShVN
AAoJEJYkg+FWYsc0dG4AnRx0d9Ti17jNFMLeigC/MCr+QSviAJ9kb2IuGhw1bUi1
KINM8q2bQQAaqohGBBARAgAGBQI7UblhAAoJEOQ7FTzLRn4nHrgAn2fkDVwZqjcN
olNGNE5LjdblbNXEAJ9Vy61tZ/s0H/l7mZOigbreJDIhGYhGBBARAgAGBQI7V0Jb
AAoJEHkWLzb39qrZbrEAoKFjjHUPomPUu1gAnuk2qqm1p3CZAKDtB/PvqBb2C0rV
mmfpg1pXj/nU2IhGBBARAgAGBQI7ZzpQAAoJEMALDTYh5T69uBEAnjTka8BHWuhK
MmPW52PQJ7cmJ9tUAJ9zGIqA/3/nk1ZS0pgyLfnKPJvRQYhGBBARAgAGBQI7SZO8
AAoJEHgz7PG1REgVUUkAn35FdEAplXfFwa+ENMPRNagzdA8LAKCFTXbGeSjirdjM
21dFNIToh8S7NYkAlQMFEDwGr3MXPHHnE9mHPQEBv60D/iZt13tGPf3PqtZDQqqB
Ej7TlHtqmRWJ41qETo5ix0CHCw0OsDF1Y1kzjwfax5Fte49YLGVlcfYhldAQ+D3q
ha0MceKQPtVFg0rcBij72QcMznYXSDtEYD7TAlNtcAPCr/VjHQBziBN6dAok2Tt8
sztsdcwJfk+9LANB2vX2qaJNiEYEEBECAAYFAjxw4+EACgkQGM0lpSLzivOYuACe
IyfkTvjVxQnVP21FOVKscS3n/Q0Ani/K4IFki5Uqe9zk5MYN3TI8mj2jiEYEEBEC
AAYFAjwlvGUACgkQLbySPj3b3eohlACfXuiyTRw8ObbNLCLAPQrAJGVjclQAn20M
uHHrNq77H1SgBw/Xn7fadKKwiEYEEBECAAYFAjtSxDgACgkQO/YJxouvzb1SXgCe
IKzHXwuDNHmz56JZApYo2QOFFUoAoLDQT7AFQT/vlXq1GkO+hKtzeuXfiEYEEBEC
AAYFAjwjtU4ACgkQRHJT9Ar9DKjy/QCffSBJW6EJF7eqTae4LxD8zPet6iEAoIWI
REsh6zjEbITlfWWGhWSrs5yYiQCVAwUQO4Hbo1Ks6y7TpCxhAQFTLwP/ZOBttIDu
MJPRxSNnJvNoSlstaYxqH42+33XtwxvUai2LCVIKHC8kgavSqn5psK+j9sVLqibn
PebK2QN8Xwid9ZG6FGF6c46T1STOhrhJyYcj4la7WBg1ggd70Q1gOn9OmzWtmYDu
7VoxTYhwG51IGrasgEOFzJrvb0hV5bzGc6iIRgQQEQIABgUCOomB3AAKCRBiiATb
IPxs9iv7AKCaonJLi5A4q952Lf1IAZSWbvaV6wCgpq1Iw+gUkhgr2UX/7dKrBA/2
hseIRgQQEQIABgUCPAgRzwAKCRBqWILfhEBGApEcAJ9RIFv5APNz7Z0xfXWl/fVH
PnUyrACfamdeFPVrHL101BILgIFOEUNbGXyIRgQQEQIABgUCPA6XmgAKCRCLup94
YAy/5zEQAJ9W0yasRJlv6ClDJffKiJfQMyFQlgCeI1wR3sdVisKpHVpclKui+3cK
SECIRgQQEQIABgUCO5hEjgAKCRCQLb2RjDipCsToAJ0YYpBpdCpAuxlvsOCVqJFD
ha2mjgCeIVf0M4eRHrZSjzUNPegY0c31fOCIRgQQEQIABgUCPAui2wAKCRCqz7OG
IRtu7wv+AJwOBT2jCTvg4DmCK6ia3Ch+4RAwIgCghK9NjNrz+yqCYR0BBtLmrFwU
cHGIRgQQEQIABgUCPAf7VwAKCRDa0rBdXzwxhQUdAKCzI6mRsmewgoxBtCiMO2yw
DI0X/QCgqJLsS94ezwllI7uvWix2qO1qt0CIRgQQEQIABgUCPF2rOgAKCRDu8Ns0
syEmAwy4AJ48w1kK9bn3eclkd3PEJ6DuHJsDTwCeNEq79cwbEEzUGX1mySe4QuPq
qwOIRgQQEQIABgUCPHFBegAKCRA6GqY1kJpUBuDEAJ4wQq/nnv52HnpLeS/Y/g0w
cp6+zQCdH5DVjozROk45axTNDiJrI+sTpZyIRgQQEQIABgUCPHN4gQAKCRCj4LnS
ejT63p/YAKCc9dxuOjoejjPjv4/bJBfE9Bb3AACeLS91AYIJCSvYhT7BI/FsNpim
WEyJARwEEAEBAAYFAjyFr5YACgkQEq14jk8L6rswwAgAmYoP9jbj4yzxZiLRwaT0
v1di1Zz5ip862ETNkr8JQGu0F57+aSlECj3BPnc/A93AnEHvw12Xryb1bAZxgKNS
t5GowTTKCm0zUvwY+6HQ+T7R3VIOGzfkzV867tt7pO2QsS+4yYwvo9gVHczV9PSF
OeCGjme1Q3yoEp1/r6VvH0fi1JgkYoKFLw0UBuu+gv2XdeXY9FWXKHm/u88nsBSc
8PJ+B6I3u0/E7B2Pu29u8apY4VCtY4BUwoALBBjUYLFzEh/xJTi7qPD5NLZQSFog
6Z3aju+0MqYsrBiQpZpSiWBgPqxQwz/DZdUH0Y/wMNU19gsjkpy2+L6uAEQYfSIW
0IhGBBARAgAGBQI8tzrnAAoJEGNFXT5qgEC9YbsAoPZcSYh+baeE+o46yDhhBV5W
4VynAKCiJAby2fHjNyOANqOs+AbJ366jhYhGBBARAgAGBQI8f3SNAAoJEG3yVZ9B
pWcPTCAAoNRGmdH4SpTKSGMu22mHq5O5B4PMAJ9q8l/Td+8yLzQZKJV7DCD2o4+F
rIhGBBARAgAGBQI8lzY1AAoJEINou1lm+8GMz1UAn1e3vrSf7b0HHMO3NgHD4Zfx
2vbiAJ0bg3QKT2sa2j6RDsQ2SOjirPZunYhGBBARAgAGBQI8foHxAAoJEI47c57d
K8ydixoAnjC8sjBGNb/0bckMNegrZUgNFBXXAJsHnBic+JYFJxX5cAM0d3YVEM4Y
LIhGBBARAgAGBQI8lzQ5AAoJEKHoAnDadDOW1DQAn3Pb1VX9+0CLtOOHaAQX3weS
BT2cAJ4+TXEmmOpYYGzgT8pXZsjGyw42fIhGBBARAgAGBQI8gGO+AAoJENeDa2wM
2SDnmrUAn0WufO0MQO/wKk0PMZsgz3gq3GkjAKDGHpOyOl0Sr5L6UwmufJHmsTju
dokAlQMFEDyCLHLlFSglMxzaXQEBOCoD/1duqEnfsCjE+0B2pzKh9h3/IPi4dIaC
qlCTjDZ/tWU4xVGmaMfU1I6TVRDUtPBOt9XW4xdew+ntJNHd8E7g2fVjRSyQYLwZ
EQ/jG2jjowfAEUMJzQSPm2C6E8uIxuvD4gP4N3/mj4l1WHp8aexGhbeSqF9BbHYu
7ri93Tz3TdJ0iEYEExECAAYFAjyvU4gACgkQ6pxm6rn41tlvcACgjPRZmULJnaVf
apXamMzoPhtFAIkAnAuIhaMOKBqsiGzpWxkAkCUh1qJ+iEYEEBECAAYFAjyxOCwA
CgkQJXt5TsZsoD0UnACePAR8wWLkY8ZdEVwJyHOztnk91oMAnA1OZbHhmMwN+bYj
mazn9dYOddvqiEYEEBECAAYFAjyxjiwACgkQocWSfM5dzg6zaACfQky2IN8wQyZA
DGCZ384YlBgRzDEAn1Ivzmi/vBUfmlAUrk91d9q1EgUxiEYEEBECAAYFAjyxgtgA
CgkQeuuK7Uc6ScmBaQCfZ9ogU30ZhDBB0JZzo7dJBqq1pu0An2aNVIoZ9KKjEiLD
+HaKMha1Q8bPiEYEEBECAAYFAjyyhzcACgkQVlEzpFDUq7kRIACg3C8msuOW4fDW
M7McRIFT5AY/084AoKUUviYD6wezVBn4NUIOKMxM6Ay4iEYEEBECAAYFAjyz7a8A
CgkQJltdGckHlEx4bgCgzog5Mv7LJUDZziSGgv+hzyvkCR0Anic4FduBfWg/zuyB
kgOhT8QzyUmCmQILBDxUyXkBEACgg6vxNPigg9FQz14CkPtR/dEq3sCjK1r4+2oy
eoRno+pqZ6Z7ZfphgA/q5woweFAGOg17KD2WXegoQ5pXbFvP+w9j9zm3g59XzTRS
zZgScelTibPnKy6g8r8GDAY6IQraR6pxe4297/NznqvRvKpTt5g1XP5LyjVBsEv9
HAYJE1vyy10qSQRtEz3QunUzfELNC4kiYNMZOnmgaFeW4APIIhWDtrrxqW3Ofjp1
K4DAhqcnayrfvYbOtqh0sxJ246kvVc3Bc9pH6wDw/yub2deuPq6BZBLBJwrtu/20
qD0nsZ9is/5j0aL1MZuVmr7xKYqeehyzJ1WdpJK52qng9natYedS+GefKDIw1Jq7
ppQNWfVduTNITFTF0JswggjQuPqKT8Td5GCywQWN/kGHbp6EdybiUXZ+9fp4eek0
UB5M+srSwbkF4hQ0mBrqlsaoji4CuXjc0c+Zx1D0pGfqqBCmvEV1tLul3U8h0TzR
4opUA8mLKegQp5cjh/dHz7zTPDxVgSr3blJ9FxI1Z69th/+jJj3q6joo3uW/5y8q
QCrzdSCzs+TDEWwucZtJIuIhTct8AMPY/Ayt+Pf9jXfI+xSQgz3r7Eu5o+rEu02/
cthaOc4b3KYDtNkjLKszgiext1BYOq06R+Yyh2qgsg9azzkfudvvpwhCpJ7EOxcd
aP3bxwAGKbQlRGF2aWQgTS4gU2hhdyA8ZHNoYXdAamFiYmVyd29ja3kuY29tPokC
NAQTAQIAHgUCPFTJeQIbAwYLBwoDBAIDFQMCAxYCAQIeAQIXgAAKCRDbaY1xmSQl
YH7aD/wMq9ksbvAf9drjVP2u4rjZhLkHyc1zCp7rMXc5CdNgDNVyhl7+co/qMeQB
wk8SYEVedrZZ5Q7qjygjkKWp3qrLlw5PSydwCHaf5mlVg5E+5gt+RTkOi6FXdE/5
c0IrIB+MNI3jt3IeOqEhITWcnjDk4gIxm4z43tvXvf/fY33ohrQknApN9uYISoEl
zYGgnEZqX6P3p/8FB2+27A3t/Eshr6lLvVNEMgOlBY8te9TFvMJTMeSJXIQVpvbz
/LMF8uEboWVzRC77y7RcD8p+JP9V97qZGsiOYB+2MPGEvAhEPHxQZAbaBF+eBFLz
ev+xmI36fHlFnAFiWikp0tYVLROgBhVGJUOJlDK+olfpxUqF+N8MfjeS01aHLy+Y
6rkzC26AC/9j+Adka9mBXEiiA1vQcBfO4U45QhgDAl00yUW1gV4oNGZ9YqslOhS/
VHB61CjWwjnV3Jwkhscxux3rjj6TAwn5QmoO9kr3CqH1rzQXxTVruCJuwyuI6aNe
ywINoubgDhqhOCPfqyzgdxfp5UAhy54ge9dqjfgHI2Q3WxxhD3mCdYgN89GZNpuH
2lJkJZrRl7BimjqDeTlKYscZ1anrRgRpSoFDdUcMncySzW6cB1WSImj1aNWpq58F
xoJWcTy6lNesINeRjZ/r1eJBeN55P8+7DKGIsGkpftsqgXAqVYhGBBARAgAGBQI8
WhCrAAoJEM3PhoWgyT97OYoAnRFHu9zcFMaNxojhWfZSlc32F8P3AJ4wp9uyTSnJ
pCDW7b4lcyUEX+fMiYkBFQMFEDxaMf7/7ryp5VOhtwEBMsMH/1O0rOOp5nFiivB6
9+IbPSc0lxeLjPfmb/wQArJXWXZsWDbBuby3yL5+wwwMFyLLDGV/kPiC6qPHfC21
oI7sui/TgBe5XblSkx19wAUgyuHrAw/YJTgqhXKmaZFgkcVKhFcc81HU1w7HiGvM
oWA+4VMFHdqKmGsqYkegvfroYWsxbDxbQ1OQ4GHVwJ8pHYVdfWX5xKTRjuKTC1GH
esfA4lorrs/zC/clQuJHMV/TrE9OyvP39vq5zBbG5iOerU/VO4w96yxiHoA2J4YD
SSmEZaCTqjleH1u6Jt/YrL41RaRBayNOoyF/AM6rrmai7agTlutY5kjMjWyZ4YNp
za3E4Q+IRgQQEQIABgUCPF2uXwAKCRC98g3l6mjvU3yBAJ92Uc/XTOt69hteH6JT
CvcFJE3NEACdG1gNdn1xkCU4cIjx4NZJty4vFF+IRgQQEQIABgUCPFyBgwAKCRDq
vxOyCxdw2+H+AJ4/oSxuFQVqj1SS3Z6nufW+4UKpxgCfUFd5h+48RyHC4prnHd2X
wTwDFYaIRgQQEQIABgUCPF7gdAAKCRCc69apC10naM32AKCypWJPQ+Y7y8odeJfa
MsjZgrN+XgCff6aipzB501CUUc/PlaKhL3KanVWIRgQQEQIABgUCPGBsXgAKCRDa
2nnNeIo/TL/wAJ9fXFgw4gF89C0G22XZBFgddadIJACeP8RBT6kShayJrX1TK6SG
o3aw3GaIRgQQEQIABgUCPH0qxgAKCRDWFJDobGH8qhA3AJ9QBuhppkcU1dO+qUDE
FDmeKGlJeQCeNIHejRJbsqRlsJjWKhU0xDW6TKaIRgQQEQIABgUCPJfc9wAKCRAH
lNKuLBMRcSkdAKCKG/h17odvnPFMdJD2/MofAmLt/wCePQBItnFwcWsaoECtHVhA
Xkor806IRgQQEQIABgUCPJ9y1AAKCRCDaLtZZvvBjN43AKCazWmPGOA8Q0oUrjF4
QvOUFM/bDACdHDw6m42VYtjIGqZGudhZiam3PBuIRgQQEQIABgUCPL9PngAKCRBE
slvUW9U99zyHAJ45DoDcb7HPXjgOAv00OHNIvDheMwCgsd3fo9m9BHyyxWz8QrCT
0aLAcv2IRgQQEQIABgUCPF4i7wAKCRAIBXUxEzAHMTr/AJ44sNlp+qn9bVY56sXE
3/iTZ+bTIgCeM16g9RACeNezFD2z+1EzCg852Oq5Ag0EPFTLBBAIAO5SrjR8+omG
/tqQGW8a46eQB1fOqW7VSUAVqRlpBixERm+sNoWEy/GF6+yYLXgZstWv/peWWI52
RUPOtN3mUQtYPv5K67lpn4icRPx7R1XFUg1MVzSYhOuw6UnRj3/InCMd3PdV5Lov
Yn0t1TEo9Xs1i5ufzmBdbrU0OUIsK7807mgrPI1g1M8SO+xXM0GEBC7g5h3r3XuC
nuujHlgiWm7PTkOoutb7qya49VkEPab1zs3G3aEBbQBf7xivNq569KeXA8nrN0uZ
QiguJyIb6JB6LQn+t2FFOmnxvTi6fwEpXKdodtb5rQ6e8UoOg+yL5+XB7R5wbwoR
ur40PSDuYHcAAwUIAJzRe8+VXFdNC22EMTdb1++4isCdWhGVUmDKyZ77YbSTzOWp
QLDkEUXvOaYGbAX3dsYCmw2RbEGj3ovp+fZzD08ZevGLK2DlmgXvSEZxCgWCB0lc
AwBrBHccjioKYTTu3ECnKUVnXqovRUNdXFlS2a0qgoZk/WermBiw2mysAIWJek6x
ENifTszOfOiwEWR2/JtjDnBq5Wvl2WWp54xFX2nouaJ/CLoTi2pcf78e+Atai4vQ
dXyPycgrCZTELo5A66c/NIcCMmr7rSwfU3UGZ/E7jai/5u3KVNWDGzSGv9TsNgoq
O864a/xb01+CoDGhqurpMe6lgw2zBPegReeyDLSJAiIEGAECAAwFAjxUywQFCRLM
AwAACgkQ22mNcZkkJWDxrA/+NILMckL+DPARXz4JzxDmJUhAcKYm6/l0Xau6vfJ9
xfWZV4yR6u+EYV+mqLS9dMKXjG+n3BSoZmjLvDYceD1D/foddSOxMJjHi59qaxv7
Em7IAmOLbBFtPDWw83F3Y+vir3pKROpWJjmuDkUExDg8fNXfUfA8XKlAmB2J/omD
GxA5wWZh4D3OYZBrwTY9hfnRrOJ9Igb8RUgaE0sx2/V5LBt/3KvA3VufTHCcNf50
8jdpCyLxozaknlftj9qHoeTUSQB7PV+VvmWq/rKr5Rw2tXtI6tkqzIVnTg9aoE19
wcxcroVltyCS3XMhRKejbAvy9niXZFsHJU9cYRL5vCxLAdtZ3RNlDaSIzlHHRbxJ
2GvOA4vGaSLxL54BuqvbZuSteA12WEHM7Dfq6zl4E2H8WxLgs6RQoNQ2WkUJlpF3
MsM6OxdmFIMNZxXvU5SKyyYF2XI4PoaN1DZqrla/qjVdSM2ApBOiO9Cf0N37lzn1
XTNldCUE2lnwTlBaMMFTcsyOV0pfE08LJbBjfK6BABgUd9ycIQcuk5XYRK50daby
DlbdJJBl2xKiCGDjb37HXdiyBWVH8noIfKBQiTQ5ijmyp7lcmR+d0N24E59Og+U3
QWgivbrFalHviWdSuFS8vttJEogami5Hpd+Ne6Pm6naS91LvIF8tW7DocqPZu/bo
PKKZAaIEOlToJxEEAMJP+0akG7QQemN3cbXVC2RNZieKFkMF16eNhXYS+i2BFkCP
mHh7CmurW7/OrMYFimJgv/2P7lcMVyhYXbhvOxSYdexsNKK/5cTJA0PUZR3HjBVw
Rjms2OQCtfTpe5nM5u9cVc6+pGPouyR4+3DfEt/m6PyM83Q1/pgqeF8YgdFZAKD/
RQCveEwrrNwD96C9ZEayb10l5wP/XxdZ6TO3kkl4rd95sk7/czB7jc7pU07GYykZ
Y5hOuGK/I5v9kuAt52pf4x5ccZ0augBFn6TFir9r3LmM1yK8P4TI34iI0M8PriuX
TQU1mSzHt2KMPz09shQsMK1SmmzYnSCTmKdH7LOKd/6MPIWeflQQcjas8UtRtdYc
lclynRQEAIGTMN16w+MRVdl1NFMuTSx+JYR1wEz/kak2zAyUrgDsDqKomhI0nik7
lCro9g7AMWoaKvX1YR+hPIdbSTGKmdVu+rira8CFIgo6o0QkbGDgNMQp5x/fEJ0n
SRbx1VKiAcMf9z5Dj5EVCr/fVp6/ccPLbRhrLEAT3gFYiwqSFozKiGEEHxECACEF
AjpU8FsCBwAXDIARP8cyBB0j6epm3bUAnJ28Id903GEACgkQx0Y2ObLXeV5XuACg
odXarRcQ/wYmTKnT9XmWBvAGYEwAn1O1V/DaSGhpncs1Xa0g1KOPQCWntCJQaGls
aXAgUi4gWmltbWVybWFubiA8cHJ6QG1pdC5lZHU+iFUEEBECABUFAjpU6CcFCwkI
BwMCGQEFGwMAAAAACgkQx0Y2ObLXeV5WUQCfWWfTDHzSezrDawgN2Z4Qb7dHKooA
oJyVnm61utdRsdLr2e6QnV5Z0yjjiEYEEBECAAYFAjpU6RIACgkQY8tpHfrr1fwk
9wCeKbj4dzSi15Bms1R64xK6Ks1VSvsAoLVZckjuDAyrQCDPTuFCz7484kEyiEYE
EBECAAYFAjpXKG0ACgkQ14y85WanSzFQbQCg2uVT3G+jVR+rVXhAyVL/rQY6eqAA
ni6DbX27Nq7yZICgx1hCA5iXYMthiD8DBRA6WP4Y8CBzV/QUlSsRAkmdAKC3TfkS
Seh+poPFnMfW+LRuQJm8hgCdGacEslDd1xCQSYyYcSVbJEVFo0qIRgQQEQIABgUC
OlrmsgAKCRBnkE+tCnkWEPSUAKDpWL9v2omScHt8go1AkjlpBG0ZawCdE0H8UBXf
KW4QVCZHAoM8Ms1J4tiIRgQQEQIABgUCOleFogAKCRCsuxZLz3PsTI1gAJ0ZT2DR
scaui0RLxHsTRdhjQED8xgCgpx/V/+LCiztzXI1f0hGVIROAKV+IRgQQEQIABgUC
Oz6yWAAKCRAToEwwnJOdb4xJAJ91WRvsYFJrpNYIIRIUxvzJrTghPgCdHazYP0SQ
h4c5PNtAW1YHA5RkOPqIRgQQEQIABgUCO9lQJgAKCRAn/j6KBbyBDt7xAJ9IFWcl
fzF6xnhv1GpDKMCKeI4CQQCeLd0VBn/44vdt3H/8zzgKy5JlRS6IRgQQEQIABgUC
PFnfQQAKCRAqK7rFw91p1ajHAJ9w3XdBtInEbKaiJhIqe3lW1jNNVwCfevWYQ7j0
B2t2N617SBsbbGkDg2+JARwEEAEBAAYFAjwuoDwACgkQLRPpBcN2PZPEKQf/R58v
HmZBgp7V8mgEKCJfX8TCOqJrNYJ8Xt81IH0bXv1k4gGXVwIaavHLHPcf31Hau2sQ
/hJm9KI71budHSBbWt4tnwNMFapI55xWWKPirM2TKnfoj+4kOOK4WuDjsTsjY0m4
v9RE8XmocZHR53YkSyryPy2b/Ti3nQKsloUpC/kezmU8XBtP3cQfaZEEbnWKHQ+Y
mkc3nrbIraEINULNu5kP2T4scMRPe7D97vQR+6K2Vc5o20n942Pzb8u7BAgN43Bw
GAVS1KcoXT+lZrch5bLgF1u5liSsn6FsHLTpOL3SecqF88tiiM+4V+bklXjZuXbr
DU4Dl6gz/M4jF8TRiohGBBARAgAGBQI8O2hdAAoJEC27dr+t1MkzaFIAnRrW4uU4
nwxzc2VHICu7nanqvIAAAJ9G4MFHT4y6ZR3prjQWjpWeQX3YYohGBBARAgAGBQI7
hGqgAAoJEDDVfYbZ1NUsLgcAn1JmhZaKQYAe7Ah59k6xNPUpZRnvAJ4/uM3HHFiR
VhArbe1vx2BjqadO/ohKBBARAgAKBQI7ty0LAwUIeAAKCRA2ttlJOTQkckVDAJ9s
mqnAjJE/VqWMhmvWVcFKdeG0cACg29PJ3V37M+lx6Z1NWsUBaC5qhZmIRgQQEQIA
BgUCPCu1uQAKCRA/sA/yl51MG59IAJsGzjndfoJFTA2uzbQCMcWeLUFnWQCgtXP+
MIuRVK6bCGdbN1WVg0wlGHSIRgQQEQIABgUCO7+BdwAKCRA/zigQ4zaxBsdMAJ9n
/toag3d/RKUMBrkYM5CahuSHwQCdEDx8+v9R85EdIXWIua+NAIxDJkSIRgQQEQIA
BgUCPCIDJwAKCRBH07jLEUv/CMmjAKDFe/lsmnnnNQzsAg732GEGBOkgxwCfdcvt
9mtxU64JWSdB7GGOGDyMSiyIRgQQEQIABgUCO8Nu2gAKCRBI1eMI/ua3cshMAJ9f
LUz4VSTpfEhJsNulV4FxsCWnkACgtKDn6Br3ncYiMCv0I1wKohwY9ciIRgQQEQIA
BgUCPESMCgAKCRBU3b7cPKNJbJ+fAJ9ith4zBy4mGX8PN2OSBxuHMBBYpwCeJSc1
wP6OgatNXzZfgERyC5tG1JGIRgQQEQIABgUCPJq0qgAKCRBh+N6vwPlo3JqPAKCj
J+WVShKpcHEv42g7TIFRx19DJgCeJaEC5PHJEpAEpJ1R135pcuMUNoSIRgQQEQIA
BgUCO6bRVAAKCRBiGZ/lFRHt+Bj5AKCx28nM8btX06i1M+M0sl7rE1g30ACfbv5n
ZYUnvB/ltVlq4Upd+suWX+uIRgQQEQIABgUCO8vVQgAKCRBj+Xyfj9I1PDMIAJ4j
6Ysm4A7vidqast/lbQ82WEy68gCeN6Edwm8GttOsqHbI98LYMQ9aIAOIRgQQEQIA
BgUCO7EVnwAKCRBn2bOMCRwxhzkeAJ0aRutcMPoywIRtM+cSDgBFtpyP7ACgz/Q7
VDZq9tNtnUVODuzQ9BbNFZGIRgQQEQIABgUCO/Hq/wAKCRBojqAxWqujDBYMAJ9e
4nWFjVYSK3NXt+XYG5ByewNKPACePp/Yd8ui91ViuNSbhHiwCAyYli6IRgQQEQIA
BgUCPB8wXQAKCRBqRzoxcSFero3PAKDzhIRGCfFfnuvcPTJs63q2rTiYmgCfS6Ct
YOMQyaYbjsCA2uNKod1h8wmIRgQQEQIABgUCO/MZBgAKCRB8MVegZEc1dpe6AJ9o
nHdaU9zxdk10LVzDS8iQfJIl3wCgkQ3PHxJACbWq550Nuu6GLcyB6JOIRgQQEQIA
BgUCPHSv2gAKCRCMnNnnGBSTGUrmAJwOG7kZGIUFwcEnd3RtUE6QXy/eUwCgluH6
J77g/pyyki767QxcWkSEXOmIRgQQEQIABgUCOyiObQAKCRCPrQIss6QEWVYBAKDO
++09sRU/5u3rlpMuUo9F4bzKbgCePw6JPtErRjAt8zfk8maUM0inwheIRgQQEQIA
BgUCPC6hGwAKCRCQ3qzudismmon3AJ0RJDe8fCYq0Sv4Q+23UZqFBkSwRgCgx/Mc
nOoHqTP5NdOWpZiekDuO2kKJASAEEAEBAAoFAjqkA6MDBQF4AAoJEJ7v5Ejutjqx
+WYH/RIGqKU1KjIonGFv6l6f+YLuiP83imKXSOHVd5r/Wu1fOhodGOkbIvCPhwgq
+xwnjNsbFNTC8KshWIaTjtz77Sgu4qp0aQzQt5ebmJliB6YN45Tq/7SdZZKP1OTk
GUFcyl2GafjRp71uHvD+eqtXTxTKfee5Dlh6vi+ha6ouBybMdB9B0OYzhU2Xi0Dm
GqtcnDDavGostWCvtzFtKEtg4yzu2tR8nUgV5kMCz3osglgr7d8WQ+aZxgMOblFf
gcCRELeBWh4zjEh9wrH/7KMcr6REiXgp0YTpm18JH+UKbvsL05sJgvnJEoDncP8P
G4IkMR0JN8KRcYhZ8E2SNV6Rn/mISgQQEQIACgUCO8+CVwMFAXgACgkQp22qG2je
6vanXQCg+p5+GfFkymKzjUML9zip1f2dVEUAni4ysdlyH3A3oxKV7RWyXj1PgCGO
iEUEEBECAAYFAjtUcBcACgkQp4aCct/T12ngEACXYfv/a7NuPFA3zpRUc0QpWCv3
LQCfd/aNbpLY3QNAGdWIrLsKTKF9IEmIRQQQEQIABgUCOt/u9QAKCRCsdttzJR81
wWSNAKDFrGzAtuKoODKe6DDKx+sOoBL/MgCYi3X66YcHE5oExf+99xwTmzMsEIhG
BBARAgAGBQI8C8rhAAoJELSC37AZpFlD+bUAoPXlGhIUXF6mARtpxetRaG7fO8Vm
AJ96IIXSJfps2fO3AUS38An/8PdmLIhGBBARAgAGBQI7zcfhAAoJEL01r7GgoJ3c
vXkAoN5CbbjJXjI5byD1iis9G+H0cCMFAJ9Mqk1scRTGFajVipyjoC61eLoEJ4hG
BBARAgAGBQI7FfJNAAoJEMR6qYKMZW0Ott4An1qoDfLV3fUHFeDlpP9OtxYLXV2c
AKCNMkaY04vqNNIvJy0c/nnsrog7GIhGBBARAgAGBQI7ztdAAAoJEMS3xe6ePjec
bb8AnA6N6qCXWvfqxZTWW8i31bnm5gMYAJwLDIRUW00lahMf3L/84nrZmHx5HIhG
BBARAgAGBQI7wo3iAAoJEMZN/hnNBj2mK0MAoONXqgCWmOwY1kuCKmMYcpXHCjgw
AKC0hG5DBo0EcCSQ9xuXN2OySrGyGYhMBBARAgAMBQI7yJIHBQMB4TOAAAoJEMtT
PRy1z8BdctkAoKLJRxjLZ02ddy73NoMS3PwTU8HEAJ9xPD9OTf3NctADtorKsf0y
dCyvcYhGBBARAgAGBQI76umKAAoJENDQZPuFwYBQPikAoMzuIMloKscZ6GTuEx83
WSozA7KIAKCDgWXCiaxSEhsJOvOLdu1C525f6IhGBBARAgAGBQI8BunhAAoJENEG
RJeBUhtCpPEAnRqnpqhWbQUGExxxlJqawSqPqA1cAJ4pRGh/F+3ALSFrH3SYv84u
MmcuHIicBBABAQAGBQI6ektkAAoJENEdYC5Hk8UppFYEAJI0VWk6aMSh4r1vT4sQ
ZZNnszlsPiXq9HFts1o0GK0BBNgN7PRcVxQYXroDajSlUGhr3pBmx8LzIS1VQcIk
GS5aMHed+UifhhdIbWDrPz4driXOQnAcB+isMeRfw1tf+5Quyp1BhrYyzSerwN3D
wZC80Uq066Bhok9bQw/Onwr2iEYEEBECAAYFAjuzGgEACgkQ1LqD795zV/I43ACg
xwwecFuPr1I4wAawRXPTvz+2iLcAnjqju6l6jGS42flmgIQhYR8IbbpOiEYEEBEC
AAYFAjuzZNQACgkQ5hUbwVnPhdbNIwCgiR88Ff9WiqZu03JUD8xg1eABomMAoMrm
WytXRamVMAgfKd/hIFBY76DEiEYEEBECAAYFAjqqoAMACgkQ7tDfcL9n0utnlACe
IB7BHKg9ajYIyf61OCLETHioqAsAmwXzodEuj1Vmkanes5VwctoPzUM7iEYEEBEC
AAYFAjvaGf0ACgkQ+8k1yjhw7+0uAgCaAztlqJo9gtpS9BfZnuQb/bK5IKUAnjLo
TJE+INlQq0PbMPFGvhS1aGn0tCJQaGlsaXAgUi4gWmltbWVybWFubiA8cHJ6QGFj
bS5vcmc+iEYEEBECAAYFAjpU6LcACgkQx0Y2ObLXeV4TyQCg5ii9gHqOjlsHGSsq
kliw+Ha0MX4AoLie5O1xLkK/rS9J3aIp9EUkE5AhiEYEEBECAAYFAjpU6WkACgkQ
Y8tpHfrr1fykfgCeLP0tqVZ8D9lU2EVrKZkdauwst50AoIQsSo6PBhfNwwb5zDLK
O/PGftGhiEYEEBECAAYFAjpXKUkACgkQ14y85WanSzGqnQCePrJJrLngH0MDYrDU
qrK1ju2/BHUAnieEItKJUoN9FXzacVsEFW1D0UwQiD8DBRA6WP4q8CBzV/QUlSsR
Ap0RAJwPSxTAIb6M1TM8LSNgnvYigYZXwwCfZzVNckHKo7WtpZ1lWN+4W80eKJyI
RgQQEQIABgUCOlrmuwAKCRBnkE+tCnkWEOpjAKDeibXDKCIMiNZafH0nzDD/CRU+
pACglr+BhEKX68HeW4QnooPxoFwlviKIRgQQEQIABgUCOleFogAKCRCsuxZLz3Ps
TDo9AJ97srZSNDeiQUHoiGsETRMKG6Uf+ACgwsiJIzN2rVgvAgCfq89g/efv8hTR
zNf/AAANkgEQAAEBAAAAAAAAAAAAAAAA/9j/4AAQSkZJRgABAQAAAQABAAD/2wBD
AAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIfIiEmKzcvJik0KSEiMEEx
NDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7Ozs7Ozs7
Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCACPAHUD
ASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA
AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAk
M2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlq
c3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG
x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEB
AQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx
BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5
OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaX
mJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq
8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiiigAooooAKyNb8S6boUZN1Lulx8sS/
eP8Ah+NZXjbxcdCt/sdjh7+UdcjES+p968fvLyW6leaa4mmlY5kkL4AP1qXLsaQh
fVnc6l8TdSncrYRRW6Zx03t/L+lYsvjjXnA8zUZY8nI2kr/QVzlu0b8+S2R/HvJN
WFgAYuwDFuvJ/lzms2/M2UbdDrLPxlrETK51CRxn7sm1gfzrs9F8b2d8ix3v+jyn
+Ij5T/hXkQj8gZX5hnlCMZq9YShm8vzDt7HuDQm0KUUz3ZHWRQ6MGU9CDkGnV5VZ
6xf6FJ5qTlY8/Mh5Vh9K77QNfi1uEkJskUZI7EeorRSuYyjY16KKKogKKKKACiii
gArO17VU0XR575sFkXCKf4mPQVo1wHxXvfJ0yztw+N8hdh3IHA/nSew4q7PNdT1G
a9vpLi4kaaaRyWY8KDRYWCXkuG5Qc+gzWe8mWAUYz19TW9pbGJAScZ6msJuyO2nG
7NOPTrcxhAMdOmOKp3eg36OWsw0qY4x2rVgkynIyfrite0bKDBrBNo3aOOtvDWr3
dwPPjEKDOS1dJbeFJYY/3UqKxGC5TJ/Wt+Fdx4HNaMUSlM9yK1TbMJ2RwWo+GtXe
MiaZLlByCo2mpvCOpTaDrKpdEmA/KxIwVz612rR4PPWue13T4RcwXBUBWYI5A6Z6
GmpNMmyasejghgCDkHkGlrD8J3ck+lfZ5m3SWreXu/vL/Cfy/lW5XQnc5GrMKKKK
YgooooAK8j+LF4ZNchtmACQQjGDySefy6V6jqeowaVp099cnEcK7j7+grwXxjq1x
r2ovqYRUV8DaCTtA7VMmtjWnBv3jMgjM0wAUnFbcCtHGFHOevtUek2RisUmkwS3O
4HIqeWTaP3e0HPzMemfwrmk7s7oWSuatk7BQG71v28OFUpjHt2rj7XWreH91NLGW
PQ7W/qK6bTdYs5IgFuI8njGajlsPmubtrmMGVuAo5q7GxWMcZBH51nmVDaIqMpEr
DJB7VcWf98Y+wXg9jVowlqTtIpGP6Vj+KNv/AAj1y4xuUAr9cjFajHnHWsvxG6DS
ij8h3H6c0yUW/Aju/n7xg7Rn6gkV2Fc14Lg22MszD53IBPf1rpa6I7HNLcKKKKok
KKKKAOQ+JchHhuOIMR5twufoATXkjOkjqqAHLYAzxXq3xLikl0uzKAkCYg49SvFe
YR2htbqKJyN3JODnNc837zO6l/DSNOLeijyuy7cEZzVG50jUbsmWKTamTny1GRzV
4TAPtUZ+la2nyJbBWmZogScBhgfnWN7G9jmrfR7/AM7ZJdq8GDw8Suf6VRtXubfU
FjMZR8jATjP0r0jfbMM7ULHvgVyl3BFPreICruTglTwvPr60+buKK1NeKe5S3W5l
iaNmHBTgKfU//WpJ/E13bYVJxM+MnEYyK25LKNtPtkPCK4U/TNYF94IinuWfcUVj
uDxnBBpITa7GppvitLnalxZzRseN6pkE/TtUviOVbmC0jhdSGk+b26VlGz1PSpkE
Vz9sthgGN/vr7hq6PT7Qajq9os4ZI0BfYB1AOcH/AD3rSOrsYzVlc6bQrZrXR4Ed
drldzD3P+RWjRRXUcQUUUUAFFFFAGN4r06bU9Blhtl3TIQ6qOrY7D8K8fvraW31J
VmR0ZQPlYYI/Cvea8q+IVi0PiFrgnImjBUY/P+VZTj1OijP7JyP2n/SMnPB9eldX
pV/5kIRsbfQ9K4yTMbhmyMnvUg1FoGYyI4THAXoPT+dYONztckkb2v69ZwSJa29q
gLf6ybYPlHt7+9Q6JdWA1NWgYBMdBXOzTf2id0aFg3anW+l3Fkv2tmcL1A/wo5VY
Sl9x6+ghnswgcEOOcdvemWs7zQHgSMjFGK+oNcZpd/Kl5Ct1JMIVAOA+M/WtGzu1
0nXHWObdbXZ8xCT3PVTSuRyHTymN1QeUSwYcba1dHt1W5Z2xvVOg9z/9YVmC583G
OM9BWtoTectzN/CZNi+4H/661p2uc9S6ia1FFFdBzBRRRQAUUVi6x4v0HQwft2ox
K4/5ZodzfkOn40AbVcX8SrHdo6akg+e2ba2P7p/+v/OsDVvjhYws0elaZLO3Z5m2
g/gM/wA6525+I+t+IQ+n3ywQ290rDy0jwQMZHJOetS9jSKdzm7i+USAlhkZ56Dr1
rd0vy5o9r4cuvzcg54rjLzNvcFMY55xW3od8FKx4GR8zMemazlG6N4zfMap02KC6
bEcTJ6Nx+tbumPYyRrb/AL+Jc/dBEig+wYcU20FtqSguuMcZ7mtCx8PrDMZGkJVG
yB/Kuf1Oly7Ej6XcyebgQ3IZTtdl2OD26cViw2lxeSrayYTyzklTnbg9veun1LUU
021IDb5Dwi+vvXOaVfIJZJN4LF8YHuadmTzHTqZEt/3eTIFwg7lu1dnpdn9g06K3
7gZb6nrXn0mvWujeVqOoI8ltG6/LHyS3b/Gu20TxRo3iCMNp16kj4yYm+Vx/wE10
U1ZHJWd3oa9FFFamAUUUUAeF+KPijqurI0Fq32K3PaJvmP1avPbi5kuZCWJOTyfW
mzOzNinwxBRuPXtSNCe3hSIBiMv/ACp1vcbdThkbp5gz9KYzEL9agcE7vXND1Hex
s6raecSVA3jkZ71nWdy1qWjkG3sQRWlBdi8tQ+cuvyuPcVFMsc3yyrz2P/16yi2t
GdE4p+8jWsfEMNsU3H7vf+92rdt/FyiI4Zcnt6GvPmsyv3HB46k4zUiQTRKF3gAH
Od3ehwi9SVOSVrHT6nrjzSYMgJUjknOKgsZnS4MrMVRerY/zk1mafAly2W3SAclg
NoNWPNaW+kUDbFF8qovQHufr/hVqFkTzXNG+v3v5T5oxGq4WM9AKxlMlheCS1leN
kO5CrYI59a0XOPvAfX1rN1OPPIB5TB+lUSekeF/ipNEqWutKbhBwJ1Hzj6jv/nrX
pWnaxp2rRCSxu4pwRnCtyPqOor5ht5G3Dca2bW+mtXEkEzxsDkMuQaCeVM+kqK8W
sPiPr1rB5bXImx0MqbiPxoouTyM80jh8xyxHyg1KVx1qxEEeNfK5FI6euKZViq5I
FJDGZA+Occ0sik9BVaYMqZUkFecjjFIksQtJZT7+iEjcPSt63W1mUNIRjFc9ZXhu
D5FwQSwwre/oa3raW3+xlGwWPr1FRUj1RtSl0GmW1jdlWCNz2Y/40yCBNQZijq0a
NtKp/X/P51nXk4RJdqYBPJJHJq74a2x6XM4I3NJyM46f5NaQgkyZVG9DRv7hNPsW
8pQP4VA7k/8A66g06Hy7dcnJbkk9yetU9TZpr+KHnKfO2fXoK0LYqYh1x6ZqpPUm
JKy45z+XaqV8AUQ89x06VeccHA6896rXSbrZj3Ug1JRjYKsQfXrVxX+Xg+4qCVQQ
D0NOhJYcdTSEtGWVkIyFU/gtFJGEywbA568c0UFmUomil/dAtk9B3q/nzBjHTqKW
BVjIPU45NMPDn3pkLQY6jBwRxTIoxJIE7HjmpW4/OmQcXC+maBdTG2FHdckFDxWp
p7yyyu+eMcD/AGj3qpdLsvpAMdTWxpkQjsVfpn5j+NVFXZCIL6N5YhG5GeWA6laT
w/c+TJLYy4Al5TI/iHb8v5VYlwblAW6qMZ9c1mztgSleCzAKR26c1T0dwL1sDNPN
Oed7HafYcCr8MnlSAZwrdSfWobSLZCij0xRLlXHHDVBojSLZGSTz29KYFDK6nncM
VHbTCSMqx+739RUJvWz+5A4/jbp+VIZSnGFOAOKbC3zZzjr0pbjvnkk9qihyZAB3
4oFfU0IEO05BH9f0oq1hIkXIySKKBn//2YhGBBARAgAGBQI8ZiQyAAoJEMdGNjmy
13leJSIAoIx0Ql/m4Gf4ZZeFQ1Of+zq6499DAKCHBzmIEtE740kuUl5HGNvCJ4Qb
MIhGBBARAgAGBQI8ZiXuAAoJEGPLaR3669X8OzwAoKHGtOZfI1nc4NEGzRLorYzu
HN2YAKC6koYnTdhlsiEOJxiaUxTGi+Vv4rkDDQQ6VOgnEAwAzB13VyQ4SuLE8OiO
E2eXTpITYfbb6yUOF/32mPfIfHmwch04dfv2wXPEgxEmK0Ngw+Po1gr9oSgmC66p
rrNlD6IAUwGgfNaroxIe+g8qzh90hE/K8xfzpEDp19J3tkItAjbBJstoXp18mAkK
jX4t7eRdefXUkk+bGI78KqdLfDL2Qle3CH8IF3KiutapQvMF6PlTETlPtvFuuUs4
INoBp1ajFOmPQFXz0AfGy0OplK33TGSGSfgMg71l6RfUodNQ+PVZX9x2Uk89PY3b
zpnhV5JZzf24rnRPxfx2vIPFRzBhznzJZv8V+bv9kV7HAarTW56NoKVyOtQa8L9G
AFgr5fSI/VhOSdvNILSd5JEHNmszbDgNRR0PfIizHHxbLY7288kjwEPwpVsYjY67
VYy4XTjTNP18F1dDox0YbN4zISy1Kv884bEpQBgRjXyEpwpy1obEAxnIByl6ypUM
2Zafq9AKUJsCRtMIPWakXUGfnHy9iUsiGSa6q6Jew1XpTDJvAAICDACNUV4K2PS6
h574Z3NaBsIQe5jkVO48MSohjC6s29CjPhlU79cQIYWmBpuNfwroZ6zltyz6Y2Fm
65V0IfvVicR7zvFFCOhahMuk1cr+Qp936OMEq9sLZGxTjClgwrHGS7YpMSZrEC7b
pOmERjo4F/n5YmCHJCH8QzCOc9+80gjVEsHiJVABrC8yykjKL5x1V/PSArE4QtML
bkBPGmQYOw8bx6jCHoO43QjUzbqRfBMHZqWVJyoIIZCp+n13XM4+NO/cDVsZ8bjc
h0LIOyMrT85n24yfXRlP0s7BFjLm59Jjhf4djuJWikJawWETlypAy86OYRRuwCbI
yNauBeTKy+avZvF2oLvpwH4UnudpC06/O0jkj2lQpn9EEUw11RwO6sq9zYTwAUyK
erN00cbCfyiZl01CIo0btcTO6hQK3c67PaloJ9lVH8/mH7LuqkMLDH5ugkpzmed/
8SorfqVkakne6b4mRySFCBXaVZoKmDHzcH2oSSMhM9exyh6dzi1bGu6ITAQYEQIA
DAUCOlToJwUbDAAAAAAKCRDHRjY5std5XuVtAKD4358jdvOoX358HnQnmwUdUczu
FgCfT70B8OXmdyevgPtF4wOVighnBFGZAaIENaIeHhEEAP6XSuDmn2tbgzewq+Z7
LOGzaYPGFEoNNVVSdPCkwhHaQgD2lPjc2j9yg9qMO+FlNoMz+9LPbkhkNlYnuAS7
zpGmgR22v94rwa4NyCxa8Wzn5ikIPBYbZ3Hf0wTsM35JG8QTXFSbgT0bY2d3ZQ20
uCDzbCCL9krgiH0JgPKjRr1rAKCKyfdG9n8xEQmZCrX5KMmAPH5zawQA4SfEZiKy
ogpw5N085NOJ7ujvH6d6ba5pzu45brw37BFbGEY8jGw5254whrtT3haD9h2fh/Za
eAmkG8o1odiZbyPVDnO9ldekhZFdK/JNHrjUFx4Yc11iJH8+IMEmwZDdpzufunCF
Xip7HchWJEMlbPkPOvzzH46O7rcq3Fi6tQgEAKLt3WtSUeviiTuIFGVYdhdTaGlQ
hDwL5Q4TVddP4cHuZktJE41CdYzJeepsABb4RRRfbGlvngJ68CDh46KW3R6zwZky
ZTpzTB1SycxZao4ocEUWUMi/Ijbtpn2q5/TK9vLreQUJqdApzRCeoZdArO5dsWoF
hbZRCtiCNeOLyt3xtCdXZXJuZXIgS29jaCAoZ251cGcgc2lnKSA8ZGQ5am5AZ251
Lm9yZz6IXQQTEQIAHQUCNlWgpgUJCG0MiAMLBAMFFQMCBgEDFgIBAheAAAoJEGi3
q4lXVI3NLj4AoId15gcyYpBX2YLtEQTlXPp3mtEGAJ9UxzJE/t3EHCHK2bAIOkBw
IW8ItIkBXwMFEDWiHkMDbxG4/z6qCxADYzIFHR6I9Si9gzPQNRcFs2znrTp5pV5M
k6f1aqRgZxL3E4qUZ3xePQhwAo3fSy3kCwLmFGqvzautSMHn8K5V1u+T5CSHqLFY
Kqj5FGtuB/xwoKDXH6UOP0+l5IP8H1RTjme3Fhqahec+zPG3NT57vc2Ru2t6PmuA
wry2BMuSFMBs7wzXkyC3DbI54MV+IKPjHMORivK8uI8jmna9hdNVyBifCk1GcxkH
BSCFvU8xJePsA/Q//zCelvrnrIiMfY4CQTmKzke9MSzbAZQIRddgrGAsiX1tE8Z3
YMd8lDpuujHLVEdWZo6s54OJuynHrtFFObdapu0uIrT+dEXSASMUbEuNCLL3aCnr
EtGJCwxB2TPQvCCvR2BKzol6MGWxA+nmddeQib2r+GXoKXLdnHcpsAjA7lkXk3IF
yJ7MLFK6uDrjGbGJs2FKSduUjS/Ib4hGBBARAgAGBQI1oic8AAoJEGx+4bhiHMAT
ftYAn1fOaKDUOt+dS38rB+CJ2Q+iElWJAKDRPpp8q5GylbM8DPlMpClWN3TYqYhG
BBARAgAGBQI27U5sAAoJEF3iSZZbA1iiarYAn35qU3ZOlVECELE/3V6q98Q30eAa
AKCtO+lacH0Qq1E6v4BP/9y6MoLIhohGBBARAgAGBQI5TM2WAAoJEAJx6COq/B+4
jTYAnjOMlKc5tuqspHgAUgAVmBda5XNGAKCIqZ3Fu33suLyRABGZ+tN3tJ1QZ4hG
BBARAgAGBQI1pysWAAoJEAQ1xdJF3KZpeMoAmwZEvOS95jEKj/HnbFBDDp5C4dw0
AJ4nsZgDnGDAG7FCEJI6+LoIIUit44hGBBARAgAGBQI26PrdAAoJEAcDKpaJBMji
EpgAoM3IisrN7XXdhnP9lmx0UJKE7SsFAJwMWIBnGK93ojuWXh9YgDRySZKZqIhG
BBARAgAGBQI7JUB0AAoJEB3TgN9DaBQASVsAn28snlWv8ljqxPsS2e7xqJxzND3G
AKCsObLMGdGyED2YKlu0sSa4E7cE+4hGBBARAgAGBQI6xKZNAAoJECAsPjFYbhLl
DsgAn0tfgJSaxWUd5s0ZGmKob7b84onEAKC15V+DRTrE1tArKxy/itSNiMtQG4hG
BDARAgAGBQI4no7wAAoJECShvswraT6/w8oAn0XLPn0F4s9wQ4pGXNPCm7MJ6E5z
AJ9CbanRlaKAXoD1LP5bmADGkRBqfYhGBBARAgAGBQI4vt9pAAoJEC5ArMtkcKsm
HDkAoL3TIizomIuEKO6vwHMFcFndsaAaAKCJAkq+I2mjYimFE7ajlaL0jyecGohM
BBARAgAMBQI6IYGCBQMD7eiAAAoJEDJKcxqmfO/9aXgAoOumahVFuBTuZsv5ma2x
G3dVPZczAKC1viEIhAakthEb+Pi0SRyeK7cqqYhGBBARAgAGBQI5zA88AAoJEDLD
W4BHupNX9vwAn1ZRUYyIWV5XoRUIq7Epz1id+hDVAKDMZSo15h9vfGAjrytpxOs5
clW+G4hGBBARAgAGBQI5bedgAAoJEDLGkzuo7SAfxjMAn2I7CSRyEz8mkaD3emaM
1WYxvbb5AKCFOlNjoxNmu3SSWfgrW1EESYPQY4hGBBARAgAGBQI4q/0WAAoJEDW6
YX9GCEVakzQAmgNaF00/D/eOgHmtLEjE0IH1H2yUAJ9EKs47I9s8U7IYJOGoQRy7
LD1JRYhGBBARAgAGBQI7ScU3AAoJEDeckqFodBLoiG0AoItVFw4742i3VVL75rHp
S/iRTyXXAJ46OJxgMvJ9knQ0l4so5JiBotS/8IkAdQMFMDifLTk7IqtjPG8o8QEB
gOEDAJEaFnJ11GJlMpSIkxT4kU1DpXJGc+w5vhX8xjqjTlkbCS1AeryM2FGz/wPK
DjHtG97Ybptmeigrx5ZZ9O/wp96sTYpKiKk93YRyzPOtJ4GhahMR48LBu6YnHppJ
nxCyg4hGBBARAgAGBQI4XUq+AAoJEEPM0G/dqdt2qekAoN1HvYZQ6AxvNVLx3M06
s/ytk21NAKDNn0RgGyCBiyQeLuV3Gkuqxke7kIhGBBARAgAGBQI5Zs0MAAoJEEcW
KRmClXtmuPEAoJe7siEXNYVflP+Glf71M2xvkSa3AKCerd0dwvhmi4Ao4ujBnuZI
4YUIhIkBFQMFEDfZA2RNwxExOP7mwwEByhEH/2zbTPiXuaff02Xj7QqSIwjo0O47
sgxNHbuUMJB7pvD0q8g/T+jX0ux6Ci16m42aOUjp254G33RN679BdjiHG47DOric
TvdLq9uWtqg+irQosJen+e0pIsFTfmj1zA1G8rrbADqVCEz4SpibDLB5wXDhVdqa
R3sAteIAZti1xoTiFc12KrarkLn+BaWUtvBbi93bsD+ySTE/kIeeCGLW9IEHok8d
id1QMWXNM2VuzSdKSoxaiuJOkuZ2Aui0HAdEycY5fhOqIo4B/rtxGpdBXBBCxNi+
VRaq0CWn13BiII2BvNOmCn879R89qMxuj10X3RnRQIHgj4mg/X7zni684FOIRgQQ
EQIABgUCOQ0ojwAKCRBS/u9nIH5xmceVAJ9VIlMfbC6Gni3jLXZs7VEX5NWQCQCg
id47hulygTIy5ePkpgjOO1ZDP/aIRgQQEQIABgUCO1X9UgAKCRBW05T8JNULxIz6
AJ9tUSb17Etq+1C6V7YiiHCt//vY2ACgt6hl1q6z2ZhSgJLBV6N6wss0GWGIRgQQ
EQIABgUCOJj9UAAKCRBl3EK31OWAJovMAJ4oWYv+ThvQp8zMdVCnbQQL77eLdgCf
ZV/ownqDt0xfEMpHTF0hSHQxy96IRgQQEQIABgUCOpP0TgAKCRBpwYMr+Tra7NWk
AKDQEafW/9gKnUNFINJqEkYUXsYlLgCZAcGWOePrrM7PEOz/h03kqllYt86IRgQQ
EQIABgUCOFjPGgAKCRBxLQsX0D2KT22cAJ0a+519NvXqtRND7/RcEK4LN2bvpwCe
LNuUSotPPf2r7FVap5vO3oAMwdmIRgQQEQIABgUCOGDD6AAKCRBxRvDjMHApSKW9
AJ9R/bMcCRef9myi9B2bC1zuN2qtbACfc+1NHDhmDSK0TaR5Seu2TyV9LceIRgQQ
EQIABgUCOUbNKQAKCRB/4u1e9RQ7Ki5KAJ4r4dNSN7kLq1nOW52+309RiDpn8gCc
DhPygqyVfPUZKOtVwvttHZcysxqIRgQQEQIABgUCOPN6JwAKCRCEP1fXrLWNT4SW
AJ9IRICEmPNdhoYWUc7hP7HOUVhHfgCfUsR4bR9KCTaynBmKvAKA/ciTBh6IRgQQ
EQIABgUCNacrcQAKCRCE5PiUAeWZaBjoAJ41XKqKVxMjGBGXxffEkyprrSj4igCf
cR5sWVtyrVUk0X/yE0jUrP9IApSIRgQQEQIABgUCOnNH4AAKCRCI98SPIjWV9R3S
AJwLoPyJ8dzW1f2ubzYBEkkHN41p9QCeKbvAZQNRcsMKTJCAuhlwFnh7KGqJARUD
BRA21moYjl8DByup3WkBAZ0tB/9v5kOKdh7rwDaPHFLxvG7flsD8XOvMM/LH0uAx
smUebXYwIRWDziZqDmFHpnzTt5LM7nyaPJjggfSCmlLKtx5ZgIgXM9D7WrwPRgcX
g3SHbuKbXTeiSQRP8goMeADlQFd+sX8l40mwKF9klQXR7/02CT+LM5A/KnXM4mqQ
1cjFLiCwhx2G+Rsx4PEDTDoBL3W6ME/pxIzn0NJuhp9oDVvKuWmKtwKPWSHRj8CR
56OBxeZG+sPK3UySM/ZEdEL0iEZvgYRwpf/t8vnS8/Li/M6pem6FnwLalQwv/vMF
FQvBiHJqRJ1VxsdHVDMbap1LO7A2QGghPkeDnAN4jyCsqXVtiEYEEBECAAYFAjt4
2yAACgkQj8C3jQmzMQbrmgCfeBACKTFlOsTcbhhlvIjZJ9ZUT10An0NHUHnoktA4
GMdxW5vR+t1uhGcWiEYEEBECAAYFAjbWagEACgkQkrJ6leQEE6q4FwCg2WMRtIdc
wsfnj8ngeK0CyIjXxqYAoOsMufELOYL7yb85M27iZlqZ48/eiEYEEBECAAYFAjnK
lgsACgkQnznd8F4pxsIVuACfc+MHLblJgJcI5Z42D4d5ufs+LsYAoMq1/GdeKCtx
028BGZm1Yc0zO8cwiEYEEBECAAYFAjnPNIIACgkQpll1bT9NtmnSywCfWpns8kIg
d/oStQbXXVzltaMJtbcAoL/cJ/9k1kraYpk6Z8IJGf2wEGVFiEYEEBECAAYFAjqW
fQEACgkQq79czSEmG4giGACg/qNL4huhd12Jyya3qTJeFYFgMm0AoOWNXs1CepYM
GZ1HNhbcJiH+G8/IiEYEEBECAAYFAjoZ9rYACgkQvhpT6zI73uZHuQCeNJfhA/uB
HrHUFhMILz27aBJcBC0An2dF4AKA1T8P5MuqKaUxL1OqdPJkiEYEEBECAAYFAjmS
plwACgkQx+D2lKJNi05V5QCgxOAE1SMP4BhATMhTXNiSJbU2BmEAoNbcbOwM+rOz
ecX6aQyeCBg8WcSeiEYEEBECAAYFAjfZA0MACgkQzTbgIX48jquOOQCgqjyYGNri
U4Zb6aKW4GHcuJNoM0kAoNCupziSR9pBxWVeMNVhVp6XvigmiEYEEBECAAYFAjm0
32EACgkQ0Y4PDnuqkPpwSQCgubij+epzZINnZ4qvmFgNNR9YGUIAn2Dwom8wzr7/
W0Q9qiUz+FVYoHHqiEYEEBECAAYFAjgmg+4ACgkQ1eiHQ5R2ErMIAwCdF+TWZ/T7
KJR0y5IQ2EoxfLKxnawAoK8xJ0QSYaiZYKCxB8tYzMItHv7liEYEEBECAAYFAjfX
jLIACgkQ1rb6S4yOnyPYrACgr35M5uneN/5PCc9Uh9caSYdJtwwAoOjzOz6KwrKd
c4wXaDnRJNnBpZMdiEYEEBECAAYFAjpCNWEACgkQ30kDp8mywsCuGACgw405ZqhW
MrgNewU0gPllz+S9V68AoLer9gdEcr3aHhxZxmZpjsRy4w/tiEYEEBECAAYFAjrO
IywACgkQ4HkONspwutzZoQCdHVZOvgnh2kW4229FOwRdtVybZGUAoOhlsIEL0j5W
4YJCGQrhd7vxuo0viEYEEBECAAYFAjnzJCIACgkQ5jU8OLhSiwGGrwCg304/n0hg
n41Bgmal2jI8WAmK098Ani2W7uoOHSWlBQEkoisKMbSh3jIhiEYEEBECAAYFAjqQ
EYkACgkQ86QzvnxWxe/4rwCfSXD8N6MhMzfKqZ6b6X/kag/dS/QAn2QM9U4dCrUl
8kOTdZbP+NC+Hcx0iEYEEBECAAYFAjnND5cACgkQ93111w6M5IHPxgCfZrmMKTTn
ZT5+uv6wVFDUyoqavEoAn0nvU51E1kt5+QPuKEnZiZyjwayniEYEEBECAAYFAjqe
VPUACgkQ+qVJWkKzL8lzvACfXa4hgEv1Z+GZLZKHQ76Yg7aPnzQAn2cm8G7PirTu
WSANQVUlCWu4PUh8
=9VIS
-----END PGP PUBLIC KEY BLOCK-----