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

Update head to match stable 1.0

Browse source
This commit is contained in:
David Shaw 2002-06-29 13:31:13 +00:00
parent 98a05e4239
commit 151ee2f47b
154 changed files with 29296 additions and 1324 deletions
Download patch file Download diff file Expand all files Collapse all files

355
doc/ChangeLog
View file

@ -1,27 +1,365 @@
Tue Oct 26 14:10:21 CEST 1999 Werner Koch <wk@gnupg.de>
2002-06-21 David Shaw <dshaw@jabberwocky.com>
* Makefile.am (SUBDIRS): Removed gph from this development series
* 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>
@ -30,7 +368,20 @@ Mon May 31 19:41:10 CEST 1999 Werner Koch <wk@isil.d.shuttle.de>
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.

418
doc/DETAILS
View file

@ -1,23 +1,47 @@
Format of "---with-colons" listings
===================================
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.
sec::1024:17:6C7EE1B8621CC013:1998-07-07:0:::Werner Koch <werner.koch@guug.de>:
ssb::1536:20:5CE086B5B5A18FF4:1998-07-07:0:::
1. Field: Type of record
pub = public key
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
@ -33,21 +57,51 @@ ssb::1536:20:5CE086B5B5A18FF4:1998-07-07:0:::
17 = DSA (sometimes called DH, sign only)
20 = ElGamal (sign and encrypt)
(for other id's see include/cipher.h)
5. Field: KeyID
5. Field: KeyID either of
6. Field: Creation Date (in UTC)
7. Field: Key expiration date or empty if none.
8. Field: Local ID: record number of the dir record in the trustdb.
This value is only valid as long as the trustdb is not
deleted. You can use "#<local-id> as the user id when
specifying a key. This is needed because keyids may not be
unique - a program may use this number to access keys later.
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:
More fields may be added later.
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:
@ -55,7 +109,7 @@ pkd:0:1024:B665B1435F4C2 .... FF26ABB:
! !------ 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
==================================
@ -66,10 +120,26 @@ more arguments in future versions.
GOODSIG <long keyid> <username>
The signature with the keyid is good.
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>
@ -80,11 +150,14 @@ more arguments in future versions.
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 ere emitted for a good signature.
status lines are emitted for a good signature.
sig-timestamp is the signature creation time in seconds after
the epoch.
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
@ -107,34 +180,51 @@ more arguments in future versions.
3 - Invalid packet found, this may indicate a non OpenPGP message.
You may see more than one of these status lines.
TRUST_UNDEFINED
TRUST_NEVER
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. No arguments yet.
to indicate how trustworthy the signature is. The error token
values are currently only emiited by gpgsm.
SIGEXPIRED
The signature key has expired. No arguments yet.
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 his owner. No arguments yet.
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 RSA or IDEA algorithms has been used in the data. A
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.
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
NEED_PASSPHRASE <long keyid> <keytype> <keylength>
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
@ -149,7 +239,7 @@ more arguments in future versions.
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
PAD_PASSPHRASE.
BAD_PASSPHRASE.
BAD_PASSPHRASE <long keyid>
The supplied passphrase was wrong or not given. In the latter case
@ -177,7 +267,7 @@ more arguments in future versions.
IMPORTED <long keyid> <username>
The keyid and name of the signature just imported
IMPORTED_RES <count> <no_user_id> <imported> <imported_rsa> <unchanged>
IMPORT_RES <count> <no_user_id> <imported> <imported_rsa> <unchanged>
<n_uids> <n_subk> <n_sigs> <n_revoc> <sec_read> <sec_imported> <sec_dups>
Final statistics on import process (this is one long line)
@ -185,11 +275,108 @@ more arguments in future versions.
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
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>
A key has been created
type: 'B' = primary and subkey
'P' = primary
'S' = subkey
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"
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
==============
@ -222,6 +409,121 @@ Key generation
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 -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 Tester (with stupid passphrase) <joe@foo.bar>
ssb 1024g/8F70E2C0 2000-03-09
Layout of the TrustDB
=====================
@ -230,6 +532,8 @@ 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.
@ -259,7 +563,7 @@ the DB is always of type 1 and this is the only record of this type.
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.
4 bytes reserved for version extension record
1 u32 record number of the trusthashtbale
Record type 2: (directory record)
@ -316,7 +620,7 @@ the DB is always of type 1 and this is the only record of this type.
Record type 5: (pref record)
--------------
Informations about preferences
This record type is not anymore used.
1 byte value 5
1 byte reserved
@ -339,16 +643,16 @@ the DB is always of type 1 and this is the only record of this type.
1 u32 next next sigrec of this uid or 0 to indicate the
last sigrec.
6 times
1 u32 Local_id of signators dir or shadow dir record
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 my be revoked)
1 = valid is set (but may be revoked)
Record type 8: (shadow directory record)
--------------
This record is used to reserved a LID for a public key. We
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
@ -477,7 +781,7 @@ There is one enhancement used with the old style packet headers:
+ future extensions. These length markers must be inserted into the data
+ stream just before writing the data out.
+
+ This 2 byte filed is large enough, because the application must buffer
+ 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
@ -485,10 +789,19 @@ There is one enhancement used with the old style packet headers:
+ 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 it's fingerprint, other records
are used for secondary keys. fingerprints are always 20 bytes
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.
@ -508,6 +821,41 @@ Usage of gdbm files for keyrings
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
===========
@ -596,11 +944,11 @@ The keyserver also recognizes http-POSTs to /pks/add. Use this to upload
keys.
A better way to to this would be a request like:
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.
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.

352
doc/FAQ
View file

@ -1,352 +0,0 @@
GNU Privacy Guard -- Frequently Asked Questions
=================================================
This FAQ is partly compiled from messages of the developers mailing list.
Many thanks to Kirk Fort, Brian Warner, ...
Q: How does this whole thing work?
A: To generate a secret/public keypair, run
gpg --gen-key
and choose the default values.
Data that is encrypted with a public key can only be decrypted by the
matching secret key. The secret key is protected by a password, the
public key is not.
So to send your friend a message, you would encrypt your message with his
public key, and he would only be able to decrypt it by having the secret
key and putting in the password to use his secret key.
GnuPG is also useful for signing things. Things that are encrypted with
the secret key can be decrypted with the public key. To sign something, a
hash is taken of the data, and then the hash is in some form encoded with
the secret key. If someone has your public key, they can verify that it
is from you and that it hasn't changed by checking the encoded form of
the hash with the public key.
A keyring is just a large file that stores keys. You have a public keyring
where you store yours and your friend's public keys. You have a secret
keyring that you keep your secret key on, and be very careful with this
secret keyring: Never ever give anyone else access to it and use a *good*
passphrase to protect the data in it.
You can 'conventionally' encrypt something by using the option 'gpg -c'.
It is encrypted using a passphrase, and does not use public and secret
keys. If the person you send the data to knows that passphrase, they can
decrypt it. This is usually most useful for encrypting things to
yourself, although you can encrypt things to your own public key in the
same way. It should be used for communication with partners you know and
where it is easy to exchange the passphrases (e.g. with your boy friend or
your wife). The advantage is that you can change the passphrase from time
to time and decrease the risk, that many old messages may be decrypted by
people who accidently got your passphrase.
You can add and copy keys to and from your keyring with the 'gpg --import'
and 'gpg --export' option. 'gpg --export-secret-keys' will export secret
keys. This is normally not useful, but you can generate the key on one
machine then move it to another machine.
Keys can be signed under the 'gpg --edit-key' option. When you sign a
key, you are saying that you are certain that the key belongs to the
person it says it comes from. You should be very sure that is really
that person: You should verify the key fingerprint
gpg --fingerprint user-id
over phone (if you really know the voice of the other person) or at
a key signing party (which are often held at computer conferences)
or at a meeting of your local GNU/Linux User Group.
Hmm, what else. You may use the option "-o filename" to force output
to this filename (use "-" to force output to stdout). "-r" just lets you
specify the recipient (which public key you encrypt with) on the command
line instead of typing it interactively.
Oh yeah, this is important. By default all data is encrypted in some weird
binary format. If you want to have things appear in ASCII text that is
readable, just add the '-a' option. But the preferred method is to use
a MIME aware mail reader (Mutt, Pine and many more).
There is a small security glitch in the OpenPGP (and therefore GnuPG) system;
to avoid this you should always sign and encrypt a message instead of only
encrypting it.
Q: What is the recommended key size?
A: 1024 bit for DSA signatures; even for plain ElGamal
signatures this is sufficient as the size of the hash
is probably the weakest link if the keysize is larger
than 1024 bits. Encryption keys may have greater sizes,
but you should than check the fingerprint of this key:
"gpg --fingerprint --fingerprint <user ID>".
Q: Why are some signatures with an ELG-E key valid?
A: These are ElGamal Key generated by GnuPG in v3 (rfc1991)
packets. The OpenPGP draft later changed the algorithm
identifier for ElGamal keys which are usable for signatures
and encryption from 16 to 20. GnuPG now uses 20 when it
generates new ElGamal keys but still accept 16 (which is
according to OpenPGP "encryption only") if this key is in
a v3 packet. GnuPG is the only program which had used
these v3 ElGamal keys - so this assumption is quite safe.
Q: Why is PGP 5.x not able to encrypt messages with some keys?
A: PGP Inc refuses to accept ElGamal keys of type 20 even for
encryption. They only support type 16 (which is identical
at least for decryption). To be more inter-operable, GnuPG
(starting with version 0.3.3) now also uses type 16 for the
ElGamal subkey which is created if the default key algorithm
is chosen. You may add an type 16 ElGamal key to your public
key which is easy as your key signatures are still valid.
Q: Why is PGP 5.x not able to verify my messages?
A: PGP 5.x does not accept V4 signatures for data material but
OpenPGP requires generation of V4 signatures for all kind of
data. Use the option "--force-v3-sigs" to generate V3 signatures
for data.
Q: I can't delete an user id because it is already deleted on my
public keyring?
A: Because you can only select from the public key ring, there is
no direct way to do this. However it is not very complicated
to do it anyway. Create a new user id with exactly the same name
and you will see that there are now two identical user ids on the
secret ring. Now select this user id and delete it. Both user
ids will be removed from the secret ring.
Q: How can I encrypt a message so that pgp 2.x is able to decrypt it?
A: You can't do that because pgp 2.x normally uses IDEA which is not
supported by GnuPG because it is patented, but if you have a modified
version of PGP you can try this:
gpg --rfc1991 --cipher-algo 3des ...
Please don't pipe the data to encrypt to gpg but give it as a filename;
other wise, pgp 2 will not be able to handle it.
Q: How can I conventional encrypt a message, so that PGP can decrypt it?
A: You can't do this for PGP 2. For PGP 5 you should use this:
gpg -c --cipher-algo 3des --compress-algo 1 myfile
You may replace "3des" by "cast5". "blowfish" does not work with
all versions of pgp5. You may also want to put
compress-algo 1
into your ~/.gnupg/options file - this does not affect normal
gnupg operation.
Q: Why does it sometimes take so long to create keys?
A: The problem here is that we need a lot of random bytes and for that
we (on Linux the /dev/random device) must collect some random data.
It is really not easy to fill the Linux internal entropy buffer; I
talked to Ted Ts'o and he commented that the best way to fill the buffer
is to play with your keyboard. Good security has it's price. What I do
is to hit several times on the shift, control, alternate, and capslock
keys, because these keys do not produce output to the screen. This way
you get your keys really fast (it's the same thing pgp2 does).
Another problem might be another program which eats up your random bytes
(a program (look at your daemons) that reads from /dev/[u]random).
Q: And it really takes long when I work on a remote system. Why?
A: Don't do this at all! You should never create keys or even use GnuPG
on a remote system because you normally have no physical control over
your secret keyring (which is in most cases vulnerable to advanced
dictionary attacks) - I strongly encourage everyone to only create keys
on a local computer (a disconnected laptop is probably the best choice)
and if you need it on your connected box (I know: We all do this) be
sure to have a strong password for your account and for your secret key
and that you can trust your system administrator.
When I check GnuPG on a remote system via ssh (I have no Alpha here ;-)
I have the same problem. It takes a *very* long time to create the
keys, so I use a special option, --quick-random, to generate insecure
keys which are only good for some tests.
Q: How does the whole trust thing work?
A: It works more or less like PGP. The difference is that the trust is
computed at the time it is needed. This is one of the reasons for the
trustdb which holds a list of valid key signatures. If you are not
running in batch mode you will be asked to assign a trust parameter
(ownertrust) to a key.
You can see the validity (calculated trust value) using this command.
gpg --list-keys --with-colons
If the first field is "pub" or "uid", the second field shows you the trust:
o = Unknown (this key is new to the system)
e = The key has expired
q = Undefined (no value assigned)
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.
r = The key has been revoked
d = The key has been disabled
The value in the "pub" record is the best one of all "uid" records.
You can get a list of the assigned trust values (how much you trust
the owner to correctly sign another person's key)
gpg --list-ownertrust
The first field is the fingerprint of the primary key, the second field
is the assigned value:
- = No Ownertrust value yet assigned.
n = Never trust this keyholder to correctly verify others signatures.
m = Have marginal trust in the keyholders capability to sign other keys.
f = Assume that the key holder really knows how to sign keys.
u = No need to trust ourself because we have the secret key.
Keep these values confidential because they express your opinions
about others. PGP stores this information with the keyring thus
it is not a good idea to publish a PGP keyring instead of exporting the
keyring. gnupg stores the trust in the trust-DB so it is okay
to give a gpg keyring away (but we have a --export command too).
Q: What is the difference between options and commands?
A: If you do a "gpg --help", you will get two separate lists. The first is
a list of commands. The second is a list of options. Whenever you run GPG,
you *must* pick exactly one command (**with one exception, see below). You
*may* pick one or more options. The command should, just by convention,
come at the end of the argument list, after all the options. If the
command takes a file (all the basic ones do), the filename comes at the
very end. So the basic way to run gpg is:
gpg [--option something] [--option2] [--option3 something] --command file
Some options take arguments, for example the --output option (which can be
abbreviated -o) is an option that takes a filename. The option's argument
must follow immediately after the option itself, otherwise gpg doesn't know
which option the argument is supposed to go with. As an option, --output and
its filename must come before the command. The --recipient (-r) option takes
a name or keyid to encrypt the message to, which must come right after the -r
argument. The --encrypt (or -e) command comes after all the options followed
by the file you wish to encrypt. So use
gpg -r alice -o secret.txt -e test.txt
If you write the options out in full, it is easier to read
gpg --recipient alice --output secret.txt --encrypt test.txt
If you're saving it in a file called ".txt" then you'd probably expect to see
ASCII-armored text in there, so you need to add the --armor (-a) option,
which doesn't take any arguments.
gpg --armor --recipient alice --output secret.txt --encrypt test.txt
If you imagine square brackets around the optional parts, it becomes a bit
clearer:
gpg [--armor] [--recipient alice] [--output secret.txt] --encrypt test.txt
The optional parts can be rearranged any way you want.
gpg --output secret.txt --recipient alice --armor --encrypt test.txt
If your filename begins with a hyphen (e.g. "-a.txt"), gnupg assumes this is
an option and may complain. To avoid this you have either to use
"./-a.txt" or stop the option and command processing with two hyphens:
"-- -a.txt".
** the exception: signing and encrypting at the same time. Use
gpg [--options] --sign --encrypt foo.txt
Q: What kind of output is this: "key C26EE891.298, uid 09FB: ...."?
A: This is the internal representation of an user id in the trustdb.
"C26EE891" is the keyid, "298" is the local id (a record number
in the trustdb) and "09FB" is the last two bytes of a ripe-md-160
hash of the user id for this key.
Q: What is trust, validity and ownertrust?
A: "ownertrust" is used instead of "trust" to make clear that
this is the value you have assigned to a key to express how much you
trust the owner of this key to correctly sign (and so introduce)
other keys. "validity", or calculated trust, is a value which
says how much GnuPG thinks a key is valid (that it really belongs
to the one who claims to be the owner of the key).
For more see the chapter "The Web of Trust" in the Manual
Q: How do I interpret some of the informational outputs?
A: While checking the validity of a key, GnuPG sometimes prints
some information which is prefixed with information about
the checked item.
"key 12345678.3456"
This is about the key with key ID 12345678 and the internal
number 3456, which is the record number of the so called
directory record in the trustdb.
"uid 12345678.3456/ACDE"
This is about the user ID for the same key. To identify the
user ID the last two bytes of a ripe-md-160 over the user ID
ring is printed.
"sig 12345678.3456/ACDE/9A8B7C6D"
This is about the signature with key ID 9A8B7C6D for the
above key and user ID, if it is a signature which is direct
on a key, the user ID part is empty (..//..).
Q: How do I sign a patch file?
A: Use "gpg --clearsign --not-dash-escaped ...".
The problem with --clearsign is that all lines starting with a dash are
quoted with "- "; obviously diff produces many of lines starting with a
dash and these are then quoted and that is not good for patch ;-). To
use a patch file without removing the cleartext signature, the special
option --not-dash-escaped may be used to suppress generation of these
escape sequences. You should not mail such a patch because spaces and
line endings are also subject to the signature and a mailer may not
preserve these. If you want to mail a file you can simply sign it
using your MUA.
Q: Where is the "encrypt-to-self" option?
A: Use "--encrypt-to your_keyid". You can use more than one
of these options. To temporary override the use of this additional
keys, you can use the option "--no-encrypt-to".
Q: How can I get rid of the Version and Comment headers in
armored messages?
A: Use "--no-version --comment ''". Note that the left over blank line
is required by the protocol.
Q: What does the "You are using the xxxx character set." mean?
A: This note is printed when UTF8 mapping has to be done. Make sure that
the displayed charset is the one you have activated on your system
"iso-8859-1" is the most used one, so this is the default. You can
change the charset with the option "--charset". It is important that
you active character set matches the one displayed - if not, restrict
yourself to plain 7 bit ASCII and no mapping has to be done.
Q: How do I transfer owner trust values from PGP to GnuPG?
A: There is a script in the tools directory to help you:
After you have imported the PGP keyring you can give this command:
$ lspgpot pgpkeyring | gpg --import-ownertrust
where pgpkeyring is the original keyring and not the GnuPG one you
might have created in the first step.
Q: Are the headerlines of a cleartext signater part of the signed
material?
A: No. For example you can add or remove "Comment:" lines. They
have a purpose like the mail header lines. However a "Hash:"
line is needed for modern signatures, to tell the parser which
hash algorithm to use.

75
doc/HACKING
View file

@ -10,12 +10,13 @@ CVS Access
==========
Anonymous read-only CVS access is available:
cvs -z6 -d :pserver:anonymous@ftp.guug.de:/home/koch/cvs login
cvs -z3 -d :pserver:anoncvs@cvs.gnupg.org:/cvs/gnupg login
use the password "anonymous". To check out the the complete
use the password "anoncvs". To check out the the complete
archive use:
cvs -z6 -d :pserver:anonymous@ftp.guug.de:/home/koch/cvs checkout gnupg
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
@ -112,6 +113,74 @@ Directory Layout
./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

93
doc/Makefile.am
View file

@ -1,42 +1,77 @@
# Copyright (C) 1998, 1999, 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
## Process this file with automake to create Makefile.in
BUILT_SOURCES = version.sgml
AUTOMAKE_OPTIONS = no-texinfo.tex
EXTRA_DIST = DETAILS gpg.sgml gpg.1 gpgv.sgml gpgv.1 faq.raw FAQ faq.html \
HACKING OpenPGP README.W32 samplekeys.asc
man_MANS = gpg.1 gpgv.1
info_TEXINFOS = gpg.texi gpgv.texi
# Need this to avoid building of dvis with automake 1.4
DVIS =
pkgdata_DATA = FAQ faq.html
BUILT_SOURCES = FAQ faq.html
# we can't add gpg.texi gpgv.texi here because automake does not like them to
# be built files.
CLEANFILES = faq.raw.xref gpg.xml gpgv.xml
#EXTRA_DIST = DETAILS gpg.sgml gpg.1 FAQ HACKING OpenPGP \
# version.sgml.in $(BUILT_SOURCES)
EXTRA_DIST = DETAILS HACKING OpenPGP FAQ
%.texi : %.xml
if HAVE_DOCBOOK_TO_TEXI
docbook2texi $< | sed 's,--,---,' >$@
else
: Warning: missing docbook to texinfo tools, cannot make $@
touch $@
endif
#man_MANS = gpg.1
### pkgdata_DATA = gcryptref.html gcryptref.ps
%.xml : %.sgml
if HAVE_DOCBOOK_TO_TEXI
sgml2xml -x lower $< >$@
else
: Warning: missing docbook to texinfo tools, cannot make $@
touch $@
endif
# gcryptref.sgml : version.sgml
if HAVE_DB2MAN
%.1 : %.sgml
$(DB2MAN) $< >$@
endif
if HAVE_DB2TEX
%.ps : %.dvi
dvips -o $@ $<
%.tex : %.sgml
$(DB2TEX) -V generate-book-toc $< > $@
%.dvi : %.tex
$(JADETEX) $<
endif
if HAVE_DB2HTML
%.html : %.sgml
$(DB2HTML) --nosplit $<
if HAVE_DOCBOOK_TO_MAN
docbook-to-man $< >$@
else
: Warning: missing docbook-to-man, cannot make $@
echo ".TH $< 1" >$@
echo "No man page due to missing docbook-to-man" >>$@
endif
FAQ : faq.raw
$(FAQPROG) -f $< $@ || $(FAQPROG) -f $< $@
faq.html : faq.raw
$(FAQPROG) -h -f $< $@ 2>&1 || $(FAQPROG) -h -f $< $@
dist-hook:
@if test "`wc -c < gpg.1`" -lt 200; then \
echo 'ERROR: dummy man page'; false; fi

17
doc/OpenPGP
View file

@ -8,11 +8,7 @@
Compatibility Notes
===================
GnuPG (>0.4.5) is in compliance with RFC2440 despite these exceptions:
* (9.1) states that RSA SHOULD be implemented. This is not done
(except with an extension, usable outside the U.S.) due to
patent problems.
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.
@ -21,7 +17,7 @@
All MAY features are implemented with this exception:
* multi-part armored messages are not supported.
MIME should be used instead.
MIME (rfc2015) should be used instead.
Most of the OPTIONAL stuff is implemented.
@ -33,6 +29,15 @@
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:
==========================================

95
doc/README.W32 Normal file
View file

@ -0,0 +1,95 @@
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" 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\HomeDir
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\MODir
(Example entry: "c:/gnu/locale/fr")
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.0.n.tar.gz
or for snapshots (with a letter appended to the version number)
ftp://ftp.gnupg.org/gcrypt/devel/gnupg-1.0.nx.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

932
doc/faq.raw Normal file
View file

@ -0,0 +1,932 @@
[$htmltitle=GnuPG FAQ]
[$sfaqheader=The GnuPG FAQ says:]
[$sfaqfooter=
The most recent version of the FAQ is available from
<http://www.gnupg.org/>
]
[$usenetheader=
]
[$maintainer=Douglas Calvert, <faq 'at' gnupg.org> ]
[$hGPG=http://www.gnupg.org]
[H body bgcolor=#ffffff text=#000000 link=#1f00ff alink=#ff0000 vlink=#9900dd]
[H H1]GNUPG FREQUENTLY ASKED QUESTIONS[H /H1]
Version: 1.5.6[H p]
Last-Modified: Sep 14, 2001[H p]
Maintained-by: [$maintainer]
This is the GnuPG FAQ. The latest HTML version is available
[H a href=[$hGPG]/faq.html] here[H/a].
The index is generated automatically, so there may be errors here. Not
all questions may be in the section they belong to. Suggestions about
how to improve the structure of this FAQ are welcome.
Please send additions and corrections to the maintainer. It would be
most convenient if you could provide the answer to be included
here. Your help is very much appreciated.
Please, don't send message like "This should be a FAQ - what's the
answer?". If it hasn't been asked before, it isn't a FAQ. In that case
you could search in the mailing list archive.
[H HR]
<C>
[H HR]
<S> GENERAL
<Q> What is GnuPG?
[H a href=[$hGPG]]GnuPG[H /a] stands for GNU Privacy Guard and
is GNU's tool for secure communication and data storage.
It can be used to encrypt data and to create digital signatures.
It includes an advanced key management facility and is compliant
with the proposed OpenPGP Internet standard as described in
[H a href=http://www.gnupg.org/rfc2440.html]RFC 2440[H/a]. As
such, it is aimed to be compatible with PGP from NAI Inc.
<Q> Is GnuPG compatible with PGP?
In general, yes. GnuPG and newer PGP releases should be implementing
the OpenPGP standard. But there are some interoperability
problems. See questions <Rcompat>ff. for details.
<S> SOURCES of INFORMATION
<Q> Where can I find more information?
Here's a list of on-line resources: [H UL]
[H LI] [H a href=[$hGPG]/docs.html]<[$hGPG]/docs.html>[H/a] is the
documentation page. Have a look at the HOWTOs and the GNU Privacy
Handbook (GPH, available in English, Spanish and Russian). The
latter provides a detailed user's guide to GnuPG. You'll also find a
document about how to convert from PGP 2.x to GnuPG.
[H LI] On [H a href=http://lists.gnupg.org]<http://lists.gnupg.org>[H/a]
you'll find an online archive of the GnuPG mailing lists. Most
interesting should be gnupg-users for all user-related issues and
gnupg-devel if you want to get in touch with the developers.
In addition, searchable archives can be found on MARC, e.g.:
GnuPG-users: [H a href=http://marc.theaimsgroup.com/?l=gnupg-users&r=1&w=2]<http://marc.theaimsgroup.com/?l=gnupg-users&r=1&w=2>[H/a],
GnuPG-devel: [H a href=http://marc.theaimsgroup.com/?l=gnupg-devel&r=1&w=2]<http://marc.theaimsgroup.com/?l=gnupg-devel&r=1&w=2>[H/a].
[H B]PLEASE:[H/B]
Before posting to a list, read this FAQ and the available
documentation. In addition, search the list archive - maybe your
question has already been discussed. This way you help people focus
on topics that have not yet been resolved.
[H LI] The GnuPG source distribution contains a subdirectory
[H PRE]./doc[H /PRE] where some additional documentation is located
(mainly interesting for hackers, not the casual user).
[H /UL]
<Q> Where do I get GnuPG?
You can download the GNU Privacy Guard from its primary FTP server
[H a href=ftp://ftp.gnupg.org/pub/gcrypt]ftp.gnupg.org[H /a] or from
one of the mirrors: [H a href=[$hGPG]/mirrors.html]<[$hGPG]/mirror.html>[H /a]
The current version is 1.0.4, please upgrade to this version as it
fixes a security bug regarding the verification of multiple signatures.
<S> INSTALLATION
<Q> Which OSes does GnuPG run on?
It should run on most Unices as well as Windows 95 and Windows NT. A
list of OSes reported to be OK is presented at
[H a href=http://www.gnupg.org/backend.html#supsys]
http://www.gnupg.org/gnupg.html#supsys [H /a].
<Q> Which random gatherer should I use?
"Good" random numbers are crucial for the security of your
encryption. Different operating systems provide a variety of more or
less quality random data. Linux and *BSD provide kernel generated
random data through /dev/random - this should be the preferred
choice on these systems. Also Solaris users with the SUNWski package
installed have a /dev/random. In these cases, use the configure
option [H pre]--enable-static-rnd=linux[H/pre]. In addition, there's
also the kernel random device by Andi Maier [H a href= http://www.cosy.sbg.ac.at/~andi]
<http://www.cosy.sbg.ac.at/~andi>[H /a], but it's still beta. Use at
own risk!
On other systems, the Entropy Gathering Daemon (EGD) is a good
choice. It is a perl-daemon that monitors system activity and hashes
it into random data. See the download page [H a href=http://www.gnupg.org/download.html]<http://www.gnupg.org/download.html>[H /a]
how to obtain egd. Use [H pre]--enable-static-rnd=egd[H/pre] here.
If the above options do not work, you can use the random number
generator "unix". This is [H B]very[H /B] slow and should be
avoided. The random quality isn't very good so don't use it on
sensitive data.
<Didea>
<Q> How do I include support for RSA and IDEA?
RSA is included as of GnuPG 1.0.3.
The official GnuPG distribution does not contain IDEA due to a
patent restriction. The patent does not expire before 2007 so don't
expect official support before then.
However, there is an unofficial module to include it even
in earlier version of GnuPG. It's available from [H a href=ftp://ftp.gnupg.org/pub/gcrypt/contrib/]
<ftp://ftp.gnupg.org/pub/gcrypt/contrib/>[H /a]. Look for [H pre]idea.c[H /pre].
Compilation directives are in the headers of these files. Then add
the following line to your ~/.gnupg/options:
[H pre]
load-extension idea
[H /pre]
<S> USAGE
<Q> What is the recommended key size?
1024 bit for DSA signatures; even for plain ElGamal
signatures this is sufficient as the size of the hash
is probably the weakest link if the key size is larger
than 1024 bits. Encryption keys may have greater sizes,
but you should then check the fingerprint of this key:
"gpg --fingerprint <user ID>".
As for the key algorithms, you should stick with the default (i.e.,
DSA signature and ElGamal encryption). A ElGamal signing key has the
following disadvantages: the signature is larger, it is hard to
create such a key useful for signatures which can withstand some
real world attacks, you don't get any extra security compared to
DSA, there might be compatibility problems with certain PGP
versions. It has only been introduced because at the time it was
not clear whether there was a patent on DSA.
<Q> Why does it sometimes take so long to create keys?
The problem here is that we need a lot of random bytes and for that
we (on Linux the /dev/random device) must collect some random data.
It is really not easy to fill the Linux internal entropy buffer; I
talked to Ted Ts'o and he commented that the best way to fill the
buffer is to play with your keyboard. Good security has its price.
What I do is to hit several times on the shift, control, alternate,
and caps lock keys, because these keys do not produce output to the
screen. This way you get your keys really fast (it's the same thing
PGP2 does).
Another problem might be another program which eats up your random
bytes (a program (look at your daemons) that reads from
/dev/[u]random).
<Q> And it really takes long when I work on a remote system. Why?
Don't do this at all! You should never create keys or even use GnuPG
on a remote system because you normally have no physical control
over your secret key ring (which is in most cases vulnerable to
advanced dictionary attacks) - I strongly encourage everyone to only
create keys on a local computer (a disconnected laptop is probably
the best choice) and if you need it on your connected box (I know:
We all do this) be sure to have a strong password for your account
and for your secret key and that you can trust your system
administrator.
When I check GnuPG on a remote system via ssh (I have no Alpha here
;-) I have the same problem. It takes a *very* long time to create
the keys, so I use a special option, --quick-random, to generate
insecure keys which are only good for some tests.
<Q> What is the difference between options and commands?
If you do a 'gpg --help', you will get two separate lists. The first
is a list of commands. The second is a list of options. Whenever you
run GPG, you [H B]must[H /B] pick exactly one command (with one
exception, see below). You [H B]may[H /B] pick one or more options.
The command should, just by convention, come at the end of the
argument list, after all the options. If the command takes a file
(all the basic ones do), the filename comes at the very end. So the
basic way to run gpg is:
[H pre]
gpg [--option something] [--option2] [--option3 something] --command file
[H/pre]
Some options take arguments, for example the --output option (which
can be abbreviated -o) is an option that takes a filename. The
option's argument must follow immediately after the option itself,
otherwise gpg doesn't know which option the argument is supposed to
go with. As an option, --output and its filename must come before
the command. The --recipient (-r) option takes a name or keyid to
encrypt the message to, which must come right after the -r argument.
The --encrypt (or -e) command comes after all the options followed
by the file you wish to encrypt. So use
[H pre]
gpg -r alice -o secret.txt -e test.txt
[H/pre]
If you write the options out in full, it is easier to read
[H pre]
gpg --recipient alice --output secret.txt --encrypt test.txt
[H/pre]
If you're saving it in a file called ".txt" then you'd probably
expect to see ASCII-armored text in there, so you need to add the
--armor (-a) option, which doesn't take any arguments.
[H pre]
gpg --armor --recipient alice --output secret.txt --encrypt test.txt
[H/pre]
If you imagine square brackets around the optional parts, it becomes
a bit clearer:
[H pre]
gpg [--armor] [--recipient alice] [--output secret.txt] --encrypt test.txt
[H/pre]
The optional parts can be rearranged any way you want.
[H pre]
gpg --output secret.txt --recipient alice --armor --encrypt test.txt
[H/pre]
If your filename begins with a hyphen (e.g. "-a.txt"), gnupg assumes
this is an option and may complain. To avoid this you have either
to use "./-a.txt" or stop the option and command processing with two
hyphens: "-- -a.txt".
[H B]The exception:[H /B] signing and encrypting at the same time. Use
[H pre] gpg [--options] --sign --encrypt foo.txt [H/pre]
<Q> I can't delete a user id because it is already deleted on my public
keyring?
Because you can only select from the public key ring, there is no
direct way to do this. However it is not very complicated to do it
anyway. Create a new user id with exactly the same name and you
will see that there are now two identical user ids on the secret
ring. Now select this user id and delete it. Both user ids will be
removed from the secret ring.
<Q> I can't delete the secret key because my public key disappeared?
To select a key a search is always done on the public keyring,
therefore it is not possible to select an secret key without
having the public key. Normally it shoud never happen that the
public key got lost but the secret key is still available. The
reality is different, so we GnuPG implements a special way to do
deal with it: Simply use the long keyid which you can figure out
by using the --with-colons options (it is the fifth field in the
lines beginning with "sec").
<Q> What are trust, validity and ownertrust?
"ownertrust" is used instead of "trust" to make clear that this is
the value you have assigned to a key to express how much you trust
the owner of this key to correctly sign (and so introduce) other
keys. "validity", or calculated trust, is a value which says how
much GnuPG thinks a key is valid (that it really belongs to the one
who claims to be the owner of the key). For more see the chapter
"The Web of Trust" in the Manual.
<Q> How do I sign a patch file?
Use "gpg --clearsign --not-dash-escaped ...". The problem with
--clearsign is that all lines starting with a dash are quoted with
"- "; obviously diff produces many of lines starting with a dash and
these are then quoted and that is not good for patch ;-). To use a
patch file without removing the cleartext signature, the special
option --not-dash-escaped may be used to suppress generation of
these escape sequences. You should not mail such a patch because
spaces and line endings are also subject to the signature and a
mailer may not preserve these. If you want to mail a file you can
simply sign it using your MUA.
<Q> Where is the "encrypt-to-self" option?
Use "--encrypt-to your_keyid". You can use more than one of these
options. To temporary override the use of this additional keys, you
can use the option "--no-encrypt-to".
<Q> How can I get rid of the Version and Comment headers in armored
messages?
Use "--no-version --comment ''". Note that the left over blank line
is required by the protocol.
<Q> What does the "You are using the xxxx character set." mean?
This note is printed when UTF8 mapping has to be done. Make sure
that the displayed charset is the one you have activated on your
system "iso-8859-1" is the most used one, so this is the default.
You can change the charset with the option "--charset". It is
important that you active character set matches the one displayed -
if not, restrict yourself to plain 7 bit ASCII and no mapping has to
be done.
<Q> How can a get list of key IDs used to encrypt a message?
[H pre] gpg --batch --decrypt --list-only --status-fd 1 2>/dev/null | \
awk '/^\[GNUPG:\] ENC_TO / { print $3 }' [H /pre]
<Q> I can't decrypt my symmetrical only (-c) encrypted message with
a new version of GnuPG.
There used to be a bug in GnuPG < 1.0.1 which happens only if 3DES
or Twofish has been used for symmetric only encryption (this has
never been the default). The bug has been fixed but to enable you
to decrypt old messages, you should run gpg with the option
"--emulate-3des-s2k-bug", decrypt the message and encrypt it again
without this option. The option will be removed in 1.1, so better
re-encrypt your message now.
<Q> How can I use GnuPG in an automated environment?
You should use the option --batch and don't use pass phrases as
there is usually no way to store it more secure than the secret
keyring itself. The suggested way to create the keys for the
automated environment is:
On a secure machine:
[H OL] [H LI] If you want to do automatic signing, create a signing
subkey for your key (edit menu, choose "addkey" and the DSA). [H
LI] Make sure that you use a passphrase (Needed by the current
implementation) [H LI] gpg --export-secret-subkeys --no-comment foo
>secring.auto [H LI] Copy secring.auto and the public keyring to a
test directory. [H LI] Cd to this directory. [H LI] gpg --homedir
. --edit foo and use "passwd" to remove the pass-phrase from the
subkeys. You may also want to remove all unused subkeys. [H LI]
copy secring.auto to a floppy and carry it to the target box [H /OL]
On the target machine: [H OL] [H LI] Install secring.auto as secret
keyring. [H LI] Now you can start your new service. It is a good
idea to install some intrusion detection system so that you
hopefully get a notice of an successful intrusion, so that you in
turn can revoke all the subkeys installed on that machine and
install new subkeys. [H /OL]
<Q> Which email-client can I use with GnuPG?
Using GnuPG to encrypt email is one of the most popular
uses. Several mail clients or mail user-agents (MUA) support GnuPG
at varying degrees. Simplifying a bit, there are two ways a mail can
be encrypted with GnuPG: the "old style" ASCII armor, i.e. plain
text encryption, and RFC2015 style (previously PGP/MIME, now
OpenPGP). The latter has full MIME support. Some MUAs support only
one of them, so whichever you actually use depends on your needs as
well as the capabilities of your addressee.
The following list is probably not exhaustive:
OpenPGP: Mutt (Unix), Emacs/Mew, Becky2 (Windows, with plugin),
TkRat (Unix). There is effort for a Mozilla plugin and
Emacs/GNUS has support in the current CVS.
ASCII: Emacs/{VM,GNUS}/MailCrypt, Mutt(Unix), Pine(Unix), and
probably many more.
Good overviews of OpenPGP-support can be found at
[H a href=http://cryptorights.org/pgp-users/pgp-mail-clients.html]http://cryptorights.org/pgp-users/pgp-mail-clients.html[H /a].
and [H a href=http://www.geocities.com/openpgp/courrier_en.html]http://www.geocities.com/openpgp/courrier_en.html[H /a].
<Q> Can't we have a gpg library?
This has been frequently requested. However, the current viewpoint
of the GnuPG maintainers is that this would lead to several security
issues and will therefore not be implemented in the foreseeable
future. However, for some areas of areas of application gpgme could
do the trick. You'll find it at
[H a href=ftp://ftp.guug.de/pub/gcrypt/alpha/gpgme]ftp://ftp.guug.de/pub/gcrypt/alpha/gpgme[H /a]
<Q> I have successfully generated a revocation certificate, but I don't
understand how to send it to the key servers.
Most keyservers don't accept a 'bare' revocation certificate. You
have to import the certificate into gpg first:
[H pre]
gpg --import my-revocation.asc
[H /pre]
then send the revoked key to the keyservers:
[H pre]
gpg --keyserver certserver.pgp.com --send-keys mykeyid
[H /pre]
(or use a keyserver web interface for this).
<Q> How do I put my keyring in a different directory?
GnuPG keeps several files in a special homedir directory. These
include the options file, pubring.gpg, secring.gpg, the trustdb, and
others. Gnupg will always create and use these files. On unices,
the homedir is usually ~/.gnupg; on Windows "C:\gnupg\".
If you want to put your keyrings somewhere else, use
[H pre]--homedir /my/path/[H /pre] to make gnupg create all its
files in that directory. Your keyring will be
"/my/path/pubring.gpg". This way you can store your secrets on a
floppy disk. Don't use "--keyring" as its purpose is to specify
additional keyring files.
<S> COMPATIBILITY ISSUES
<Dcompat>
<Q> How can I encrypt a message with GnuPG so that PGP is able to decrypt it?
It depends on the PGP version.[H UL]
[H LI] PGP 2.x
You can't do that because PGP 2.x normally uses IDEA which is not
supported by GnuPG as it is patented (see <Ridea>), but if you
have a modified version of PGP you can try this:
[H pre] gpg --rfc1991 --cipher-algo 3des ... [H/pre]
Please don't pipe the data to encrypt to gpg but provide it using a
filename; otherwise, PGP 2 will not be able to handle it.
As for conventional encryption, you can't do this for PGP 2.
[H LI] PGP 5.x and higher
You need to provide two additional options:
[H pre]--compress-algo 1 --cipher-algo cast5 [H/pre]
You may also use "3des" instead of "cast5", "blowfish" does not
work with all versions of pgp5. You may also want to put [H pre]
compress-algo 1 [H/pre] into your ~/.gnupg/options file - this does
not affect normal gnupg operation.
This applies to conventional encryption as well.
[H /UL]
<Q> How do I migrate from PGP 2.x to GnuPG?
PGP 2 uses the RSA and IDEA encryption algorithms. Whereas the RSA
patent has expired and RSA is included as of GnuPG 1.0.3, the IDEA
algorithm is still patented until 2007. Under certain conditions you
may use IDEA even today. In that case, you may refer to Question
<Ridea> about how to add IDEA support to GnuPG and read
[H a href=http://www.gnupg.org/gph/en/pgp2x.html]http://www.gnupg.org/gph/en/pgp2x.html[H /a]
to perform the migration.
<Q> (removed)
(empty)
<Q> Why is PGP 5.x not able to encrypt messages with some keys?
PGP Inc refuses to accept ElGamal keys of type 20 even for
encryption. They only support type 16 (which is identical at least
for decryption). To be more inter-operable, GnuPG (starting with
version 0.3.3) now also uses type 16 for the ElGamal subkey which is
created if the default key algorithm is chosen. You may add an type
16 ElGamal key to your public key which is easy as your key
signatures are still valid.
<Q> Why is PGP 5.x not able to verify my messages?
PGP 5.x does not accept V4 signatures for data material but OpenPGP
requests generation of V4 signatures for all kind of data, that's why
GnuPG defaults to them. Use the option "--force-v3-sigs" to generate
V3 signatures for data.
<Q> How do I transfer owner trust values from PGP to GnuPG?
There is a script in the tools directory to help you: After you have
imported the PGP keyring you can give this command:
[H pre]
$ lspgpot pgpkeyring | gpg --import-ownertrust
[H /pre]
where pgpkeyring is the original keyring and not the GnuPG one you
might have created in the first step.
<Q> PGP does not like my secret key.
Older PGPs probably bail out on some private comment packets used by
GnuPG. These packets are fully in compliance with OpenPGP; however
PGP is not really OpenPGP aware. A workaround is to export the
secret keys with this command:
[H pre] $ gpg --export-secret-keys --no-comment -a your-key-id [H /pre]
Another possibility is this: by default, GnuPG encrypts your secret
key using the Blowfish symmetric algorithm. Older PGPs will only
understand 3DES, CAST5, or IDEA symmetric algorithms. Using the
following method you can re-encrypt your secret gpg key with a
different algo:
[H pre]
$ gpg --s2k-cipher-algo=CAST5 --s2k-digest-algo=SHA1 \
--compress-algo=1 --edit-key <username>
[H /pre]
Then use passwd to change the password (just change it to the same
thing, but it will encrypt the key with CAST5 this time).
Now you can export it and PGP should be able to handle it.
For PGP 6.x the following options work to export a key:
[H pre]
$ gpg --s2k-cipher-algo 3des --compress-algo 1 --rfc1991 \
--export-secret-keys <Key-ID>
[H /pre]
<S> PROBLEMS and ERROR MESSAGES
<Q> Why do I get "gpg: Warning: using insecure memory!"
On many systems this program should be installed as
setuid(root). This is necessary to lock memory pages. Locking
memory pages prevents the operating system from writing them
to disk and thereby keeping your secret keys really secret. If you
get no warning message about insecure memory your operating system
supports locking without being root. The program drops root
privileges as soon as locked memory is allocated.
On UnixWare 2.x and 7.x you should install GnuPG with the
'plock' privilege to get the same effect:
[H pre]
filepriv -f plock /path/to/gpg
[H /pre]
If you can't or don't want to install GnuPG setuid(root), you can
use the option "--no-secmem-warning" or put [H pre]
no-secmem-warning [H /pre] in your ~/.gnupg/options file (this
disables the warning).
On some systems (e.g., Windows) GnuPG does not lock memory pages
and older GnuPG versions (<=1.0.4) issue the warning
[H pre]
gpg: Please note that you don't have secure memory
[H /pre]
This warning can't be switched off by the above option because it
was thought to be a too serious issue. However, it confused users
too much so the warning was eventually removed.
<Q> Large File Support doesn't work ..
LFS is correctly working in post-1.0.4 CVS. If configure doesn't
detect it correctly, try a different (i.e., better) compiler. egcs
1.1.2 works fine, other gccs sometimes don't. BTW, several
compilation problems of GnuPG 1.0.3 and 1.0.4 on HP-UX and Solaris
were due to broken LFS support.
<Q> In the edit menu the trust values is not displayed correctly after
signing uids - why?
This happens because the some informations are stored immediately in
the trustdb, but the actual trust calculation can be done after the
save command. This is a not easy to fix design bug which will be
addressed in some future release.
<Q> What does "skipping pubkey 1: already loaded" mean?
As of GnuPG 1.0.3, the RSA algorithm is included. If you still have
a "load-extension rsa" in your .options files, the above message
occurs. Just remove the load command from the .options file.
<Q> GnuPG 1.0.4 doesn't create ~/.gnupg ...
That's a known bug, already fixed in newer versions.
<Q> An ElGamal signature does not verify anymore since version 1.0.2 ...
Use the option --emulate-md-encode-bug.
<Q> Old versions of GnuPG can't verify ElGamal signatures
Update to GnuPG 1.0.2 or newer.
<Q> When I use --clearsign, the plain text has sometimes extra dashes
in it - why?
This is called dash-escaped text and required by OpenPGP.
It always happens when a line starts with a dash ("-") and is needed
to make the lines that structure signature and text
(i.e., "-----BEGIN PGP SIGNATURE-----") to be the only lines that
start with two dashes.
If you use GnuPG to process those messages, the extra dashes are removed.
Good mail clients remove those extra dashes when displaying such a
message.
<Q> What is the thing with "can't handle multiple signatures"?
Due to different message formats GnuPG is not always able to split a
file with multiple signatures unambiguously into its parts. This
error message informs you that there is something wrong with the input.
The only way to have multiple signatures in a file is by using the
OpenPGP format with one-pass-signature packets (which is GnuPG's
default) or the cleartext signed format.
<Q> If I submit a key to a keyserver, nothing happens ...
You are most likely using GnuPG on Windows 1.0.2 or older. That's
feature isn't yet implemented, but it's a bug not to say it. Newer
versions issue a warning. Upgrade to 1.0.4 or newer.
<Q> I get "gpg: waiting for lock ..."
A previous gpg has most likely exited abnormally and left a lock
file. Go to ~/.gnupg and look for .*.lock files and remove them.
<Q> Older gpg's (e.g., 1.0) have problems with keys from newer gpgs ...
As of 1.0.3, keys generated with gpg are created with preferences to
TWOFISH (and AES since 1.0.4) and that also means that they have the
capability to use the new MDC encryption method. This will go into
OpenPGP soon and is also suppoted by PGP 7. This new method avoids
a (not so new) attack on all email encryption systems.
This in turn means that pre-1.0.3 gpg's have problems with newer
key. Because of security fixes, you should keep your gpg
installation in a recent state anyway. As a workaround, you can
force gpg to use a previous default cipher algo by putting
[H pre]cipher-algo cast5[H /pre] into your options file.
<Q> With 1.0.4, I get "this cipher algorithm is deprecated ..."
If you just generated a new key and get this message while
encrypting, you've witnessed a bug in 1.0.4. It uses the new AES
cipher Rijndael that is incorrectly being referred as
"deprecated". Ignore this warning, more recent versions of gpg are
corrected.
<Q> Some dates are displayed as ????-??-??, why?
Due to constraints in most libc implementations, dates beyond
2038-01-19 can't be displayed correctly. 64 bit OSes are not
affected by this problem. To avoid printing wrong dates, GnuPG
instead prints some question marks. To see the correct value, you
can use the options --with-colons and --fixed-list-mode.
<Q> I still have a problem. How do I report a bug?
Are you sure that it's not been mentioned somewhere on the mailing
lists? Did you have a look at the bug list (You'll find a link to
the list of reported bugs on the documentation page). If you're not
sure about it being a bug, you can send mail to the gnupg-devel
list. Otherwise, use the GUUG bug tracking system
[H a href=http://bugs.guug.de/Reporting.html]
http://bugs.guug.de/Reporting.html[H /a].
<Q> Why doesn't GnuPG support X509 certificates?
GnuPG, first and foremost, is an implementation of the OpenPGP
standard (RFC 2440), which is a competing infrastructure, different
from X509.
They are both public-key cryptosystems, but how the public keys are
actually handled is different.
<Q> Why do national characters in my user ID look funny?
According to OpenPGP, GnuPG encodes user id strings (and other
things) using UTF-8. In this encoding of Unicode, most national
characters get encoded as two- or three-byte sequences. For
example, &aring; (0xE5 in ISO-8859-1) becomes &Atilde;&yen; (0xC3,
0xA5). This might also be the reason why keyservers can't find
your key.
<Q> I get 'sed' errors when running ./configure on Mac OS X ...
This will be fixed after GnuPG has been upgraded to
autoconf-2.50. Until then, find the line setting CDPATH in the
configure script and place a [H pre]unset CDPATH[H /pre] statement
below it.
<Q> Why does GnuPG 1.0.6 bail out on keyrings used with 1.0.7?
There is a small bug in 1.0.6 which didn't parse trust packets
currectly. You may want to apply this patch if you can't upgrade:
http://www.gnupg.org/developer/gpg-woody-fix.txt
<S> ADVANCED TOPICS
<Q> How does this whole thing work?
To generate a secret/public keypair, run [H pre] gpg --gen-key
[H/pre] and choose the default values.
Data that is encrypted with a public key can only be decrypted by
the matching secret key. The secret key is protected by a password,
the public key is not.
So to send your friend a message, you would encrypt your message
with his public key, and he would only be able to decrypt it by
having the secret key and putting in the password to use his secret
key.
GnuPG is also useful for signing things. Things that are encrypted
with the secret key can be decrypted with the public key. To sign
something, a hash is taken of the data, and then the hash is in some
form encoded with the secret key. If someone has your public key, they
can verify that it is from you and that it hasn't changed by checking
the encoded form of the hash with the public key.
A keyring is just a large file that stores keys. You have a public
keyring where you store yours and your friend's public keys. You have
a secret keyring that you keep your secret key on, and be very careful
with this secret keyring: Never ever give anyone else access to it and
use a *good* passphrase to protect the data in it.
You can 'conventionally' encrypt something by using the option 'gpg
-c'. It is encrypted using a passphrase, and does not use public and
secret keys. If the person you send the data to knows that
passphrase, they can decrypt it. This is usually most useful for
encrypting things to yourself, although you can encrypt things to your
own public key in the same way. It should be used for communication
with partners you know and where it is easy to exchange the
passphrases (e.g. with your boy friend or your wife). The advantage
is that you can change the passphrase from time to time and decrease
the risk, that many old messages may be decrypted by people who
accidently got your passphrase.
You can add and copy keys to and from your keyring with the 'gpg
--import' and 'gpg --export' option. 'gpg --export-secret-keys' will
export secret keys. This is normally not useful, but you can generate
the key on one machine then move it to another machine.
Keys can be signed under the 'gpg --edit-key' option. When you sign a
key, you are saying that you are certain that the key belongs to the
person it says it comes from. You should be very sure that is really
that person: You should verify the key fingerprint
[H pre]
gpg --fingerprint user-id
[H/pre]
over phone (if you really know the voice of the other person) or at a
key signing party (which are often held at computer conferences) or at
a meeting of your local GNU/Linux User Group.
Hmm, what else. You may use the option "-o filename" to force output
to this filename (use "-" to force output to stdout). "-r" just lets
you specify the recipient (which public key you encrypt with) on the
command line instead of typing it interactively.
Oh yeah, this is important. By default all data is encrypted in some
weird binary format. If you want to have things appear in ASCII text
that is readable, just add the '-a' option. But the preferred method
is to use a MIME aware mail reader (Mutt, Pine and many more).
There is a small security glitch in the OpenPGP (and therefore GnuPG)
system; to avoid this you should always sign and encrypt a message
instead of only encrypting it.
<Q> Why are some signatures with an ELG-E key valid?
These are ElGamal Key generated by GnuPG in v3 (rfc1991) packets.
The OpenPGP draft later changed the algorithm identifier for ElGamal
keys which are usable for signatures and encryption from 16 to 20.
GnuPG now uses 20 when it generates new ElGamal keys but still
accept 16 (which is according to OpenPGP "encryption only") if this
key is in a v3 packet. GnuPG is the only program which had used
these v3 ElGamal keys - so this assumption is quite safe.
<Q> How does the whole trust thing work?
It works more or less like PGP. The difference is that the trust is
computed at the time it is needed. This is one of the reasons for
the trustdb which holds a list of valid key signatures. If you are
not running in batch mode you will be asked to assign a trust
parameter (ownertrust) to a key.
You can see the validity (calculated trust value) using this
command.
[H pre] gpg --list-keys --with-colons [H/pre]
If the first field is "pub" or "uid", the second field shows you the
trust:
[H pre]
o = Unknown (this key is new to the system)
e = The key has expired
q = Undefined (no value assigned)
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.
r = The key has been revoked
d = The key has been disabled
[H/pre]
The value in the "pub" record is the best one of all "uid" records.
You can get a list of the assigned trust values (how much you trust
the owner to correctly sign another person's key)
[H pre] gpg --list-ownertrust [H/pre] The first field is the
fingerprint of the primary key, the second field is the assigned
value:
[H pre]
- = No Ownertrust value yet assigned.
n = Never trust this keyholder to correctly verify others signatures.
m = Have marginal trust in the keyholders capability to sign other
keys.
f = Assume that the key holder really knows how to sign keys.
u = No need to trust ourself because we have the secret key.
[H/pre]
Keep these values confidential because they express your opinions
about others. PGP stores this information with the keyring thus it
is not a good idea to publish a PGP keyring instead of exporting the
keyring. gnupg stores the trust in the trust-DB so it is okay to
give a gpg keyring away (but we have a --export command too).
<Q> What kind of output is this: "key C26EE891.298, uid 09FB: ...."?
This is the internal representation of a user id in the trustdb.
"C26EE891" is the keyid, "298" is the local id (a record number in
the trustdb) and "09FB" is the last two bytes of a ripe-md-160 hash
of the user id for this key.
<Q> How do I interpret some of the informational outputs?
While checking the validity of a key, GnuPG sometimes prints some
information which is prefixed with information about the checked
item. [H pre] "key 12345678.3456" [H/pre] This is about the key
with key ID 12345678 and the internal number 3456, which is the
record number of the so called directory record in the trustdb.
[H pre] "uid 12345678.3456/ACDE" [H/pre] This is about the user ID for
the same key. To identify the user ID the last two bytes of a
ripe-md-160 over the user ID ring is printed. [H pre] "sig
12345678.3456/ACDE/9A8B7C6D" [H/pre] This is about the signature
with key ID 9A8B7C6D for the above key and user ID, if it is a
signature which is direct on a key, the user ID part is empty
(..//..).
<Q> Are the header lines of a cleartext signature part of the signed
material?
No. For example you can add or remove "Comment:" lines. They have
a purpose like the mail header lines. However a "Hash:" line is
needed for OpenPGP signatures to tell the parser which hash
algorithm to use.
<Q> What is the list of preferred algorithms?
The list of preferred algorithms is a list of cipher, hash and
compression algorithms stored in the self-signature of a key during
key generation. When you encrypt a document, GnuPG uses this list
(which is then part of a public key) to determine which algorithms
to use. Basically it tells other people what algorithms the
recipient is able to handle and provides an order of preference.
<Q> How do I change the list of preferred algorithms?
Use the edit menu and set the new list of preference using the
command "setpref"; the format of this command resembles the output
of the command "pref". The preference are not changes immediately
but the set preference will be used when a new user ID is
created. If you want to update the preferences for existing user
IDs, select those user IDs (or select none to update all) and
enter the command "updpref". Note that the timestamp of the
self-signatures is increaded by one second when running this
command.
<S> ACKNOWLEDGEMENTS
Many thanks to Nils Ellmenreich for maintaining this FAQ file for
a long time and to all posters to gnupg-users and gnupg-devel. They
all provided most of the answers.
Also thanks to Casper Dik for providing me with a script to generate
this FAQ (he uses it for the excellent Solaris2 FAQ).
[H HR]
Copyright (C) 2000, 2002 Free Software Foundation, Inc. ,
59 Temple Place - Suite 330, Boston, MA 02111, USA
Verbatim copying and distribution of this entire article is permitted in
any medium, provided this notice is preserved.

17
doc/fr/ChangeLog Normal file
View file

@ -0,0 +1,17 @@
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 Normal file
View file

@ -0,0 +1,945 @@
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 Normal file
View file

File diff suppressed because it is too large Load diff

10
doc/fr/README.fr Normal file
View file

@ -0,0 +1,10 @@
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 Normal file
View file

@ -0,0 +1,8 @@
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"

1136
doc/gpg.sgml
View file

File diff suppressed because it is too large Load diff

225
doc/gpgv.sgml Normal file
View file

@ -0,0 +1,225 @@
<!-- 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>

115
doc/gpgv.texi Normal file
View file

@ -0,0 +1,115 @@
\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
@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

4
doc/gph/Makefile.am
View file

@ -11,7 +11,7 @@ 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
-test -d manual && cp ./signatures.jpg ./manual/signatures.jpg
index.html: $(PARTS)
@ -27,7 +27,7 @@ index.html: $(PARTS)
echo '</body></html>' >>index.html
-rm -r manual.junk
-rm manual/signatures.jpg
(cd manual; rm -r stylesheet-images; ls | grep -v distfiles >distfiles)
## (cd manual; rm -r stylesheet-images; ls | grep -v distfiles >distfiles)
dist-hook: index.html

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

@ -0,0 +1,232 @@
-----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 Normal file
View file

@ -0,0 +1,624 @@
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-----

1
doc/version.sgml.in
View file

@ -1 +0,0 @@
@VERSION@