diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/ChangeLog | 4 | ||||
| -rw-r--r-- | doc/DETAILS | 1250 | ||||
| -rw-r--r-- | doc/HACKING | 305 | ||||
| -rw-r--r-- | doc/KEYSERVER | 83 | ||||
| -rw-r--r-- | doc/Makefile.am | 32 | ||||
| -rw-r--r-- | doc/OpenPGP | 108 | ||||
| -rw-r--r-- | doc/TRANSLATE | 33 | ||||
| -rw-r--r-- | doc/faq.raw | 1344 | ||||
| -rw-r--r-- | doc/samplekeys.asc | 461 |
9 files changed, 3616 insertions, 4 deletions
diff --git a/doc/ChangeLog b/doc/ChangeLog index a697b2605..b70e70fdc 100644 --- a/doc/ChangeLog +++ b/doc/ChangeLog @@ -1,3 +1,7 @@ +2006-08-21 Werner Koch <[email protected]> + + * Makefile.am: Added other doc files from gpg 1.4. + 2006-08-17 Werner Koch <[email protected]> * Makefile.am: Added rules to build man pages. diff --git a/doc/DETAILS b/doc/DETAILS new file mode 100644 index 000000000..51a31a5b4 --- /dev/null +++ b/doc/DETAILS @@ -0,0 +1,1250 @@ + -*- text -*- +Format of colon listings +======================== +First an example: + +$ gpg --fixed-list-mode --with-colons --list-keys \ + --with-fingerprint --with-fingerprint [email protected] + +pub:f:1024:17:6C7EE1B8621CC013:899817715:1055898235::m:::scESC: +fpr:::::::::ECAF7590EB3443B5C7CF3ACB6C7EE1B8621CC013: +uid:f::::::::Werner Koch <[email protected]>: +uid:f::::::::Werner Koch <[email protected]>: +sub:f:1536:16:06AD222CADF6A6E1:919537416:1036177416:::::e: +fpr:::::::::CF8BCC4B18DE08FCD8A1615906AD222CADF6A6E1: +sub:r:1536:20:5CE086B5B5A18FF4:899817788:1025961788:::::esc: +fpr:::::::::AB059359A3B81F410FCFF97F5CE086B5B5A18FF4: + +The double --with-fingerprint prints the fingerprint for the subkeys +too, --fixed-list-mode is themodern listing way printing dates in +seconds since Epoch and does not merge the first userID with the pub +record. + + + 1. Field: Type of record + pub = public key + crt = X.509 certificate + crs = X.509 certificate and private key available + sub = subkey (secondary key) + sec = secret key + ssb = secret subkey (secondary key) + uid = user id (only field 10 is used). + uat = user attribute (same as user id except for field 10). + sig = signature + rev = revocation signature + fpr = fingerprint: (fingerprint is in field 10) + pkd = public key data (special field format, see below) + grp = reserved for gpgsm + rvk = revocation key + tru = trust database information + spk = signature subpacket + + 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 + (deprecated - use the 'D' in field 12 instead) + r = The key has been revoked + e = The key has expired + - = Unknown trust (i.e. no value assigned) + q = Undefined trust + '-' and 'q' may safely be treated as the same + value for most purposes + n = Don't trust this key at all + m = There is marginal trust in this key + f = The key is fully trusted + u = The key is ultimately trusted. This often means + that the secret key is available, but any key may + be marked as ultimately trusted. + 3. Field: length of key in bits. + 4. Field: Algorithm: 1 = RSA + 16 = Elgamal (encrypt only) + 17 = DSA (sometimes called DH, sign only) + 20 = Elgamal (sign and encrypt - don't use them!) + (for other id's see include/cipher.h) + 5. Field: KeyID + 6. Field: Creation Date (in UTC). For UID and UAT records, this is the + self-signature date. Note that the dae is usally printed + in seconds since epoch, however, we are migrating to an ISO + 8601 format (e.g. "19660205T091500"). This is currently + only relevant for X.509, A simple way to detect the format + is be scannning for the 'T'. + 7. Field: Key or user ID/user attribute expiration date or empty if none. + 8. Field: Used for serial number in crt records (used to be the Local-ID). + For UID and UAT records, this is a hash of the user ID contents + used to represent that exact user ID. For trust signatures, + this is the trust depth seperated by the trust value by a + space. + 9. Field: Ownertrust (primary public keys only) + This is a single letter, but be prepared that additional + information may follow in some future versions. For trust + signatures with a regular expression, this is the regular + expression value, quoted as in field 10. +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 = authentication + A key may have any combination of them in any order. In + addition to these letters, the primary key has uppercase + versions of the letters to denote the _usable_ + capabilities of the entire key, and a potential letter 'D' + to indicate a disabled 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. + For "sig" records, this is the fingerprint of the key that + issued the signature. Note that this is only filled in if + the signature verified correctly. Note also that for + various technical reasons, this fingerprint is only + available if --no-sig-cache is used. + +14. Field Flag field used in the --edit menu output: + +15. Field Used in sec/sbb to print the serial number of a token + (internal protect mode 1002) or a '#' if that key is a + simple stub (internal protect mode 1001) + +All dates are displayed in the format yyyy-mm-dd unless you use the +option --fixed-list-mode in which case they are displayed as seconds +since Epoch. More fields may be added later, so parsers should be +prepared for this. When parsing a number the parser should stop at the +first non-number character so that additional information can later be +added. + +If field 1 has the tag "pkd", a listing looks like this: +pkd:0:1024:B665B1435F4C2 .... FF26ABB: + ! ! !-- the value + ! !------ for information number of bits in the value + !--------- index (eg. DSA goes from 0 to 3: p,q,g,y) + + +The "tru" trust database records have the fields: + + 2: Reason for staleness of trust. If this field is empty, then the + trustdb is not stale. This field may have multiple flags in it: + + o: Trustdb is old + t: Trustdb was built with a different trust model than the one we + are using now. + + 3: Trust model: + 0: Classic trust model, as used in PGP 2.x. + 1: PGP trust model, as used in PGP 6 and later. This is the same + as the classic trust model, except for the addition of trust + signatures. + + GnuPG before version 1.4 used the classic trust model by default. + GnuPG 1.4 and later uses the PGP trust model by default. + + 4: Date trustdb was created in seconds since 1/1/1970. + 5: Date trustdb will expire in seconds since 1/1/1970. + +The "spk" signature subpacket records have the fields: + + 2: Subpacket number as per RFC-2440 and later. + 3: Flags in hex. Currently the only two bits assigned are 1, to + indicate that the subpacket came from the hashed part of the + signature, and 2, to indicate the subpacket was marked critical. + 4: Length of the subpacket. Note that this is the length of the + subpacket, and not the length of field 5 below. Due to the need + for %-encoding, the length of field 5 may be up to 3x this value. + 5: The subpacket data. Printable ASCII is shown as ASCII, but other + values are rendered as %XX where XX is the hex value for the byte. + + +Format of the "--status-fd" output +================================== +Every line is prefixed with "[GNUPG:] ", followed by a keyword with +the type of the status line and a some arguments depending on the +type (maybe none); an application should always be prepared to see +more arguments in future versions. + + + NEWSIG + May be issued right before a signature verification starts. This + is useful to define a context for parsing ERROR status + messages. No arguments are currently defined. + + GOODSIG <long keyid> <username> + The signature with the keyid is good. For each signature only + one of the three codes GOODSIG, BADSIG or ERRSIG will be + emitted and they may be used as a marker for a new signature. + The username is the primary one encoded in UTF-8 and %XX + escaped. + + EXPSIG <long keyid> <username> + The signature with the keyid is good, but the signature is + expired. The username is the primary one encoded in UTF-8 and + %XX escaped. + + EXPKEYSIG <long keyid> <username> + The signature with the keyid is good, but the signature was + made by an expired key. The username is the primary one + encoded in UTF-8 and %XX escaped. + + REVKEYSIG <long keyid> <username> + The signature with the keyid is good, but the signature was + made by a revoked key. The username is the primary one + encoded in UTF-8 and %XX escaped. + + BADSIG <long keyid> <username> + The signature with the keyid has not been verified okay. + The username is the primary one encoded in UTF-8 and %XX + escaped. + + ERRSIG <long keyid> <pubkey_algo> <hash_algo> \ + <sig_class> <timestamp> <rc> + It was not possible to check the signature. This may be + caused by a missing public key or an unsupported algorithm. + A RC of 4 indicates unknown algorithm, a 9 indicates a missing + public key. The other fields give more information about + this signature. sig_class is a 2 byte hex-value. + + Note, that TIMESTAMP may either be a number with seconds since + epoch or an ISO 8601 string which can be detected by the + presence of the letter 'T' inside. + + VALIDSIG <fingerprint in hex> <sig_creation_date> <sig-timestamp> + <expire-timestamp> <sig-version> <reserved> <pubkey-algo> + <hash-algo> <sig-class> <primary-key-fpr> + + The signature with the keyid is good. This is the same as + GOODSIG but has the fingerprint as the argument. Both status + lines are emitted for a good signature. All arguments here + are on one long line. sig-timestamp is the signature creation + time in seconds after the epoch. expire-timestamp is the + signature expiration time in seconds after the epoch (zero + means "does not expire"). sig-version, pubkey-algo, hash-algo, + and sig-class (a 2-byte hex value) are all straight from the + signature packet. PRIMARY-KEY-FPR is the fingerprint of the + primary key or identical to the first argument. This is + useful to get back to the primary key without running gpg + again for this purpose. + + Note, that *-TIMESTAMP may either be a number with seconds + since epoch or an ISO 8601 string which can be detected by the + presence of the letter 'T' inside. + + SIG_ID <radix64_string> <sig_creation_date> <sig-timestamp> + This is emitted only for signatures of class 0 or 1 which + have been verified okay. The string is a signature id + and may be used in applications to detect replay attacks + of signed messages. Note that only DLP algorithms give + unique ids - others may yield duplicated ones when they + have been created in the same second. + + Note, that SIG-TIMESTAMP may either be a number with seconds + since epoch or an ISO 8601 string which can be detected by the + presence of the letter 'T' inside. + + + ENC_TO <long keyid> <keytype> <keylength> + The message is encrypted to this keyid. + keytype is the numerical value of the public key algorithm, + keylength is the length of the key or 0 if it is not known + (which is currently always the case). + + NODATA <what> + No data has been found. Codes for what are: + 1 - No armored data. + 2 - Expected a packet but did not found one. + 3 - Invalid packet found, this may indicate a non OpenPGP + message. + 4 - signature expected but not found + You may see more than one of these status lines. + + UNEXPECTED <what> + Unexpected data has been encountered + 0 - not further specified 1 + + + TRUST_UNDEFINED <error token> + TRUST_NEVER <error token> + TRUST_MARGINAL + TRUST_FULLY + TRUST_ULTIMATE + For good signatures one of these status lines are emitted + to indicate how trustworthy the signature is. The error token + values are currently only emiited by gpgsm. + + PKA_TRUST_GOOD <mailbox> + PKA_TRUST_BAD <mailbox> + Depending on the outcome of the PKA check one of the above + status codes is emitted in addition to a TRUST_* status. + Without PKA info available or + + SIGEXPIRED + This is deprecated in favor of KEYEXPIRED. + + KEYEXPIRED <expire-timestamp> + The key has expired. expire-timestamp is the expiration time + in seconds after the epoch. + + Note, that TIMESTAMP may either be a number with seconds since + epoch or an ISO 8601 string which can be detected by the + presence of the letter 'T' inside. + + KEYREVOKED + The used key has been revoked by its owner. No arguments yet. + + BADARMOR + The ASCII armor is corrupted. No arguments yet. + + RSA_OR_IDEA + The IDEA algorithms has been used in the data. A + program might want to fallback to another program to handle + the data if GnuPG failed. This status message used to be emitted + also for RSA but this has been dropped after the RSA patent expired. + However we can't change the name of the message. + + SHM_INFO + SHM_GET + SHM_GET_BOOL + SHM_GET_HIDDEN + + GET_BOOL + GET_LINE + GET_HIDDEN + GOT_IT + + NEED_PASSPHRASE <long main keyid> <long keyid> <keytype> <keylength> + Issued whenever a passphrase is needed. + keytype is the numerical value of the public key algorithm + or 0 if this is not applicable, keylength is the length + of the key or 0 if it is not known (this is currently always the case). + + NEED_PASSPHRASE_SYM <cipher_algo> <s2k_mode> <s2k_hash> + Issued whenever a passphrase for symmetric encryption is needed. + + NEED_PASSPHRASE_PIN <card_type> <chvno> [<serialno>] + Issued whenever a PIN is requested to unlock a card. + + MISSING_PASSPHRASE + No passphrase was supplied. An application which encounters this + message may want to stop parsing immediately because the next message + will probably be a BAD_PASSPHRASE. However, if the application + is a wrapper around the key edit menu functionality it might not + make sense to stop parsing but simply ignoring the following + BAD_PASSPHRASE. + + BAD_PASSPHRASE <long keyid> + The supplied passphrase was wrong or not given. In the latter case + you may have seen a MISSING_PASSPHRASE. + + GOOD_PASSPHRASE + The supplied passphrase was good and the secret key material + is therefore usable. + + DECRYPTION_FAILED + The symmetric decryption failed - one reason could be a wrong + passphrase for a symmetrical encrypted message. + + DECRYPTION_OKAY + The decryption process succeeded. This means, that either the + correct secret key has been used or the correct passphrase + for a conventional encrypted message was given. The program + itself may return an errorcode because it may not be possible to + verify a signature for some reasons. + + NO_PUBKEY <long keyid> + NO_SECKEY <long keyid> + The key is not available + + IMPORT_CHECK <long keyid> <fingerprint> <user ID> + This status is emitted in interactive mode right before + the "import.okay" prompt. + + IMPORTED <long keyid> <username> + The keyid and name of the signature just imported + + IMPORT_OK <reason> [<fingerprint>] + The key with the primary key's FINGERPRINT has been imported. + Reason flags: + 0 := Not actually changed + 1 := Entirely new key. + 2 := New user IDs + 4 := New signatures + 8 := New subkeys + 16 := Contains private key. + The flags may be ORed. + + IMPORT_PROBLEM <reason> [<fingerprint>] + Issued for each import failure. Reason codes are: + 0 := "No specific reason given". + 1 := "Invalid Certificate". + 2 := "Issuer Certificate missing". + 3 := "Certificate Chain too long". + 4 := "Error storing certificate". + + IMPORT_RES <count> <no_user_id> <imported> <imported_rsa> <unchanged> + <n_uids> <n_subk> <n_sigs> <n_revoc> <sec_read> <sec_imported> <sec_dups> <not_imported> + Final statistics on import process (this is one long line) + + FILE_START <what> <filename> + Start processing a file <filename>. <what> indicates the performed + operation: + 1 - verify + 2 - encrypt + 3 - decrypt + + FILE_DONE + Marks the end of a file processing which has been started + by FILE_START. + + BEGIN_DECRYPTION + END_DECRYPTION + Mark the start and end of the actual decryption process. These + are also emitted when in --list-only mode. + + BEGIN_ENCRYPTION <mdc_method> <sym_algo> + END_ENCRYPTION + Mark the start and end of the actual encryption process. + + BEGIN_SIGNING + Mark the start of the actual signing process. This may be used + as an indication that all requested secret keys are ready for + use. + + DELETE_PROBLEM reason_code + Deleting a key failed. Reason codes are: + 1 - No such key + 2 - Must delete secret key first + 3 - Ambigious specification + + PROGRESS what char cur total + Used by the primegen and Public key functions to indicate progress. + "char" is the character displayed with no --status-fd enabled, with + the linefeed replaced by an 'X'. "cur" is the current amount + done and "total" is amount to be done; a "total" of 0 indicates that + the total amount is not known. 100/100 may be used to detect the + end of operation. + Well known values for WHAT: + "pk_dsa" - DSA key generation + "pk_elg" - Elgamal key generation + "primegen" - Prime generation + "need_entropy" - Waiting for new entropy in the RNG + "file:XXX" - processing file XXX + (note that current gpg versions leave out the + "file:" prefix). + "tick" - generic tick without any special meaning - useful + for letting clients know that the server is + still working. + "starting_agent" - A gpg-agent was started because it is not + running as a daemon. + + + 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 + + Note, that TIMESTAMP may either be a number with seconds since + epoch or an ISO 8601 string which can be detected by the + presence of the letter 'T' inside. + + KEY_CREATED <type> <fingerprint> [<handle>] + A key has been created + type: 'B' = primary and subkey + 'P' = primary + 'S' = subkey + The fingerprint is one of the primary key for type B and P and + the one of the subkey for S. Handle is an arbitrary + non-whitespace string used to match key parameters from batch + key creation run. + + KEY_NOT_CREATED [<handle>] + The key from batch run has not been created due to errors. + + + SESSION_KEY <algo>:<hexdigits> + The session key used to decrypt the message. This message will + only be emitted when the special option --show-session-key + is used. The format is suitable to be passed to the option + --override-session-key + + NOTATION_NAME <name> + NOTATION_DATA <string> + name and string are %XX escaped; the data may be splitted + among several notation_data lines. + + USERID_HINT <long main keyid> <string> + Give a hint about the user ID for a certain keyID. + + POLICY_URL <string> + string is %XX escaped + + BEGIN_STREAM + END_STREAM + Issued by pipemode. + + INV_RECP <reason> <requested_recipient> + Issued for each unusable recipient. The reasons codes + currently in use are: + 0 := "No specific reason given". + 1 := "Not Found" + 2 := "Ambigious specification" + 3 := "Wrong key usage" + 4 := "Key revoked" + 5 := "Key expired" + 6 := "No CRL known" + 7 := "CRL too old" + 8 := "Policy mismatch" + 9 := "Not a secret key" + 10 := "Key not trusted" + + Note that this status is also used for gpgsm's SIGNER command + where it relates to signer's of course. + + NO_RECP <reserved> + Issued when no recipients are usable. + + ALREADY_SIGNED <long-keyid> + Warning: This is experimental and might be removed at any time. + + TRUNCATED <maxno> + The output was truncated to MAXNO items. This status code is issued + for certain external requests + + ERROR <error location> <error code> + + This is a generic error status message, it might be followed + by error location specific data. <error token> and + <error_location> should not contain a space. The error code + is a either a string commencing with a letter or such string + prefix with a numerical error code and an underscore; e.g.: + "151011327_EOF" + + 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 + + CARDCTRL <what> [<serialno>] + This is used to control smartcard operations. + Defined values for WHAT are: + 1 = Request insertion of a card. Serialnumber may be given + to request a specific card. + 2 = Request removal of a card. + 3 = Card with serialnumber detected + 4 = No card available. + 5 = No card reader available + + + PLAINTEXT <format> <timestamp> <filename> + This indicates the format of the plaintext that is about to be + written. The format is a 1 byte hex code that shows the + format of the plaintext: 62 ('b') is binary data, 74 ('t') is + text data with no character set specified, and 75 ('u') is + text data encoded in the UTF-8 character set. The timestamp + is in seconds since the epoch. If a filename is available it + gets printed as the third argument, percent-escaped as usual. + + PLAINTEXT_LENGTH <length> + This indicates the length of the plaintext that is about to be + written. Note that if the plaintext packet has partial length + encoding it is not possible to know the length ahead of time. + In that case, this status tag does not appear. + + SIG_SUBPACKET <type> <flags> <len> <data> + This indicates that a signature subpacket was seen. The + format is the same as the "spk" record above. + + SC_OP_FAILURE [<code>] + An operation on a smartcard definitely failed. Currently + there is no indication of the actual error code, but + application should be prepared to later accept more arguments. + Defined values for CODE are: + 0 - unspecified error (identically to a missing CODE) + 1 - canceled + 2 - bad PIN + + SC_OP_SUCCESS + A smart card operaion succeeded. This status is only printed + for certain operation and is mostly useful to check whether a + PIN change really worked. + + BACKUP_KEY_CREATED fingerprint fname + A backup key named FNAME has been created for the key with + KEYID. + + +Format of the "--attribute-fd" output +===================================== + +When --attribute-fd is set, during key listings (--list-keys, +--list-secret-keys) GnuPG dumps each attribute packet to the file +descriptor specified. --attribute-fd is intended for use with +--status-fd as part of the required information is carried on the +ATTRIBUTE status tag (see above). + +The contents of the attribute data is specified by 2440bis, but for +convenience, here is the Photo ID format, as it is currently the only +attribute defined: + + Byte 0-1: The length of the image header. Due to a historical + accident (i.e. oops!) back in the NAI PGP days, this is + a little-endian number. Currently 16 (0x10 0x00). + + Byte 2: The image header version. Currently 0x01. + + Byte 3: Encoding format. 0x01 == JPEG. + + Byte 4-15: Reserved, and currently unused. + + All other data after this header is raw image (JPEG) data. + + +Format of the "--list-config" output +==================================== + +--list-config outputs information about the GnuPG configuration for +the benefit of frontends or other programs that call GnuPG. There are +several list-config items, all colon delimited like the rest of the +--with-colons output. The first field is always "cfg" to indicate +configuration information. The second field is one of (with +examples): + +version: the third field contains the version of GnuPG. + + cfg:version:1.3.5 + +pubkey: the third field contains the public key algorithmdcaiphers + this version of GnuPG supports, separated by semicolons. The + algorithm numbers are as specified in RFC-2440. + + cfg:pubkey:1;2;3;16;17 + +cipher: the third field contains the symmetric ciphers this version of + GnuPG supports, separated by semicolons. The cipher numbers + are as specified in RFC-2440. + + cfg:cipher:2;3;4;7;8;9;10 + +digest: the third field contains the digest (hash) algorithms this + version of GnuPG supports, separated by semicolons. The + digest numbers are as specified in RFC-2440. + + cfg:digest:1;2;3;8;9;10 + +compress: the third field contains the compression algorithms this + version of GnuPG supports, separated by semicolons. The + algorithm numbers are as specified in RFC-2440. + + cfg:compress:0;1;2;3 + +group: the third field contains the name of the group, and the fourth + field contains the values that the group expands to, separated + by semicolons. + +For example, a group of: + group mynames = paige 0x12345678 joe patti + +would result in: + cfg:group:mynames:patti;joe;0x12345678;paige + + +Key generation +============== + Key generation shows progress by printing different characters to + stderr: + "." Last 10 Miller-Rabin tests failed + "+" Miller-Rabin test succeeded + "!" Reloading the pool with fresh prime numbers + "^" Checking a new value for the generator + "<" Size of one factor decreased + ">" Size of one factor increased + + The prime number for Elgamal is generated this way: + + 1) Make a prime number q of 160, 200, 240 bits (depending on the keysize) + 2) Select the length of the other prime factors to be at least the size + of q and calculate the number of prime factors needed + 3) Make a pool of prime numbers, each of the length determined in step 2 + 4) Get a new permutation out of the pool or continue with step 3 + if we have tested all permutations. + 5) Calculate a candidate prime p = 2 * q * p[1] * ... * p[n] + 1 + 6) Check that this prime has the correct length (this may change q if + it seems not to be possible to make a prime of the desired length) + 7) Check whether this is a prime using trial divisions and the + Miller-Rabin test. + 8) Continue with step 4 if we did not find a prime in step 7. + 9) Find a generator for that prime. + + This algorithm is based on Lim and Lee's suggestion from the + Crypto '97 proceedings p. 260. + + +Unattended key generation +========================= +This feature allows unattended generation of keys controlled by a +parameter file. To use this feature, you use --gen-key together with +--batch and feed the parameters either from stdin or from a file given +on the commandline. + +The format of this file is as follows: + o Text only, line length is limited to about 1000 chars. + o You must use UTF-8 encoding to specify non-ascii characters. + o Empty lines are ignored. + o Leading and trailing spaces are ignored. + o A hash sign as the first non white space character indicates a comment line. + o Control statements are indicated by a leading percent sign, the + arguments are separated by white space from the keyword. + o Parameters are specified by a keyword, followed by a colon. Arguments + are separated by white space. + o The first parameter must be "Key-Type", control statements + may be placed anywhere. + o Key generation takes place when either the end of the parameter file + is reached, the next "Key-Type" parameter is encountered or at the + control statement "%commit" + o Control statements: + %echo <text> + Print <text>. + %dry-run + Suppress actual key generation (useful for syntax checking). + %commit + Perform the key generation. An implicit commit is done + at the next "Key-Type" parameter. + %pubring <filename> + %secring <filename> + Do not write the key to the default or commandline given + keyring but to <filename>. This must be given before the first + commit to take place, duplicate specification of the same filename + is ignored, the last filename before a commit is used. + The filename is used until a new filename is used (at commit points) + and all keys are written to that file. If a new filename is given, + this file is created (and overwrites an existing one). + Both control statements must be given. + o The order of the parameters does not matter except for "Key-Type" + which must be the first parameter. The parameters are only for the + generated keyblock and parameters from previous key generations are not + used. Some syntactically checks may be performed. + The currently defined parameters are: + Key-Type: <algo-number>|<algo-string> + Starts a new parameter block by giving the type of the + primary key. The algorithm must be capable of signing. + This is a required parameter. + Key-Length: <length-in-bits> + Length of the key in bits. Default is 1024. + Key-Usage: <usage-list> + Space or comma delimited list of key usage, allowed values are + "encrypt", "sign", and "auth". This is used to generate the + key flags. Please make sure that the algorithm is capable of + this usage. Note that OpenPGP requires that all primary keys + are capable of certification, so no matter what usage is given + here, the "cert" flag will be on. If no Key-Usage is + specified, all the allowed usages for that particular + algorithm are used. + 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. + Handle: <string> + This is an optional parameter only used with the status lines + KEY_CREATED and KEY_NOT_CREATED. STRING may be up to 100 + characters and should not contain spaces. It is useful for + batch key generation to associate a key parameter block with a + status line. + Keyserver: <string> + This is an optional parameter that specifies the preferred + keyserver URL for the key. + + +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: [email protected] + Expire-Date: 0 + Passphrase: abc + %pubring foo.pub + %secring foo.sec + # Do a commit here, so that we can later print "done" :-) + %commit + %echo done +EOF +$ gpg --batch --gen-key foo + [...] +$ gpg --no-default-keyring --secret-keyring ./foo.sec \ + --keyring ./foo.pub --list-secret-keys +/home/wk/work/gnupg-stable/scratch/foo.sec +------------------------------------------ +sec 1024D/915A878D 2000-03-09 Joe Tester (with stupid passphrase) <[email protected]> +ssb 1024g/8F70E2C0 2000-03-09 + + + +Layout of the TrustDB +===================== +The TrustDB is built from fixed length records, where the first byte +describes the record type. All numeric values are stored in network +byte order. The length of each record is 40 bytes. The first record of +the DB is always of type 1 and this is the only record of this type. + +FIXME: The layout changed, document it here. + + Record type 0: + -------------- + Unused record, can be reused for any purpose. + + Record type 1: + -------------- + Version information for this TrustDB. This is always the first + record of the DB and the only one with type 1. + 1 byte value 1 + 3 bytes 'gpg' magic value + 1 byte Version of the TrustDB (2) + 1 byte marginals needed + 1 byte completes needed + 1 byte max_cert_depth + The three items are used to check whether the cached + validity value from the dir record can be used. + 1 u32 locked flags [not used] + 1 u32 timestamp of trustdb creation + 1 u32 timestamp of last modification which may affect the validity + of keys in the trustdb. This value is checked against the + validity timestamp in the dir records. + 1 u32 timestamp of last validation [currently not used] + (Used to keep track of the time, when this TrustDB was checked + against the pubring) + 1 u32 record number of keyhashtable [currently not used] + 1 u32 first free record + 1 u32 record number of shadow directory hash table [currently not used] + It does not make sense to combine this table with the key table + because the keyid is not in every case a part of the fingerprint. + 1 u32 record number of the trusthashtbale + + + Record type 2: (directory record) + -------------- + Informations about a public key certificate. + These are static values which are never changed without user interaction. + + 1 byte value 2 + 1 byte reserved + 1 u32 LID . (This is simply the record number of this record.) + 1 u32 List of key-records (the first one is the primary key) + 1 u32 List of uid-records + 1 u32 cache record + 1 byte ownertrust + 1 byte dirflag + 1 byte maximum validity of all the user ids + 1 u32 time of last validity check. + 1 u32 Must check when this time has been reached. + (0 = no check required) + + + Record type 3: (key record) + -------------- + Informations about a primary public key. + (This is mainly used to lookup a trust record) + + 1 byte value 3 + 1 byte reserved + 1 u32 LID + 1 u32 next - next key record + 7 bytes reserved + 1 byte keyflags + 1 byte pubkey algorithm + 1 byte length of the fingerprint (in bytes) + 20 bytes fingerprint of the public key + (This is the value we use to identify a key) + + Record type 4: (uid record) + -------------- + Informations about a userid + We do not store the userid but the hash value of the userid because that + is sufficient. + + 1 byte value 4 + 1 byte reserved + 1 u32 LID points to the directory record. + 1 u32 next next userid + 1 u32 pointer to preference record + 1 u32 siglist list of valid signatures + 1 byte uidflags + 1 byte validity of the key calculated over this user id + 20 bytes ripemd160 hash of the username. + + + Record type 5: (pref record) + -------------- + This record type is not anymore used. + + 1 byte value 5 + 1 byte reserved + 1 u32 LID; points to the directory record (and not to the uid record!). + (or 0 for standard preference record) + 1 u32 next + 30 byte preference data + + Record type 6 (sigrec) + ------------- + Used to keep track of key signatures. Self-signatures are not + stored. If a public key is not in the DB, the signature points to + a shadow dir record, which in turn has a list of records which + might be interested in this key (and the signature record here + is one). + + 1 byte value 6 + 1 byte reserved + 1 u32 LID points back to the dir record + 1 u32 next next sigrec of this uid or 0 to indicate the + last sigrec. + 6 times + 1 u32 Local_id of signatures dir or shadow dir record + 1 byte Flag: Bit 0 = checked: Bit 1 is valid (we have a real + directory record for this) + 1 = valid is set (but may be revoked) + + + + Record type 8: (shadow directory record) + -------------- + This record is used to reserve a LID for a public key. We + need this to create the sig records of other keys, even if we + do not yet have the public key of the signature. + This record (the record number to be more precise) will be reused + as the dir record when we import the real public key. + + 1 byte value 8 + 1 byte reserved + 1 u32 LID (This is simply the record number of this record.) + 2 u32 keyid + 1 byte pubkey algorithm + 3 byte reserved + 1 u32 hintlist A list of records which have references to + this key. This is used for fast access to + signature records which are not yet checked. + Note, that this is only a hint and the actual records + may not anymore hold signature records for that key + but that the code cares about this. + 18 byte reserved + + + + Record Type 10 (hash table) + -------------- + Due to the fact that we use fingerprints to lookup keys, we can + implement quick access by some simple hash methods, and avoid + the overhead of gdbm. A property of fingerprints is that they can be + used directly as hash values. (They can be considered as strong + random numbers.) + What we use is a dynamic multilevel architecture, which combines + hashtables, record lists, and linked lists. + + This record is a hashtable of 256 entries; a special property + is that all these records are stored consecutively to make one + big table. The hash value is simple the 1st, 2nd, ... byte of + the fingerprint (depending on the indirection level). + + When used to hash shadow directory records, a different table is used + and indexed by the keyid. + + 1 byte value 10 + 1 byte reserved + n u32 recnum; n depends on the record length: + n = (reclen-2)/4 which yields 9 for the current record length + of 40 bytes. + + the total number of such record which makes up the table is: + m = (256+n-1) / n + which is 29 for a record length of 40. + + To look up a key we use the first byte of the fingerprint to get + the recnum from this hashtable and look up the addressed record: + - If this record is another hashtable, we use 2nd byte + to index this hash table and so on. + - if this record is a hashlist, we walk all entries + until we found one a matching one. + - if this record is a key record, we compare the + fingerprint and to decide whether it is the requested key; + + + Record type 11 (hash list) + -------------- + see hash table for an explanation. + This is also used for other purposes. + + 1 byte value 11 + 1 byte reserved + 1 u32 next next hash list record + n times n = (reclen-5)/5 + 1 u32 recnum + + For the current record length of 40, n is 7 + + + + Record type 254 (free record) + --------------- + All these records form a linked list of unused records. + 1 byte value 254 + 1 byte reserved (0) + 1 u32 next_free + + + +Packet Headers +=============== + +GNUPG uses PGP 2 packet headers and also understands OpenPGP packet header. +There is one enhancement used with the old style packet headers: + + CTB bits 10, the "packet-length length bits", have values listed in + the following table: + + 00 - 1-byte packet-length field + 01 - 2-byte packet-length field + 10 - 4-byte packet-length field + 11 - no packet length supplied, unknown packet length + + As indicated in this table, depending on the packet-length length + bits, the remaining 1, 2, 4, or 0 bytes of the packet structure field + are a "packet-length field". The packet-length field is a whole + number field. The value of the packet-length field is defined to be + the value of the whole number field. + + A value of 11 is currently used in one place: on compressed data. + That is, a compressed data block currently looks like <A3 01 . . .>, + where <A3>, binary 10 1000 11, is an indefinite-length packet. The + proper interpretation is "until the end of the enclosing structure", + although it should never appear outermost (where the enclosing + structure is a file). + ++ This will be changed with another version, where the new meaning of ++ the value 11 (see below) will also take place. ++ ++ A value of 11 for other packets enables a special length encoding, ++ which is used in case, where the length of the following packet can ++ not be determined prior to writing the packet; especially this will ++ be used if large amounts of data are processed in filter mode. ++ ++ It works like this: After the CTB (with a length field of 11) a ++ marker field is used, which gives the length of the following datablock. ++ This is a simple 2 byte field (MSB first) containing the amount of data ++ following this field, not including this length field. After this datablock ++ another length field follows, which gives the size of the next datablock. ++ A value of 0 indicates the end of the packet. The maximum size of a ++ data block is limited to 65534, thereby reserving a value of 0xffff for ++ future extensions. These length markers must be inserted into the data ++ stream just before writing the data out. ++ ++ This 2 byte field is large enough, because the application must buffer ++ this amount of data to prepend the length marker before writing it out. ++ Data block sizes larger than about 32k doesn't make any sense. Note ++ that this may also be used for compressed data streams, but we must use ++ another packet version to tell the application that it can not assume, ++ that this is the last packet. + + +GNU extensions to the S2K algorithm +=================================== +S2K mode 101 is used to identify these extensions. +After the hash algorithm the 3 bytes "GNU" are used to make +clear that these are extensions for GNU, the next bytes gives the +GNU protection mode - 1000. Defined modes are: + 1001 - do not store the secret part at all + 1002 - a stub to access smartcards (not used in 1.2.x) + + +Pipemode +======== +NOTE: This is deprecated and will be removed in future versions. + +This mode can be used to perform multiple operations with one call to +gpg. It comes handy in cases where you have to verify a lot of +signatures. Currently we support only detached signatures. This mode +is a kludge to avoid running gpg n daemon mode and using Unix Domain +Sockets to pass the data to it. There is no easy portable way to do +this under Windows, so we use plain old pipes which do work well under +Windows. Because there is no way to signal multiple EOFs in a pipe we +have to embed control commands in the data stream: We distinguish +between a data state and a control state. Initially the system is in +data state but it won't accept any data. Instead it waits for +transition to control state which is done by sending a single '@' +character. While in control state the control command os expected and +this command is just a single byte after which the system falls back +to data state (but does not necesary accept data now). The simplest +control command is a '@' which just inserts this character into the +data stream. + +Here is the format we use for detached signatures: +"@<" - Begin of new stream +"@B" - Detached signature follows. + This emits a control packet (1,'B') +<detached_signature> +"@t" - Signed text follows. + This emits the control packet (2, 'B') +<signed_text> +"@." - End of operation. The final control packet forces signature + verification +"@>" - End of stream + + + + + + +Other Notes +=========== + * For packet version 3 we calculate the keyids this way: + RSA := low 64 bits of n + ELGAMAL := build a v3 pubkey packet (with CTB 0x99) and calculate + a rmd160 hash value from it. This is used as the + fingerprint and the low 64 bits are the keyid. + + * Revocation certificates consist only of the signature packet; + "import" knows how to handle this. The rationale behind it is + to keep them small. + + + + + + + +Keyserver Message Format +========================= + +The keyserver may be contacted by a Unix Domain socket or via TCP. + +The format of a request is: + +==== +command-tag +"Content-length:" digits +CRLF +======= + +Where command-tag is + +NOOP +GET <user-name> +PUT +DELETE <user-name> + + +The format of a response is: + +====== +"GNUPG/1.0" status-code status-text +"Content-length:" digits +CRLF +============ +followed by <digits> bytes of data + + +Status codes are: + + o 1xx: Informational - Request received, continuing process + + o 2xx: Success - The action was successfully received, understood, + and accepted + + o 4xx: Client Error - The request contains bad syntax or cannot be + fulfilled + + o 5xx: Server Error - The server failed to fulfill an apparently + valid request + + + +Documentation on HKP (the http keyserver protocol): + +A minimalistic HTTP server on port 11371 recognizes a GET for /pks/lookup. +The standard http URL encoded query parameters are this (always key=value): + +- op=index (like pgp -kv), op=vindex (like pgp -kvv) and op=get (like + pgp -kxa) + +- search=<stringlist>. This is a list of words that must occur in the key. + The words are delimited with space, points, @ and so on. The delimiters + are not searched for and the order of the words doesn't matter (but see + next option). + +- exact=on. This switch tells the hkp server to only report exact matching + keys back. In this case the order and the "delimiters" are important. + +- fingerprint=on. Also reports the fingerprints when used with 'index' or + 'vindex' + +The keyserver also recognizes http-POSTs to /pks/add. Use this to upload +keys. + + +A better way to do this would be a request like: + + /pks/lookup/<gnupg_formatierte_user_id>?op=<operation> + +This can be implemented using Hurd's translator mechanism. +However, I think the whole key server stuff has to be re-thought; +I have some ideas and probably create a white paper. + diff --git a/doc/HACKING b/doc/HACKING new file mode 100644 index 000000000..eee9f628b --- /dev/null +++ b/doc/HACKING @@ -0,0 +1,305 @@ + A Hacker's Guide to GNUPG + ================================ + (Some notes on GNUPG internals.) + + + ===> Under construction <======= + + +CVS Access +========== + +NOTE: CVS access has been disabled while we are migrating to Subversion. +Watch www.gnupg.org for instarctions on how to use the Subversion repository. + +Anonymous read-only CVS access is available: + + cvs -z3 -d :pserver:[email protected]:/cvs/gnupg login + +use the password "anoncvs". To check out the the complete +archive use: + + cvs -z3 -d :pserver:[email protected]:/cvs/gnupg \ + checkout -R STABLE-BRANCH-1-0 gnupg + +This service is provided to help you in hunting bugs and not to deliver +stable snapshots; it may happen that it even does not compile, so please +don't complain. CVS may put a high load on a server, so please don't poll +poll for new updates but wait for an announcement; to receive this you may +want to subscribe to: + + +by sending a mail with subject "subscribe" to + + + +You must run scripts/autogen.sh before doing the ./configure, +as this creates some needed while which are not in the CVS. +autogen.sh should checks that you have all required tools +installed. + + +RSYNC access +============ +The FTP archive is also available by anonymous rsync. A daily snapshot +of the CVS head revision is also available. See rsync(1) and try +"rsync ftp.gnupg.org::" to see available resources. + + + +Special Tools +============= +Documentation is based on the docbook DTD. Actually we have only the +man page for now. To build a man page you need the docbook-to-man +tool and all the other thinks needed for SGML processing. Debian +comes with the docbook tools and you only need this docbook-to-man +script which is comes with gtk-doc or download it from +ftp.openit.de:/pub/devel/sgml. If you don't have it everything +should still work fine but you will have only a dummy man page. + + +RFCs +==== + +1423 Privacy Enhancement for Internet Electronic Mail: + Part III: Algorithms, Modes, and Identifiers. + +1489 Registration of a Cyrillic Character Set. + +1750 Randomness Recommendations for Security. + +1991 PGP Message Exchange Formats. + +2015 MIME Security with Pretty Good Privacy (PGP). + +2144 The CAST-128 Encryption Algorithm. + +2279 UTF-8, a transformation format of ISO 10646. + +2440 OpenPGP. + + + +Debug Flags +----------- +Use the option "--debug n" to output debug information. This option +can be used multiple times, all values are ORed; n maybe prefixed with +0x to use hex-values. + + value used for + ----- ---------------------------------------------- + 1 packet reading/writing + 2 MPI details + 4 ciphers and primes (may reveal sensitive data) + 8 iobuf filter functions + 16 iobuf stuff + 32 memory allocation stuff + 64 caching + 128 show memory statistics at exit + 256 trust verification stuff + + + + +Directory Layout +---------------- + ./ Readme, configure + ./scripts Scripts needed by configure and others + ./doc Documentation + ./util General purpose utility function + ./mpi Multi precision integer library + ./cipher Cryptographic functions + ./g10 GnuPG application + ./tools Some helper and demo programs + ./keybox The keybox library (under construction) + ./gcrypt Stuff needed to build libgcrypt (under construction) + + +Detailed Roadmap +---------------- +g10/g10.c Main module with option parsing and all the stuff you have + to do on startup. Also has the exout handler and some + helper functions. +g10/sign.c Create signature and optionally encrypt + +g10/parse-packet.c +g10/build-packet.c +g10/free-packet.c + Parsing and creating of OpenPGP message packets. + +g10/getkey.c Key selection code +g10/pkclist.c Build a list of public keys +g10/skclist.c Build a list of secret keys +g10/ringedit.c Keyring I/O +g10/keydb.h + +g10/keyid.c Helper functions to get the keyid, fingerprint etc. + + +g10/trustdb.c +g10/trustdb.h +g10/tdbdump.c + Management of the trustdb.gpg + +g10/compress.c Filter to handle compression +g10/filter.h Declarations for all filter functions +g10/delkey.c Delete a key +g10/kbnode.c Helper for the KBNODE linked list +g10/main.h Prototypes and some constants +g10/mainproc.c Message processing +g10/armor.c Ascii armor filter +g10/mdfilter.c Filter to calculate hashs +g10/textfilter.c Filter to handle CR/LF and trailing white space +g10/cipher.c En-/Decryption filter +g10/misc.c Utlity functions +g10/options.h Structure with all the command line options + and related constants +g10/openfile.c Create/Open Files +g10/tdbio.c I/O handling for the trustdb.gpg +g10/tdbio.h +g10/hkp.h Keyserver access +g10/hkp.c +g10/packet.h Defintion of OpenPGP structures. +g10/passphrase.c Passphrase handling code +g10/pubkey-enc.c +g10/seckey-cert.c +g10/seskey.c +g10/import.c +g10/export.c +g10/comment.c +g10/status.c +g10/status.h +g10/sign.c +g10/plaintext.c +g10/encr-data.c +g10/encode.c +g10/revoke.c +g10/keylist.c +g10/sig-check.c +g10/signal.c +g10/helptext.c +g10/verify.c +g10/decrypt.c +g10/keyedit.c +g10/dearmor.c +g10/keygen.c + + + +Memory allocation +----------------- +Use only the functions: + + m_alloc() + m_alloc_clear() + m_strdup() + m_free() + +If you want to store a passphrase or some other sensitive data you may +want to use m_alloc_secure() instead of m_alloc(), as this puts the data +into a memory region which is protected from swapping (on some platforms). +m_free() works for both. This functions will not return if there is not +enough memory available. + + + +Logging +------- + + + + + + +Option parsing +--------------- +GNUPG does not use getopt or GNU getopt but functions of it's own. See +util/argparse.c for details. The advantage of these functions is that +it is more easy to display and maintain the help texts for the options. +The same option table is also used to parse resource files. + + + +What is an IOBUF +---------------- +This is the data structure used for most I/O of gnupg. It is similar +to System V Streams but much simpler. Because OpenPGP messages are nested +in different ways; the use of such a system has big advantages. Here is +an example, how it works: If the parser sees a packet header with a partial +length, it pushes the block_filter onto the IOBUF to handle these partial +length packets: from now on you don't have to worry about this. When it sees +a compressed packet it pushes the uncompress filter and the next read byte +is one which has already been uncompressed by this filter. Same goes for +enciphered packet, plaintext packets and so on. The file g10/encode.c +might be a good staring point to see how it is used - actually this is +the other way: constructing messages using pushed filters but it may be +easier to understand. + + +How to use the message digest functions +--------------------------------------- +cipher/md.c implements an interface to hash (message digest functions). + +a) If you have a common part of data and some variable parts + and you need to hash of the concatenated parts, you can use this: + md = md_open(...) + md_write( md, common_part ) + md1 = md_copy( md ) + md_write(md1, part1) + md_final(md1); + digest1 = md_read(md1) + md2 = md_copy( md ) + md_write(md2, part2) + md_final(md2); + digest2 = md_read(md2) + + An example are key signatures; the key packet is the common part + and the user-id packets are the variable parts. + +b) If you need a running digest you should use this: + md = md_open(...) + md_write( md, part1 ) + digest_of_part1 = md_digest( md ); + md_write( md, part2 ) + digest_of_part1_cat_part2 = md_digest( md ); + .... + +Both methods may be combined. [Please see the source for the real syntax] + + + + +How to use the cipher functions +------------------------------- +cipher/cipher.c implements the interface to symmetric encryption functions. +As usual you have a function to open a cipher (which returns a handle to be used +with all other functions), some functions to set the key and other stuff and +a encrypt and decrypt function which does the real work. You probably know +how to work with files - so it should really be easy to work with these +functions. Here is an example: + + CIPHER_HANDLE hd; + + hd = cipher_open( CIPHER_ALGO_TWOFISH, CIPHER_MODE_CFB, 0 ); + if( !hd ) + oops( use other function to check for the real error ); + rc = cipher_setkey( hd, key256bit, 32 ) ) + if( rc ) + oops( weak key or something like this ); + cipher_setiv( hd, some_IV_or_NULL_for_all_zeroes ); + cipher_encrypt( hd, plain, cipher, size ); + cipher_close( hd ); + + + +How to use the public key functions +----------------------------------- +cipher/pubkey.c implements the interface to asymmetric encryption and +signature functions. This is basically the same as with the symmetric +counterparts, but due to their nature it is a little bit more complicated. + + [Give an example] + + diff --git a/doc/KEYSERVER b/doc/KEYSERVER new file mode 100644 index 000000000..f63200a6b --- /dev/null +++ b/doc/KEYSERVER @@ -0,0 +1,83 @@ +Format of keyserver colon listings +================================== + +David Shaw <[email protected]> + +The machine readable response begins with an optional information +line: + +info:<version>:<count> + +<version> = this is the version of this protocol. Currently, this is + the number 1. + +<count> = the number of keys returned in this response. Note this is + the number of keys, and not the number of lines returned. + It should match the number of "pub:" lines returned. + +If this optional line is not included, or the version information is +not supplied, the version number is assumed to be 1. + +The key listings are made up of several lines per key. The first line +is for the primary key: + +pub:<fingerprint>:<algo>:<keylen>:<creationdate>:<expirationdate>:<flags> + +<fingerprint> = this is either the fingerprint or the keyid of the + key. Either the 16-digit or 8-digit keyids are + acceptable, but obviously the fingerprint is best. + Since it is not possible to calculate the keyid from a + V3 key fingerprint, for V3 keys this should be either + the 16-digit or 8-digit keyid only. + +<algo> = the algorithm number from RFC-2440. (i.e. 1==RSA, 17==DSA, + etc). + +<keylen> = the key length (i.e. 1024, 2048, 4096, etc.) + +<creationdate> = creation date of the key in standard RFC-2440 form + (i.e. number of seconds since 1/1/1970 UTC time) + +<expirationdate> = expiration date of the key in standard RFC-2440 + form (i.e. number of seconds since 1/1/1970 UTC time) + +<flags> = letter codes to indicate details of the key, if any. Flags + may be in any order. + + r == revoked + d == disabled + e == expired + +Following the "pub" line are one or more "uid" lines to indicate user +IDs on the key: + +uid:<escaped uid string>:<creationdate>:<expirationdate>:<flags> + +<escaped uid string> == the user ID string, with HTTP %-escaping for + anything that isn't 7-bit safe as well as for + the ":" character. Any other characters may + be escaped, as desired. + +creationdate, expirationdate, and flags mean the same here as before. +The information is taken from the self-sig, if any, and applies to the +user ID in question, and not to the key as a whole. + +Details: + +* All characters except for the <escaped uid string> are + case-insensitive. + +* Obviously, on a keyserver without integrated crypto, many of the + items given here are not fully trustworthy until the key is + downloaded and signatures checked. For example, the information + that a key is flagged "r" for revoked should be treated as + untrustworthy information until the key is checked on the client + side. + +* Empty fields are allowed. For example, a key with no expiration + date would have the <expirationdate> field empty. Also, a keyserver + that does not track a particular piece of information may leave that + field empty as well. I expect that the creation and expiration + dates for user IDs will be left empty in current keyservers. Colons + for empty fields on the end of each line may be left off, if + desired. diff --git a/doc/Makefile.am b/doc/Makefile.am index 8c1cdd767..73350fdc6 100644 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@ -19,20 +19,22 @@ ## Process this file with automake to produce Makefile.in -EXTRA_DIST = gnupg-badge-openpgp.eps gnupg-badge-openpgp.jpg \ +EXTRA_DIST = DETAILS HACKING TRANSLATE OpenPGP KEYSERVER samplekeys.asc \ + gnupg-badge-openpgp.eps gnupg-badge-openpgp.jpg \ gnupg-badge-openpgp.pdf \ gnupg-card-architecture.eps gnupg-card-architecture.png \ gnupg-card-architecture.pdf \ - opt-homedir.texi see-also-note.texi + faq.raw FAQ faq.html \ + opt-homedir.texi see-also-note.texi BUILT_SOURCES = gnupg-card-architecture.eps gnupg-card-architecture.png \ - gnupg-card-architecture.pdf + gnupg-card-architecture.pdf FAQ faq.html noinst_PROGRAMS = yat2m info_TEXINFOS = gnupg.texi -dist_pkgdata_DATA = qualified.txt +dist_pkgdata_DATA = qualified.txt FAQ faq.html gnupg_TEXINFOS = \ gpg.texi gpgsm.texi gpg-agent.texi scdaemon.texi assuan.texi \ @@ -55,6 +57,9 @@ man_MANS = $(myman_pages) watchgnupg_SOURCE = gnupg.texi + +CLEANFILES = faq.raw.xref + DISTCLEANFILES = gnupg.tmp gnupg.ops yat2m-stamp.tmp yat2m-stamp \ $(myman_pages) @@ -74,6 +79,25 @@ yat2m_SOURCES = yat2m.c fig2dev -L pdf `test -f '$<' || echo '$(srcdir)/'`$< $@ +FAQ : faq.raw +if WORKING_FAQPROG + $(FAQPROG) -f $< $@ || $(FAQPROG) -f $< $@ +else + : Warning: missing faqprog.pl, cannot make $@ + echo "No $@ due to missing faqprog.pl" > $@ + echo "See ftp://ftp.gnupg.org/gcrypt/contrib/faqprog.pl" >> $@ +endif + +faq.html : faq.raw +if WORKING_FAQPROG + $(FAQPROG) -h -f $< $@ 2>&1 || $(FAQPROG) -h -f $< $@ +else + : Warning: missing faqprog.pl, cannot make $@ + echo "No $@ due to missing faqprog.pl" > $@ + echo "See ftp://ftp.gnupg.org/gcrypt/contrib/faqprog.pl" >> $@ +endif + + yat2m-stamp: $(myman_sources) @rm -f yat2m-stamp.tmp @touch yat2m-stamp.tmp diff --git a/doc/OpenPGP b/doc/OpenPGP new file mode 100644 index 000000000..a511ad7fd --- /dev/null +++ b/doc/OpenPGP @@ -0,0 +1,108 @@ + GnuPG and OpenPGP + ================= + + See RFC2440 for a description of OpenPGP. We have an annotated version + of this RFC online: http://www.gnupg.org/rfc2440.html + + + + Compatibility Notes + =================== + GnuPG (>=1.0.3) is in compliance with RFC2440 despite these exceptions: + + * (9.2) states that IDEA SHOULD be implemented. This is not done + due to patent problems. + + + All MAY features are implemented with this exception: + + * multi-part armored messages are not supported. + MIME (rfc2015) should be used instead. + + Most of the OPTIONAL stuff is implemented. + + There are a couple of options which can be used to override some + RFC requirements. This is always mentioned with the description + of that options. + + A special format of partial packet length exists for v3 packets + which can be considered to be in compliance with RFC1991; this + format is only created if a special option is active. + + GnuPG uses a S2K mode of 101 for GNU extensions to the secret key + protection algorithms. This number is not defined in OpenPGP, but + given the fact that this number is in a range which used at many + other places in OpenPGP for private/experimenat algorithm identifiers, + this should be not a so bad choice. The 3 bytes "GNU" are used + to identify this as a GNU extension - see the file DETAILS for a + definition of the used data formats. + + + + Some Notes on OpenPGP / PGP Compatibility: + ========================================== + + * PGP 5.x does not accept V4 signatures for anything other than + key material. The GnuPG option --force-v3-sigs mimics this + behavior. + + * PGP 5.x does not recognize the "five-octet" lengths in + new-format headers or in signature subpacket lengths. + + * PGP 5.0 rejects an encrypted session key if the keylength + differs from the S2K symmetric algorithm. This is a bug in its + validation function. + + * PGP 5.0 does not handle multiple one-pass signature headers and + trailers. Signing one will compress the one-pass signed literal + and prefix a V3 signature instead of doing a nested one-pass + signature. + + * When exporting a private key, PGP 2.x generates the header + "BEGIN PGP SECRET KEY BLOCK" instead of "BEGIN PGP PRIVATE KEY + BLOCK". All previous versions ignore the implied data type, and + look directly at the packet data type. + + * In a clear-signed signature, PGP 5.0 will figure out the correct + hash algorithm if there is no "Hash:" header, but it will reject + a mismatch between the header and the actual algorithm used. The + "standard" (i.e. Zimmermann/Finney/et al.) version of PGP 2.x + rejects the "Hash:" header and assumes MD5. There are a number + of enhanced variants of PGP 2.6.x that have been modified for + SHA-1 signatures. + + * PGP 5.0 can read an RSA key in V4 format, but can only recognize + it with a V3 keyid, and can properly use only a V3 format RSA + key. + + * Neither PGP 5.x nor PGP 6.0 recognize ElGamal Encrypt and Sign + keys. They only handle ElGamal Encrypt-only keys. + + + Parts of this document are taken from: + ====================================== + + OpenPGP Message Format + draft-ietf-openpgp-formats-07.txt + + + Copyright 1998 by The Internet Society. All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph + are included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + diff --git a/doc/TRANSLATE b/doc/TRANSLATE new file mode 100644 index 000000000..1a2f266c9 --- /dev/null +++ b/doc/TRANSLATE @@ -0,0 +1,33 @@ +$Id$ + +Note for translators +-------------------- + +Some strings in GnuPG are for matching user input against. These +strings can accept multiple values that mean essentially the same +thing. + +For example, the string "yes" in English is "sÃ" in Spanish. However, +some users will type "si" (without the accent). To accomodate both +users, you can translate the string "yes" as "sÃ|si". You can have +any number of alternate matches seperated by the | character like +"sÃ|si|seguro". + +The strings that can be handled in this way are of the form "yes|yes", +(or "no|no", etc.) There should also be a comment in the .po file +directing you to this file. + + + +Sending new or updated translations +----------------------------------- + +Please note that we do not use the TP Robot but require that +translations are to be send by mail to [email protected]. We +also strongly advise to get subscribed to [email protected] and request +assistance if it is not clear on how to translate certain strings. A +wrongly translated string may lead to a security problem. + +A copyright disclaimer to the FSF is required by all translators. + + diff --git a/doc/faq.raw b/doc/faq.raw new file mode 100644 index 000000000..cbab76b0c --- /dev/null +++ b/doc/faq.raw @@ -0,0 +1,1344 @@ +[$htmltitle=GnuPG FAQ] +[$htmlcharset=<meta http-equiv="content-type" content="text/html; charset=utf-8">] +[$sfaqheader=The GnuPG FAQ says:] +[$sfaqfooter= +The most recent version of the FAQ is available from +<http://www.gnupg.org/> +] +[$usenetheader= +] +[$maintainer=David D. Scribner, <faq 'at' gnupg.org>] +[$hGPGHTTP=http://www.gnupg.org] +[$hGPGFTP=ftp://ftp.gnupg.org] +[$hVERSION=1.2.2] + +[H body bgcolor=#ffffff text=#000000 link=#1f00ff alink=#ff0000 vlink=#9900dd] +[H h1]GnuPG Frequently Asked Questions[H /h1] + + +[H p] +Version: 1.6.3[H br] +Last-Modified: Jul 30, 2003[H br] +Maintained-by: [$maintainer] +[H /p] + + +This is the GnuPG FAQ. The latest HTML version is available +[H a href=[$hGPGHTTP]/documentation/faqs.html]here[H/a]. + +The index is generated automatically, so there may be errors. 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 +as well. 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=[$hGPGHTTP]]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.rfc-editor.org/]RFC 2440[H/a]. + As such, it is aimed to be compatible with PGP from PGP Corp. and + other OpenPGP tools + +<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 question <Rcompat> for details. + +<Q> Is GnuPG free to use for personal or commercial use? + + Yes. GnuPG is part of the GNU family of tools and applications built + and provided in accordance with the Free Software Foundation (FSF) + General Public License (GPL). Therefore the software is free to copy, + use, modify and distribute in accordance with that license. Please + read the file titled COPYING that accompanies the application for + more information. + +<Q> What conventions are used in this FAQ? + + Although GnuPG is being developed for several operating systems + (often in parallel), the conventions used in this FAQ reflect a + UNIX shell environment. For Win32 users, references to a shell + prompt (`$') should be interpreted as a command prompt (`>'), + directory names separated by a forward slash (`/') may need to be + converted to a back slash (`\'), and a tilde (`~') represents a + user's "home" directory (reference question <Rhomedir> for an example). + + Some command-lines presented in this FAQ are too long to properly + display in some browsers for the web page version of this file, and + have been split into two or more lines. For these commands please + remember to enter the entire command-string on one line or the + command will error, or at minimum not give the desired results. + + Please keep in mind that this FAQ contains information that may not + apply to your particular version, as new features and bug fixes are + added on a continuing basis (reference the NEWS file included with + the source or package for noteworthy changes between versions). One + item to note is that starting with GnuPG version 1.1.92 the file + containing user options and settings has been renamed from "options" + to "gpg.conf". Information in the FAQ that relates to the options + file may be interchangable with the newer gpg.conf file in many + instances. See question <Roptions> for details. + + +<S> SOURCES of INFORMATION + +<Q> Where can I find more information on GnuPG? + + On-line resources: + + [H ul] + [H li]The documentation page is located at [H a href=[$hGPGHTTP]/documentation/]<[$hGPGHTTP]/documentation/>[H/a]. + Also, 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]At [H a href=[$hGPGHTTP]/documentation/mailing-lists.html]<[$hGPGHTTP]/documentation/mailing-lists.html>[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.: [H br] + 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][H br] + 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 br] + + [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 samp] + ./doc + [H /samp] + + 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=[$hGPGFTP]/gcrypt/]<[$hGPGFTP]/gcrypt/>[H /a] or from one of the mirrors: + + [H a href=[$hGPGHTTP]/download/mirrors.html] + <[$hGPGHTTP]/download/mirrors.html> + [H /a] + + The current stable version is [$hVERSION]. Please upgrade to this version as + it includes additional features, functions and security fixes that may + not have existed in prior versions. + + +<S> INSTALLATION + +<Q> Which OSes does GnuPG run on? + + It should run on most Unices as well as Windows versions (including + Windows NT/2000) and Macintosh OS/X. A list of OSes reported to be OK + is presented at: + + [H a href=[$hGPGHTTP]/download/supported_systems.html] + <[$hGPGHTTP]/download/supported_systems.html> + [H /a] + +<Q> Which random data 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 samp] + --enable-static-rnd=linux + [H /samp] + + In addition, there's also the kernel random device by Andi Maier + [H a href= http://www.cosy.sbg.ac.at/~andi/SUNrand/]<http://www.cosy.sbg.ac.at/~andi/SUNrand/>[H /a], but it's still beta. Use at your + 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=[$hGPGHTTP]/download/]<[$hGPGHTTP]/download/>[H /a] + to obtain EGD. Use: + + [H samp] + --enable-static-rnd=egd + [H /samp] + + 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 version 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 + versions of GnuPG. It's available from + [H a href=ftp://ftp.gnupg.dk/pub/contrib-dk/]<ftp://ftp.gnupg.dk/pub/contrib-dk/>[H /a]. Look for: + + [H pre] + idea.c.gz (c module) + idea.c.gz.sig (signature file) + [H /pre] + + [H pre] + ideadll.zip (c module and win32 dll) + ideadll.zip.sig (signature file) + [H /pre] + + Compilation directives are in the headers of these files. You will + then need to add the following line to your ~/.gnupg/gpg.conf or + ~/.gnupg/options file: + + [H samp] + load-extension idea + [H /samp] + + +<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: + + [H samp] + $ gpg --fingerprint <user ID> + [H /samp] + + As for the key algorithms, you should stick with the default (i.e., + DSA signature and Elgamal encryption). An 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, and 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/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 both 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 samp] + $ gpg [--option something] [--option2] [--option3 something] --command file + [H /samp] + + Some options take arguments. For example, the --output option (which + can be abbreviated as -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 + paired 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 option. + The --encrypt (or -e) command comes after all the options and is + followed by the file you wish to encrypt. Therefore in this example + the command-line issued would be: + + [H samp] + $ gpg -r alice -o secret.txt -e test.txt + [H /samp] + + If you write the options out in full, it is easier to read: + + [H samp] + $ gpg --recipient alice --output secret.txt --encrypt test.txt + [H /samp] + + If you're encrypting to a file with the extension ".txt", then you'd + probably expect to see ASCII-armored text in the file (not binary), + so you need to add the --armor (-a) option, which doesn't take any + arguments: + + [H samp] + $ gpg --armor --recipient alice --output secret.txt --encrypt test.txt + [H /samp] + + If you imagine square brackets around the optional parts, it becomes + a bit clearer: + + [H samp] + $ gpg [--armor] [--recipient alice] [--output secret.txt] --encrypt test.txt + [H /samp] + + The optional parts can be rearranged any way you want: + + [H samp] + $ gpg --output secret.txt --recipient alice --armor --encrypt test.txt + [H /samp] + + 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 to either + use "./-a.txt", or stop the option and command processing with two + hyphens: "-- -a.txt". + + [H B]The exception to using only one command:[H /B] signing and encrypting + at the same time. For this you can combine both commands, such as in: + + [H samp] + $ gpg [--options] --sign --encrypt foo.txt + [H /samp] + +<Q> I can't delete a user ID on my secret keyring because it has + already been deleted on my public keyring. What can I do? + + 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 + 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 my secret key because the public key disappeared. + What can I do? + + To select a key a search is always done on the public keyring, + therefore it is not possible to select a secret key without + having the public key. Normally it should never happen that the + public key got lost but the secret key is still available. The + reality is different, so GnuPG implements a special way to deal + with it: Simply use the long keyID to specify the key to delete, + which can be obtained by using the --with-colons options (it is + the fifth field in the lines beginning with "sec"). + + If you've lost your public key and need to recreate it instead + for continued use with your secret key, you may be able to use + gpgsplit as detailed in question <Rgpgsplit>. + +<Q> What are trust, validity and ownertrust? + + With GnuPG, the term "ownertrust" is used instead of "trust" to + help clarify 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 thereby introduce) other keys. The "validity", or + calculated trust, is a value which indicates how much GnuPG + considers a key as being valid (that it really belongs to the + one who claims to be the owner of the key). For more information + on trust values see the chapter "The Web of Trust" in The GNU + Privacy Handbook. + +<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 lines starting with a dash and + these are then quoted and that is not good for a 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 (Mail User Agent). + +<Q> Where is the "encrypt-to-self" option? + + Use "--encrypt-to your_keyID". You can use more than one of these + options. To temporarily override the use of this additional key, + 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 UTF-8 mapping has to be done. Make sure + that the displayed character set is the one you have activated on + your system. Since "iso-8859-1" is the character set most used, + this is the default. You can change the charset with the option + "--charset". It is important that your 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 I get list of key IDs used to encrypt a message? + + [H samp] + $ gpg --batch --decrypt --list-only --status-fd 1 2>/dev/null | + awk '/^\[GNUPG:\] ENC_TO / { print $3 }' + [H /samp] + +<Q> Why can't I decrypt files encrypted as symmetrical-only (-c) with + a version of GnuPG prior to 1.0.1. + + There was a bug in GnuPG versions prior to 1.0.1 which affected files + only if 3DES or Twofish was used for symmetric-only encryption (this has + never been the default). The bug has been fixed, but to enable decryption + of old files you should run gpg with the option "--emulate-3des-s2k-bug", + decrypt the file and encrypt it again without this option. + + NOTE: This option was removed in GnuPG development version 1.1.0 and later + updates, so you will need to use a version between 1.0.1 and 1.0.7 to + re-encrypt any affected files. + +<Q> How can I use GnuPG in an automated environment? + + You should use the option --batch and don't use passphrases as + there is usually no way to store it more securely than on the + secret keyring itself. The suggested way to create keys for an + 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 (use the interactive key editing menu by issueing + the command 'gpg --edit-key keyID', enter "addkey" and select + the DSA key type). + [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] Change to this directory. + [H li] gpg --homedir . --edit foo and use "passwd" to remove the + passphrase 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 the secret keyring. + [H li] Now you can start your new service. It's also a good idea to + install an 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 (MUAs) support GnuPG to + varying degrees. Simplifying a bit, there are two ways mail can be + encrypted with GnuPG: the "old style" ASCII armor (i.e. cleartext + encryption), and RFC 2015 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. As well, support may be + native to the MUA, or provided via "plug-ins" or external tools. + + The following list is not exhaustive: + + [H pre] + MUA OpenPGP ASCII How? (N,P,T) + ------------------------------------------------------------- + Calypso N Y P (Unixmail) + Elm N Y T (mailpgp,morepgp) + Elm ME+ N Y N + Emacs/Gnus Y Y T (Mailcrypt,gpg.el) + Emacs/Mew Y Y N + Emacs/VM N Y T (Mailcrypt) + Evolution Y Y N + Exmh Y Y N + GNUMail.app Y Y P (PGPBundle) + GPGMail Y Y N + KMail (<=1.4.x) N Y N + KMail (1.5.x) Y(P) Y(N) P/N + Mozilla Y Y P (Enigmail) + Mulberry Y Y P + Mutt Y Y N + Sylpheed Y Y N + Sylpheed-claws Y Y N + TkRat Y Y N + XEmacs/Gnus Y Y T (Mailcrypt) + XEmacs/Mew Y Y N + XEmacs/VM N Y T (Mailcrypt) + XFmail Y Y N + + N - Native, P - Plug-in, T - External Tool + [H /pre] + + The following table lists proprietary MUAs. The GNU Project + suggests against the use of these programs, but they are listed + for interoperability reasons for your convenience. + + [H pre] + MUA OpenPGP ASCII How? (N,P,T) + ------------------------------------------------------------- + Apple Mail Y Y P (GPGMail) + Becky2 Y Y P (BkGnuPG) + Eudora Y Y P (EuroraGPG) + Eudora Pro Y Y P (EudoraGPG) + Lotus Notes N Y P + Netscape 4.x N Y P + Netscape 7.x Y Y P (Enigmail) + Novell Groupwise N Y P + Outlook N Y P (G-Data) + Outlook Express N Y P (GPGOE) + Pegasus N Y P (QDPGP,PM-PGP) + Pine N Y T (pgpenvelope,(gpg|pgp)4pine) + Postme N Y P (GPGPPL) + The Bat! N Y P (Ritlabs) + [H /pre] + + Good overviews of OpenPGP-support can be found at:[H br] + [H a href=http://www.openpgp.fr.st/courrier_en.html]<http://www.openpgp.fr.st/courrier_en.html>[H /a] and[H br] + [H a href=http://www.bretschneidernet.de/tips/secmua.html]<http://www.bretschneidernet.de/tips/secmua.html>[H /a]. + + Users of Win32 MUAs that lack OpenPGP support may look into + using GPGrelay [H a href=http://gpgrelay.sourceforge.net]<http://gpgrelay.sourceforge.net>[H /a], a small + email-relaying server that uses GnuPG to enable many email clients + to send and receive emails that conform to PGP-MIME (RFC 2015). + +<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 application gpgme could do the + trick. You'll find it at [H a href=[$hGPGFTP]/gcrypt/alpha/gpgme]<[$hGPGFTP]/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 samp] + $ gpg --import my-revocation.asc + [H /samp] + + then send the revoked key to the keyservers: + + [H samp] + $ gpg --keyserver certserver.pgp.com --send-keys mykeyid + [H /samp] + + (or use a keyserver web interface for this). + +<Dhomedir> +<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, trustdb.gpg, + 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 the option: + + [H samp] + --homedir /my/path/ + [H /samp] + + 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. + +<Q> How do I verify signed packages? + + Before you can verify the signature that accompanies a package, + you must first have the vendor, organisation, or issueing person's + key imported into your public keyring. To prevent GnuPG warning + messages the key should also be validated (or locally signed). + + You will also need to download the detached signature file along + with the package. These files will usually have the same name as + the package, with either a binary (.sig) or ASCII armor (.asc) + extension. + + Once their key has been imported, and the package and accompanying + signature files have been downloaded, use: + + [H samp] + $ gpg --verify sigfile signed-file + [H /samp] + + If the signature file has the same base name as the package file, + the package can also be verified by specifying just the signature + file, as GnuPG will derive the package's file name from the name + given (less the .sig or .asc extension). For example, to verify a + package named foobar.tar.gz against its detached binary signature + file, use: + + [H samp] + $ gpg --verify foobar.tar.gz.sig + [H /samp] + +<Q> How do I export a keyring with only selected signatures (keys)? + + If you're wanting to create a keyring with only a subset of keys + selected from a master keyring (for a club, user group, or company + department for example), simply specify the keys you want to export: + + [H samp] + $ gpg --armor --export key1 key2 key3 key4 > keys1-4.asc + [H /samp] + +<Dgpgsplit> +<Q> I still have my secret key, but lost my public key. What can I do? + + All OpenPGP secret keys have a copy of the public key inside them, + and in a worst-case scenario, you can create yourself a new public + key using the secret key. + + A tool to convert a secret key into a public one has been included + (it's actually a new option for gpgsplit) and is available with GnuPG + versions 1.2.1 or later (or can be found in CVS). It works like this: + + [H samp] + $ gpgsplit --no-split --secret-to-public secret.gpg >publickey.gpg + [H /samp] + + One should first try to export the secret key and convert just this + one. Using the entire secret keyring should work too. After this has + been done, the publickey.gpg file can be imported into GnuPG as usual. + +<Q> Clearsigned messages sent from my web-mail account have an invalid + signature. Why? + + Check to make sure the settings for your web-based email account + do not use HTML formatting for the pasted clearsigned message. This can + alter the message with embedded HTML markup tags or spaces, resulting + in an invalid signature. The recipient may be able to copy the signed + message block to a text file for verification, or the web email + service may allow you to attach the clearsigned message as a file + if plaintext messages are not an option. + + +<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[H br] + 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 samp] + $ gpg --rfc1991 --cipher-algo 3des ... + [H /samp] + + 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[H br] + You need to provide two additional options: + + [H samp] + --compress-algo 1 --cipher-algo cast5 + [H /samp] + + You may also use "3des" instead of "cast5", and "blowfish" does not + work with all versions of PGP 5. You may also want to put: + + [H samp] + compress-algo 1 + [H /samp] + + 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=[$hGPGHTTP]/gph/en/pgp2x.html]<[$hGPGHTTP]/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 a 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 samp] + $ lspgpot pgpkeyring | gpg --import-ownertrust + [H /samp] + + where pgpkeyring is the original keyring and not the GnuPG keyring + 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 samp] + $ gpg --export-secret-keys --no-comment -a your-KeyID + [H /samp] + + 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 samp] + $ gpg --s2k-cipher-algo=CAST5 --s2k-digest-algo=SHA1 + --compress-algo=1 --edit-key <username> + [H /samp] + + 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 samp] + $ gpg --s2k-cipher-algo 3des --compress-algo 1 --rfc1991 + --export-secret-keys <KeyID> + [H /samp] + +<Doptions> +<Q> GnuPG no longer installs a ~/.gnupg/options file. Is it missing? + + No. The ~/.gnupg/options file has been renamed to ~/.gnupg/gpg.conf for + new installs as of version 1.1.92. If an existing ~/.gnupg/options file + is found during an upgrade it will still be used, but this change was + required to have a more consistent naming scheme with forthcoming tools. + An existing options file can be renamed to gpg.conf for users upgrading, + or receiving the message that the "old default options file" is ignored + (occurs if both a gpg.conf and an options file are found). + +<Q> How do you export GnuPG keys for use with PGP? + + This has come up fairly often, so here's the HOWTO: + + PGP can (for most key types) use secret keys generated by GnuPG. The + problems that come up occasionally are generally because GnuPG + supports a few more features from the OpenPGP standard than PGP does. + If your secret key has any of those features in use, then PGP will + reject the key or you will have problems communicating later. Note + that PGP doesn't do Elgamal signing keys at all, so they are not + usable with any version. + + These instructions should work for GnuPG 1.0.7 and later, and PGP + 7.0.3 and later. + + Start by editing the key. Most of this line is not really necessary + as the default values are correct, but it does not hurt to repeat the + values, as this will override them in case you have something else set + in your options file. + + [H samp] + $ gpg --s2k-cipher-algo cast5 --s2k-digest-algo sha1 --s2k-mode 3 + --simple-sk-checksum --edit KeyID + [H /samp] + + Turn off some features. Set the list of preferred ciphers, hashes, + and compression algorithms to things that PGP can handle. (Yes, I + know this is an odd list of ciphers, but this is what PGP itself uses, + minus IDEA). + + [H samp] + > setpref S9 S8 S7 S3 S2 S10 H2 H3 Z1 Z0 + [H /samp] + + Now put the list of preferences onto the key. + + [H samp] + > updpref + [H /samp] + + Finally we must decrypt and re-encrypt the key, making sure that we + encrypt with a cipher that PGP likes. We set this up in the --edit + line above, so now we just need to change the passphrase to make it + take effect. You can use the same passphrase if you like, or take + this opportunity to actually change it. + + [H samp] + > passwd + [H /samp] + + Save our work. + + [H samp] + > save + [H /samp] + + Now we can do the usual export: + + [H samp] + $ gpg --export KeyID > mypublickey.pgp[H br] + $ gpg --export-secret-key KeyID > mysecretkey.pgp + [H /samp] + + Thanks to David Shaw for this information! + + +<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. + + To setuid(root) permissions on the gpg binary you can either use: + + [H samp] + $ chmod u+s /path/to/gpg + [H /samp] + + or + + [H samp] + $ chmod 4755 /path/to/gpg + [H /samp] + + Some refrain from using setuid(root) unless absolutely required for + security reasons. Please check with your system administrator if you + are not able to make these determinations yourself. + + On UnixWare 2.x and 7.x you should install GnuPG with the 'plock' + privilege to get the same effect: + + [H samp] + $ filepriv -f plock /path/to/gpg + [H /samp] + + If you can't or don't want to install GnuPG setuid(root), you can + use the option "--no-secmem-warning" or put: + + [H samp] + no-secmem-warning + [H /samp] + + in your ~/.gnupg/options or ~/.gnupg/gpg.conf 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 samp] + gpg: Please note that you don't have secure memory + [H /samp] + + This warning can't be switched off by the above option because it + was thought to be too serious an issue. However, it confused users + too much, so the warning was eventually removed. + +<Q> Large File Support doesn't work ... + + LFS works correctly in post-1.0.4 versions. If configure doesn't + detect it, 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 are not displayed correctly after + signing uids. Why? + + This happens because some information is 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 file, 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 is 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 1.0.2 or older on Windows. 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 instance of 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 binaries (e.g., 1.0) have problems with keys from newer + gpg binaries ... + + 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 binaries have problems with + newer keys. Because of security and bug fixes, you should keep your + GnuPG installation in a recent state anyway. As a workaround, you can + force gpg to use a previous default cipher algo by putting: + + [H samp] + cipher-algo cast5 + [H /samp] + + 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 X.509 certificates? + + GnuPG, first and foremost, is an implementation of the OpenPGP + standard (RFC 2440), which is a competing infrastructure, different + from X.509. + + 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, å (0xE5 in ISO-8859-1) becomes Ã¥ (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 an: + + [H samp] + unset CDPATH + [H /samp] + + 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 + correctly. You may want to apply this patch if you can't upgrade: + + [H a href=http://www.gnupg.org/developer/gpg-woody-fix.txt]<http://www.gnupg.org/developer/gpg-woody-fix.txt>[H /a] + +<Q> I upgraded to GnuPG version 1.0.7 and now it takes longer to load my + keyrings. What can I do? + + The way signature states are stored has changed so that v3 signatures + can be supported. You can use the new --rebuild-keydb-caches migration + command, which was built into this release and increases the speed of + many operations for existing keyrings. + +<Q> Doesn't a fully trusted user ID on a key prevent warning messages + when encrypting to other IDs on the key? + + No. That was actually a key validity bug in GnuPG 1.2.1 and earlier + versions. As part of the development of GnuPG 1.2.2, a bug was + discovered in the key validation code. This bug causes keys with + more than one user ID to give all user IDs on the key the amount of + validity given to the most-valid key. The bug has been fixed in GnuPG + release 1.2.2, and upgrading is the recommended fix for this problem. + More information and a patch for a some pre-1.2.2 versions of GnuPG + can be found at: + + [H a href=http://lists.gnupg.org/pipermail/gnupg-announce/2003q2/000268.html]<http://lists.gnupg.org/pipermail/gnupg-announce/2003q2/000268.html>[H /a] + +<Q> I just compiled GnuPG from source on my GNU/Linux RPM-based system + and it's not working. Why? + + Many GNU/Linux distributions that are RPM-based will install a + version of GnuPG as part of its standard installation, placing the + binaries in the /usr/bin directory. Later, compiling and installing + GnuPG from source other than from a source RPM won't normally + overwrite these files, as the default location for placement of + GnuPG binaries is in /usr/local/bin unless the '--prefix' switch + is used during compile to specify an alternate location. Since the + /usr/bin directory more than likely appears in your path before + /usr/local/bin, the older RPM-version binaries will continue to + be used when called since they were not replaced. + + To resolve this, uninstall the RPM-based version with 'rpm -e gnupg' + before installing the binaries compiled from source. If dependency + errors are displayed when attempting to uninstall the RPM (such as + when Red Hat's up2date is also installed, which uses GnuPG), uninstall + the RPM with 'rpm -e gnupg --nodeps' to force the uninstall. Any + dependent files should be automatically replaced during the install + of the compiled version. If the default /usr/local/bin directory is + used, some packages such as SuSE's Yast Online Update may need to be + configured to look for GnuPG binaries in the /usr/local/bin directory, + or symlinks can be created in /usr/bin that point to the binaries + located in /usr/local/bin. + + +<S> ADVANCED TOPICS + +<Q> How does this whole thing work? + + To generate a secret/public keypair, run: + + [H samp] + $ gpg --gen-key + [H /samp] + + 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. Files 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 should be very + careful with. 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' command. '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 with: + + [H samp] + $ gpg --fingerprint KeyID + [H /samp] + + over the phone (if you really know the voice of the other person), 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 keys generated by GnuPG in v3 (RFC 1991) 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 + accepts 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 samp] + $ gpg --list-keys --with-colons + [H /samp] + + 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) with: + + [H samp] + $ gpg --list-ownertrust + [H /samp] + + The first field is the fingerprint of the primary key, the second + field is the assigned value: + + [H pre] + - = No ownertrust value yet assigned or calculated. + 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 trustdb.gpg file 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 samp] + "key 12345678.3456" + [H /samp] + + 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 samp] + "uid 12345678.3456/ACDE" + [H /samp] + + 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 samp] + "sig 12345678.3456/ACDE/9A8B7C6D" + [H /samp] + + 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? + + In version 1.0.7 or later, you can 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 is not changed 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-signature is increased by one second when + running this command. + + +<S> ACKNOWLEDGEMENTS + + Many thanks to Nils Ellmenreich for maintaining this FAQ file for + such a long time, Werner Koch for the original FAQ file, and to all + posters to gnupg-users and gnupg-devel. They all provided most of + the answers. + + Also thanks to Casper Dik for providing us with a script to generate + this FAQ (he uses it for the excellent Solaris2 FAQ). + +[H hr] + +Copyright (C) 2000, 2001, 2002, 2003 Free Software Foundation, Inc., +51 Franklin Street, Fifth Floor, Boston, MA 02111, USA + +Verbatim copying and distribution of this entire article is permitted in +any medium, provided this notice is preserved. diff --git a/doc/samplekeys.asc b/doc/samplekeys.asc new file mode 100644 index 000000000..21c36d89e --- /dev/null +++ b/doc/samplekeys.asc @@ -0,0 +1,461 @@ + pub 1024D/5B0358A2 1999-03-15 [expires: 2009-07-11] + uid Werner Koch <[email protected]> + uid Werner Koch <[email protected]> + uid Werner Koch + uid Werner Koch <[email protected]> + sub 1024D/010A57ED 2004-03-21 [expires: 2007-12-31] + sub 2048R/C3680A6E 2006-01-01 [expires: 2007-12-31] + + pub 1024D/57548DCD 1998-07-07 [expired: 2005-12-31] + uid Werner Koch (gnupg sig) <[email protected]> + + pub 4096R/99242560 2002-01-28 + uid David M. Shaw <[email protected]> + sub 2048g/1643B926 2002-01-28 [expires: 2012-01-26] + sub 1024D/49E1CBC9 2002-01-28 [expires: 2012-01-26] + + pub 2048R/CA57AD7C 2004-12-06 + uid PGP Global Directory Verification Key + uid [jpeg image of size 3400] + + pub 1024D/B2D7795E 2001-01-04 + uid Philip R. Zimmermann <[email protected]> + uid Philip R. Zimmermann <[email protected]> + uid [jpeg image of size 3369] + uid [jpeg image of size 3457] + uid Philip R. Zimmermann <[email protected]> + sub 3072g/A8E92834 2001-01-04 + + pub 1024R/1CE0C630 2006-01-01 [expires: 2008-12-31] + uid Werner Koch (dist sig) <[email protected]> + + +-----BEGIN PGP PUBLIC KEY BLOCK----- +Version: GnuPG v1.4.4-svn4128 (GNU/Linux) + +mQGiBDWiHh4RBAD+l0rg5p9rW4M3sKvmeyzhs2mDxhRKDTVVUnTwpMIR2kIA9pT4 +3No/coPajDvhZTaDM/vSz25IZDZWJ7gEu86RpoEdtr/eK8GuDcgsWvFs5+YpCDwW +G2dx39ME7DN+SRvEE1xUm4E9G2Nnd2UNtLgg82wgi/ZK4Ih9CYDyo0a9awCgisn3 +RvZ/MREJmQq1+SjJgDx+c2sEAOEnxGYisqIKcOTdPOTTie7o7x+nem2uac7uOW68 +N+wRWxhGPIxsOdueMIa7U94Wg/Ydn4f2WngJpBvKNaHYmW8j1Q5zvZXXpIWRXSvy +TR641BceGHNdYiR/PiDBJsGQ3ac7n7pwhV4qex3IViRDJWz5Dzr88x+Oju63KtxY +urUIBACi7d1rUlHr4ok7iBRlWHYXU2hpUIQ8C+UOE1XXT+HB7mZLSRONQnWMyXnq +bAAW+EUUX2xpb54CevAg4eOilt0es8GZMmU6c0wdUsnMWWqOKHBFFlDIvyI27aZ9 +quf0yvby63kFCanQKc0QnqGXQKzuXbFqBYW2UQrYgjXji8rd8bQnV2VybmVyIEtv +Y2ggKGdudXBnIHNpZykgPGRkOWpuQGdudS5vcmc+iGEEExECACECF4AFCQ4Uh/0F +AkG8aF4GCwkIBwMCAxUCAwMWAgECHgEACgkQaLeriVdUjc0EkwCfTXfXdqDS2COs +ZRm0OUphuY0h4x4AnRSlWyPGnKUFxKOw8TwwCSLsdvZHmQGiBDbtSOkRBACURhKn +GIFyXIeX61GAY9hJA5FgG4UalV55ohdz4whBgDzDGLE3XYlO8HCn4ggKilll6MOw +Y0yZeg6PEU9Y3SqTzpQSV6qj2M7MgcS8xOpi6bNCu0iyZUik0KklUXMdI8e/CVmB +pQJT9CofbD1dsP6z4dC6z3jil0+5Wbfw6yIXzwCgy/7Fagq5mN0H760/JEiiXILS +1n0D/3H26lTaxo1vGput9Td1FQN7Vn6YDP0/To5ipsOODROV3zyUwF5QleY+8zTF +JA3qD5KxRfA726WELOF1mB6Mw44UdkPniOoGdMH5oSx6qnNnlVZBBu3U+e1qfQwL +QjHu0WX4Z2q00DKpWLThGv7Loh5NKi6OfTbMhfHoevCAzQnmA/wKc6J8GqthENTh +KXxZaei3Ep0t+PlBmbUzuAYCXZhI6/0KyD6emyQ7LYIaPv9qEfMkMLhxicG0v/AA +wOCBRKS3bkqc6wAYaO0bjUHJvem3HkWPux82t83+6YPyRnVjm/mwt0uEyKSvt7Md +2DVrO3lEcKRkRHiYuf0nonPhl5Rs5bQaV2VybmVyIEtvY2ggPHdrQGdudXBnLm9y +Zz6IawQTEQIAIwIXgAIZAQUJE2uL/wUCQllAcgULBwoDAgMVAgMDFgIBAh4BABIH +ZUdQRwABAQkQXeJJllsDWKI6xwCfV3paxYsk7KQmrtOUxNmZb004OQoAn3uq9imO +pgxqsXhXaLfz5IqZu5O7tBxXZXJuZXIgS29jaCA8d2tAZzEwY29kZS5jb20+iGME +ExECACMCGwMCHgECF4AFCRNri/8FAkJZQHoFCwcKAwIDFQIDAxYCAQAKCRBd4kmW +WwNYouXsAJ9nbkvbiJZvNlzwBL98x7YB+u9fsgCfXE6vHv6DJk7Eh9CY+Gcdn6kC +G8i0C1dlcm5lciBLb2NoiGMEExECABsFAjbtSOoFCQzJfIADCwoDAxUDAgMWAgEC +F4AAEgkQXeJJllsDWKIHZUdQRwABAbXWAJ9SCW0ieOpL7AY6vF+OIaMmw2ZW1gCg +kto0eWfgpjAuVg6jXqR1wHt2pQO0HVdlcm5lciBLb2NoIDx3ZXJuZXJAZnNmZS5v +cmc+iGMEExECACMCGwMFCRNri/8CHgECF4AFAkJZQHoFCwcKAwIDFQIDAxYCAQAK +CRBd4kmWWwNYovxpAJ0ftTtETxhK8aKfIok/+43wNbQASwCfSFCPuVKTNHpv4JJ7 +9feDCtfxxLG5AaIEQF3aTxEEAP9SgfIbIPL6BQ1nqoblsTYoiwWPL48uBZPjkDfy +8XsVR5V9aRQlggC4x4/MD3Ip5AUgReI7PcHnp4m3vcVLXPl+/7i7hAwd84iKzgN8 +I8VW0EevflcNm7nbWEnpjaGxJWFbhSLI1DmqnafoU8nZgGp2QoE+flgGDd559C3S +iHRTAKDbqgS3EDhTbwfS+bAhW5Xi8/2CPwP9HueeuW9M/cyt8UvliLsj2eYMEIy7 +CeSLO13XfnqCjcnHK+b59/ADd99dpMaq3gKj7Aj1RIsRV2qWDJpDNXVxP7Cy+Fzx +elQsytPQOV8H8AkB+RgmSyfxlNRUkC3sQU6jR9IwmPD4iB5fp/SqUpn++77TAArX +qsfHbmlnwcuU1EAD/i7CEhxLBYS1N77hwxL8DWCqjpi+1PKG+6dc0BQFIU3uUhbz +LGfqEobUDhveqgtlsvoEZ/lR8RgMv/uOjXEgiATQyTEa7s3M2vjXlpLjXjzklma3 +Lqmcam3dEf/5OR02yZif6hPU/x8f/VQle0kKNKdOCV1+dlo8aJH2UIZRRIvtiE8E +GBECAA8FAkBd2k8CGwIFCQcbVgAACgkQXeJJllsDWKIiqACff+MvmBLGSBA0NkdK +9ZB3fTSzCdcAoLrJ9QYe2+vFu2WYGZNC5xJy2db1iE8EGBECAA8FAkBd2lACGwIF +CQcbVgAACgkQXeJJllsDWKLDcQCfdFh2/dY6p8Sz6nS5tfx5akOqmPAAn3Y/PpYm +Z+bIfoFcHlzjPxmI93uSiJcEGBECAA8CGwIFCQcbVgAFAkR1rB0AUkcgBBkRAgAG +BQJEdawTAAoJEGB4TpQBClft2RMAn1XiL/bC9hByZInCJTaCd8WS8kYCAKCfpAWw +LIxkfwAeD/RI+2p00nQfvAkQXeJJllsDWKKx7QCguc4/HiEs64Ey5p6Yihy67X8E +0YsAnRXMFdXVP7ww8uldljPiD1TgyurpuQELBEBd2ykBCADRKFS0lZw/2MawS97P +3nVyt2FF9XWb8si7T9Jgl+NRF93uqUOIC15s3u5SVPcwdIhoG04wYKHTLKhyBAjF +p4azfLmiIBDDp37DY3SAtJT6TsgULR+yFkXbRvuIOU5N/0WxzrK6JJwlFVEyaPX7 +zmWVKMCj+SMj2FrmltuVS0aCf0io3n97bUAvuU3dgjTFoHqW4017smfbE4VMwnLY +i3/1SS9s0ysKM6Px5yEM3oQiOW/9pS48wSFfs3lXi8N1BikgPdU5FFA+5BGSUhxy +Ff+lqdjwcByBC7LT3dCrFeWQOL0UeVh6wG48O63j8jue7mfTm+559uXnD/J65PiH +cZTnAAYpiE8EGBECAA8FAkBd2ykCGwwFCQNY7wAACgkQXeJJllsDWKIS1gCgoJ2z +4OnA0dVt7ZM/PeAsKXA0KFUAn3AV3yuZKX4WHw5Pnf5sLmF5LUkluQELBEO4FiIB +CADRWoeCwf4lVIJQahM7ytFRvPMrkSZQy072/I6/4QPKsaHI+HnoB8PjTmBpyBDL +K8Y6Of3Y1hNb77xe+m2g+8Wq/BUKHvUi1F+xzszpnixtMr+QOiy6U7kCJA6fGvq0 +qmzrXGcv5rXpGvWwyZfymTLW4X2WKgNL8bhODy0uJ9ZR/fhjE7nnIHgIboSnBAUP +HCsI9BFumsbU8FKsKJCOBqziHEyDHbix7uP6ByYslH2tUw9WdQU8Yzo2mWojghXp +jE7UT0tAb4QNTdwurLgiEIH5umsM43elr1/2nd06KigQX+NR4MqytR+28JtEEKvU +LwJZpmExs4B+OB4x8l+6Lc0/AAYpiE8EGBECAA8FAkO4FiICGwwFCQPBFYAACgkQ +XeJJllsDWKJdywCeNyRtO1/yIyiNkotYRfO5y3xuHocAnAyA4jaxa702sRs4iPR/ +WWJkMgEqmQGiBDpU6CcRBADCT/tGpBu0EHpjd3G11QtkTWYnihZDBdenjYV2Evot +gRZAj5h4ewprq1u/zqzGBYpiYL/9j+5XDFcoWF24bzsUmHXsbDSiv+XEyQND1GUd +x4wVcEY5rNjkArX06XuZzObvXFXOvqRj6LskePtw3xLf5uj8jPN0Nf6YKnhfGIHR +WQCg/0UAr3hMK6zcA/egvWRGsm9dJecD/18XWekzt5JJeK3febJO/3Mwe43O6VNO +xmMpGWOYTrhivyOb/ZLgLedqX+MeXHGdGroARZ+kxYq/a9y5jNcivD+EyN+IiNDP +D64rl00FNZksx7dijD89PbIULDCtUpps2J0gk5inR+yzinf+jDyFnn5UEHI2rPFL +UbXWHJXJcp0UBACBkzDdesPjEVXZdTRTLk0sfiWEdcBM/5GpNswMlK4A7A6iqJoS +NJ4pO5Qq6PYOwDFqGir19WEfoTyHW0kxipnVbvq4q2vAhSIKOqNEJGxg4DTEKecf +3xCdJ0kW8dVSogHDH/c+Q4+RFQq/31aev3HDy20YayxAE94BWIsKkhaMyohhBB8R +AgAhBQI6VPBbAgcAFwyAET/HMgQdI+nqZt21AJydvCHfdNxhAAoJEMdGNjmy13le +V7gAoKHV2q0XEP8GJkyp0/V5lgbwBmBMAJ9TtVfw2khoaZ3LNV2tINSjj0Alp7Qi +UGhpbGlwIFIuIFppbW1lcm1hbm4gPHByekBtaXQuZWR1PohdBBARAgAVBQI6VOgn +BQsJCAcDAhkBBRsDAAAAABIJEMdGNjmy13leB2VHUEcAAQFWUQCfWWfTDHzSezrD +awgN2Z4Qb7dHKooAoJyVnm61utdRsdLr2e6QnV5Z0yjjtCJQaGlsaXAgUi4gWmlt +bWVybWFubiA8cHJ6QGFjbS5vcmc+iE4EEBECAAYFAjpU6LcAEgkQx0Y2ObLXeV4H +ZUdQRwABARPJAKDmKL2Aeo6OWwcZKyqSWLD4drQxfgCguJ7k7XEuQr+tL0ndoin0 +RSQTkCHRzH//AAANOgEQAAEBAAAAAAAAAAAAAAAA/9j/4AAQSkZJRgABAQAAAQAB +AAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIfIiEmKzcvJik0 +KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 +Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAAR +CACQAHgDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL +/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0Kx +wRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNk +ZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5 +usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEB +AQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAEC +AxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygp +KjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImK +kpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk +5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDqKXFKDSEgDJOBXSeeHaoJrqKI +fMwqleanyUi/Osi4udqNLM+EUZJNNIlvsakuqjnYazbzxKlopLOHYfwqa5S/8QvO +xjtyY1z17msqWZpGAzuz1wP61LmuhrGk3udHceO9RL4gSNB6EbjVU+Ndd3YEir9U +Fc+nLYC49jWhbt5UW0RIGbpyKzuzbliuhuWfjnUw377ypQv3vk2/rXVaV4o07VFC +iUQzd43P8j3rzVpnLESIgHoopZJIYIxPDg89Vb7tNSZLppnsIIYAggj1FKa4XQ/G +7r5dvexI0R4WVTgj6jpXbxyrNGskZ3IwyCD1FWncxaa3F24oNLRTJIyKKecUUwHj +rWbql2Y/3KHk9a084HPauZu7gTXLsemeKEgkyLmuS8TaqXmNlG3yofnweprp7qdb +a1lnbpGhavPH3yN5rH55DuJNKo9LF0Y3d2T2sTt+8dflPQYzk1twaJK8AeVCxfkK +OMVBo1qJLmJSPkHzH3ru4bRJlXjFc7Z2JXOBudBlIyEYAevaq8FkLRsld5J69xXp +DaNC5PByffAqlJ4b8wkFiPTjpSci/ZnA3cXDbmcsRkEmoILGWYkpu9zXfjwkzgGU +qVHtWhbaFbWyjEa7vYUlIfszy+e1uLEhnjfY3Xjiu28EeJZJ3XSpxuVUzFJ3Hsa0 +dU02IwMCgI78VxEcB0nxAnlOUDfPGfQ1pF6mNSN0eu0lQ2c4ubOKYfxoGqatjjG0 +UtFMQTsFgdj2U1zGB2OfwroNTcrZPjvxXP5pxJkZniF9miz5/iwv61xA+aUDOR3x +3rq/F0hWwhjH8cmT+ArmIIvNmSJeD61lU3OqivdOn0KNTPuU5xxgdBXZ2TAIOe1Y +Gj2ItLYYGTitSK7ghchpBk9hWD1OqKsbCcke1WkdcYIFUYZo3I2uDn0q2FIIx3pG +y1JHAJAAHNVpCu4kcCpFJaZgOiioJm2vt6E9KQzPvZAUIHNcL4jjC3Fq/cOR+Fdt +dHnHrXH+JSjMmexP8qqLMah1vgq4kuPDNuZc5jLRgnuAeK3s+lYng2PZ4YtAeSdx +5/3jW5XUtjzpbsaTRSniimSUdZmCwrF3bmsWtDWj/pKD/ZrNzVLYh7lTVbCG8tQ1 +wGKKTgoeR71yGmWNzPdpLb/NsfOG4yK72+XfoU20Y8uJmJPucf41geG38wSMRwpC +iuVu8nc9JRUYRSNoXqiHywjJOy/LH1J9hWcraeFBup0jnI3FVXcfyrYvoEmsSdoL +qQQ2ORyKVdDRcmNEORz2P51m20aRjcy5L0mKIWmpWpVc8mHa2M8c960NP1q9hjYS +SJMy85wentg/zph0OSCJ47UCNJAA4JBz+lVv7NayUlV3DG04bGc1Dl2NIxstToot +VaMFlaEmY4UEkZ9hVPUtZS2lU3Aj3DjCPnH8qp60vkWVrDHkMoULjocVizRXDxB4 +1aSbJLh1BUjtjvmmmEtDVk8QWLLuD89g3Ga5bxDceY0Ei5AJY4PrV9mit40juNPX +bIPneNSNp+hrLvdO86SGCJsB5Pl3N68YFXFmMr9T0vw2mzw7YjrmEH8+a06itYkh +to4kXasaBQPoKkNdR57EPSig0UyTH1sEXSHsVrNzW7q1uZoBIvVKwqtbEvcfefPo +N1GpADR4ye3P/wBesDQEaJHU93PFbNzP5em3K7S25OlZumxFGXBGc5I9zya5ZRs2 +ehCfMkdJbqs0LRN91hg1pQQtDCBKPMI43L396yLeTax7VdGrJbqRlWfsDWLZ1xWh +PcXFvEhZoZRj8vzqghM9woMe1B8yoe3ufeo5pDcobiW4Tcpyq54H1qGDW0aXeFUh +OCVOaSa6ltE2twubZZlHzQsGA9aW1WC6gVwVdT09foaj1PXbaeLy1CqzcbV706yg +iZQs4aFnGUkjOD9D60SaYK4XenW5iJ2c/WucVJX1qzEfOJlUH6cmupeJY1w11Iw9 +OP8ACsSNgNegRFyC/AA6Zq6aVznr6RO34Hako5PUYorrPMENFIaKACQZiYY6iuWc +FZCp7Gur61z+qQ+TclscNzTiTIoyLvjZemQRVLTTifyygUr156VezmsbUDLY3YlD +YSQ8H0qaqujWhK0jo2woDk8DrXOs8l9eTeQHI3EgjkYqpca4fLMcbEMoxyeM07RL +42t+vmk7W6iuJxaPRTTdh10bpVMDu0eTyDnp9aq2drdfaFaNhgckKwBxXaXKwtH5 +2wEDuRWNJqVgGKPbINo5YDrSTNuWK3Zg38N48m9iS2SQA2cYq9aapdJCIblnjKn5 +WHar32GzuxvjTAPYHFJq7W1qkEPAbpgUeRMlbZlqHUjdW2cguDg46fWl0KJ7jxIW +IysEe4nHeq1oYYrNSD0GcVueFICIbi6YYM0mVz/d7VtSWpy15e6dATSGkJpO2a6T +hFJoppNFAhj3MUf3mFZGqXUdy6BMELU8GiXExDXcu0d1Xk1p2+nQWw/cwgH+83Jq +rWFqznorC7nGUgYL/ebgfrVfVdGa80h1UZlQFlx3xXXT7RE67yXI7dKrImxAw7c0 +90C0dzxIFkk2SZznByav2skk0qFDzjLH0xXVeLvBzMx1CxA2Ocso7E1xdtI9rO6S +Db2NcjXQ9BSuro7bT74y2z2rNkA4znNStpNreyGZTtJTHXpXJR3ptFUhyNwzx61o +QeIvs8flocnGCcVm1Y3jNPc04mTSRKGcNj7g+lc5qN897dPcHg54x2FNu9Qku5Bu +4XJp+m6Re61MIrZDsj5eRuFH1pxjqROf3Gr4etLnVL0LyE6s3YCvRLeFLW3SFOFR +QBVHQ9Ihs7IxIoL5yzdCTV4xvE3D/g4rqjCyPPnPmdyQkH8aCaZv28suPXHNKGBG +Qc07MgDn6UUhNFAGmqHkscewpjnJ4qZhlKZjJ/CmXYrtFhSzDkn+lMWPAGOhHFXJ +UypHr/hUUe0t5ZHJGV/qKLisJDtKmNgCp4wen0rl/EPgS0ut09rFjOSUX7y+49R7 +V1DJ5b5/hNVtb1mHRdHlvJ2xtwqcZyx6Cs5JM0hJpnkWoaBeW0525aMHA/wqrBoW +oXMwSOI7mOABySa6ifW9W1KASBLe3twebhgCfwNNi8XQ6XgpKbmXp+7iChvbNYdT +p5tNCzpHw6uSY5dRnVVz80SHJI9zXZixtdOsRDaQpDHnhVHU+tSWFyL6yjnG5RIP +mRuGQ91PuDQd1zc4AyqV0xSRySk5bkcceyMHkHOanWN2HJyOvNSiIAHPvUuAAvvx +VXJsVli4IBwR1HrTXtznrjPtVhky+fUU7naCfUU7isUGhZejZ9sUVcdCxxjt1op6 +CsWs/u/ypFHzfhS9Bj3pT1yKg0FwGB/Gq7Aq4YdRyKtIMg1E69PUYpDB8Mgbsaxt +Z05NYhXTp8i3kzvI6j0x/OtUuBGUP1qjJJ5CvczSrGicszHhR70xdTy7XLS60y8b +R5jmKGMNERwHH96r3gfR7aZ5NZvFL/Z32wRkcbgMlj9M8VDqeo22t+JZL2V3Fq37 +qM9DtAxn8Sa6fwtAunatPprOJLe5Tzrd/cDDD8ufwrFW5rGzb5Tb0xwLad1BCtIW +AIx1AqzCjIAwOGPWoogzyunyhSR90VfEf9DW2xh1IP3jORk9anVG8sbjyKfgA09e +dwouFiJ+GH4il2ZUjvQ/b609SN2KYC4AGexopkzHyyB1ooSBs//ZiE4EEBECAAYF +AjpWjyIAEgkQx0Y2ObLXeV4HZUdQRwABAQfRAKCSnx3toHhFsCAaIsCRkmFdI4Hn +9gCbBDKIqvBEjybcnaBW+iZufcjAzsfRzNf/AAANkgEQAAEBAAAAAAAAAAAAAAAA +/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0V +FhEYIx8lJCIfIiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoL +Cw4NDhwQEBw7KCIoOzs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7 +Ozs7Ozs7Ozs7Ozs7Ozv/wAARCACPAHUDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEA +AAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIh +MUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6 +Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZ +mqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx +8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA +AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAV +YnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp +anN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPE +xcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2 +aiiigAooooAKyNb8S6boUZN1Lulx8sS/eP8Ah+NZXjbxcdCt/sdjh7+UdcjES+p9 +68fvLyW6leaa4mmlY5kkL4AP1qXLsaQhfVnc6l8TdSncrYRRW6Zx03t/L+lYsvjj +XnA8zUZY8nI2kr/QVzlu0b8+S2R/HvJNWFgAYuwDFuvJ/lzms2/M2UbdDrLPxlrE +TK51CRxn7sm1gfzrs9F8b2d8ix3v+jyn+Ij5T/hXkQj8gZX5hnlCMZq9YShm8vzD +t7HuDQm0KUUz3ZHWRQ6MGU9CDkGnV5VZ6xf6FJ5qTlY8/Mh5Vh9K77QNfi1uEkJs +kUZI7EeorRSuYyjY16KKKogKKKKACiiigArO17VU0XR575sFkXCKf4mPQVo1wHxX +vfJ0yztw+N8hdh3IHA/nSew4q7PNdT1Ga9vpLi4kaaaRyWY8KDRYWCXkuG5Qc+gz +We8mWAUYz19TW9pbGJAScZ6msJuyO2nG7NOPTrcxhAMdOmOKp3eg36OWsw0qY4x2 +rVgkynIyfrite0bKDBrBNo3aOOtvDWr3dwPPjEKDOS1dJbeFJYY/3UqKxGC5TJ/W +t+Fdx4HNaMUSlM9yK1TbMJ2RwWo+GtXeMiaZLlByCo2mpvCOpTaDrKpdEmA/KxIw +Vz612rR4PPWue13T4RcwXBUBWYI5A6Z6GmpNMmyasejghgCDkHkGlrD8J3ck+lfZ +5m3SWreXu/vL/Cfy/lW5XQnc5GrMKKKKYgooooAK8j+LF4ZNchtmACQQjGDySefy +6V6jqeowaVp099cnEcK7j7+grwXxjq1xr2ovqYRUV8DaCTtA7VMmtjWnBv3jMgjM +0wAUnFbcCtHGFHOevtUek2RisUmkwS3O4HIqeWTaP3e0HPzMemfwrmk7s7oWSuat +k7BQG71v28OFUpjHt2rj7XWreH91NLGWPQ7W/qK6bTdYs5IgFuI8njGajlsPmubt +rmMGVuAo5q7GxWMcZBH51nmVDaIqMpErDJB7VcWf98Y+wXg9jVowlqTtIpGP6Vj+ +KNv/AAj1y4xuUAr9cjFajHnHWsvxG6DSij8h3H6c0yUW/Aju/n7xg7Rn6gkV2Fc1 +4Lg22MszD53IBPf1rpa6I7HNLcKKKKokKKKKAOQ+JchHhuOIMR5twufoATXkjOkj +qqAHLYAzxXq3xLikl0uzKAkCYg49SvFeYR2htbqKJyN3JODnNc837zO6l/DSNOLe +ijyuy7cEZzVG50jUbsmWKTamTny1GRzV4TAPtUZ+la2nyJbBWmZogScBhgfnWN7G +9jmrfR7/AM7ZJdq8GDw8Suf6VRtXubfUFjMZR8jATjP0r0jfbMM7ULHvgVyl3BFP +reICruTglTwvPr60+buKK1NeKe5S3W5liaNmHBTgKfU//WpJ/E13bYVJxM+MnEYy +K25LKNtPtkPCK4U/TNYF94IinuWfcUVjuDxnBBpITa7GppvitLnalxZzRseN6pkE +/TtUviOVbmC0jhdSGk+b26VlGz1PSpkEVz9sthgGN/vr7hq6PT7Qajq9os4ZI0Bf +YB1AOcH/AD3rSOrsYzVlc6bQrZrXR4EddrldzD3P+RWjRRXUcQUUUUAFFFFAGN4r +06bU9Blhtl3TIQ6qOrY7D8K8fvraW31JVmR0ZQPlYYI/Cvea8q+IVi0PiFrgnImj +BUY/P+VZTj1OijP7JyP2n/SMnPB9eldXpV/5kIRsbfQ9K4yTMbhmyMnvUg1FoGYy +I4THAXoPT+dYONztckkb2v69ZwSJa29qgLf6ybYPlHt7+9Q6JdWA1NWgYBMdBXOz +Tf2id0aFg3anW+l3Fkv2tmcL1A/wo5VYSl9x6+ghnswgcEOOcdvemWs7zQHgSMjF +GK+oNcZpd/Kl5Ct1JMIVAOA+M/WtGzu10nXHWObdbXZ8xCT3PVTSuRyHTymN1QeU +SwYcba1dHt1W5Z2xvVOg9z/9YVmC583GOM9BWtoTectzN/CZNi+4H/661p2uc9S6 +ia1FFFdBzBRRRQAUUVi6x4v0HQwft2oxK4/5ZodzfkOn40AbVcX8SrHdo6akg+e2 +ba2P7p/+v/OsDVvjhYws0elaZLO3Z5m2g/gM/wA6525+I+t+IQ+n3ywQ290rDy0j +wQMZHJOetS9jSKdzm7i+USAlhkZ56Dr1rd0vy5o9r4cuvzcg54rjLzNvcFMY55xW +3od8FKx4GR8zMemazlG6N4zfMap02KC6bEcTJ6Nx+tbumPYyRrb/AL+Jc/dBEig+ +wYcU20FtqSguuMcZ7mtCx8PrDMZGkJVGyB/Kuf1Oly7Ej6XcyebgQ3IZTtdl2OD2 +6cViw2lxeSrayYTyzklTnbg9veun1LUU021IDb5Dwi+vvXOaVfIJZJN4LF8YHuad +mTzHTqZEt/3eTIFwg7lu1dnpdn9g06K37gZb6nrXn0mvWujeVqOoI8ltG6/LHyS3 +b/Gu20TxRo3iCMNp16kj4yYm+Vx/wE10U1ZHJWd3oa9FFFamAUUUUAeF+KPijqur +I0Fq32K3PaJvmP1avPbi5kuZCWJOTyfWmzOzNinwxBRuPXtSNCe3hSIBiMv/ACp1 +vcbdThkbp5gz9KYzEL9agcE7vXND1Hexs6raecSVA3jkZ71nWdy1qWjkG3sQRWlB +di8tQ+cuvyuPcVFMsc3yyrz2P/16yi2tGdE4p+8jWsfEMNsU3H7vf+92rdt/FyiI +4Zcnt6GvPmsyv3HB46k4zUiQTRKF3gAHOd3ehwi9SVOSVrHT6nrjzSYMgJUjknOK +gsZnS4MrMVRerY/zk1mafAly2W3SAclgNoNWPNaW+kUDbFF8qovQHufr/hVqFkTz +XNG+v3v5T5oxGq4WM9AKxlMlheCS1leNkO5CrYI59a0XOPvAfX1rN1OPPIB5TB+l +USekeF/ipNEqWutKbhBwJ1Hzj6jv/nrXpWnaxp2rRCSxu4pwRnCtyPqOor5ht5G3 +Dca2bW+mtXEkEzxsDkMuQaCeVM+kqK8WsPiPr1rB5bXImx0MqbiPxoouTyM80jh8 +xyxHyg1KVx1qxEEeNfK5FI6euKZViq5IFJDGZA+Occ0sik9BVaYMqZUkFecjjFIk +sQtJZT7+iEjcPSt63W1mUNIRjFc9ZXhuD5FwQSwwre/oa3raW3+xlGwWPr1FRUj1 +RtSl0GmW1jdlWCNz2Y/40yCBNQZijq0aNtKp/X/P51nXk4RJdqYBPJJHJq74a2x6 +XM4I3NJyM46f5NaQgkyZVG9DRv7hNPsW8pQP4VA7k/8A66g06Hy7dcnJbkk9yetU +9TZpr+KHnKfO2fXoK0LYqYh1x6ZqpPUmJKy45z+XaqV8AUQ89x06VeccHA6896rX +SbrZj3Ug1JRjYKsQfXrVxX+Xg+4qCVQQD0NOhJYcdTSEtGWVkIyFU/gtFJGEywbA +568c0UFmUomil/dAtk9B3q/nzBjHTqKWBVjIPU45NMPDn3pkLQY6jBwRxTIoxJIE +7HjmpW4/OmQcXC+maBdTG2FHdckFDxWpp7yyyu+eMcD/AGj3qpdLsvpAMdTWxpkQ +jsVfpn5j+NVFXZCIL6N5YhG5GeWA6laTw/c+TJLYy4Al5TI/iHb8v5VYlwblAW6q +MZ9c1mztgSleCzAKR26c1T0dwL1sDNPNOed7HafYcCr8MnlSAZwrdSfWobSLZCij +0xRLlXHHDVBojSLZGSTz29KYFDK6nncMVHbTCSMqx+739RUJvWz+5A4/jbp+VIZS +nGFOAOKbC3zZzjr0pbjvnkk9qihyZAB34oFfU0IEO05BH9f0oq1hIkXIySKKBn// +2YhGBBARAgAGBQI8ZiQyAAoJEMdGNjmy13leJSIAoIx0Ql/m4Gf4ZZeFQ1Of+zq6 +499DAKCHBzmIEtE740kuUl5HGNvCJ4QbMLQtUGhpbGlwIFIuIFppbW1lcm1hbm4g +PHByekBwaGlsemltbWVybWFubi5jb20+iEwEEBECAAwFAj6+zxoFCwkIBwMACgkQ +x0Y2ObLXeV4M5gCgnemzKjFcpG5MpeFCTjVg24ptLhsAn03rO14zwfdxKS9ZSuGL +eBG+d/eUuQMNBDpU6CcQDADMHXdXJDhK4sTw6I4TZ5dOkhNh9tvrJQ4X/faY98h8 +ebByHTh1+/bBc8SDESYrQ2DD4+jWCv2hKCYLrqmus2UPogBTAaB81qujEh76DyrO +H3SET8rzF/OkQOnX0ne2Qi0CNsEmy2henXyYCQqNfi3t5F159dSST5sYjvwqp0t8 +MvZCV7cIfwgXcqK61qlC8wXo+VMROU+28W65Szgg2gGnVqMU6Y9AVfPQB8bLQ6mU +rfdMZIZJ+AyDvWXpF9Sh01D49Vlf3HZSTz09jdvOmeFXklnN/biudE/F/Ha8g8VH +MGHOfMlm/xX5u/2RXscBqtNbno2gpXI61Brwv0YAWCvl9Ij9WE5J280gtJ3kkQc2 +azNsOA1FHQ98iLMcfFstjvbzySPAQ/ClWxiNjrtVjLhdONM0/XwXV0OjHRhs3jMh +LLUq/zzhsSlAGBGNfISnCnLWhsQDGcgHKXrKlQzZlp+r0ApQmwJG0wg9ZqRdQZ+c +fL2JSyIZJrqrol7DVelMMm8AAgIMAI1RXgrY9LqHnvhnc1oGwhB7mORU7jwxKiGM +Lqzb0KM+GVTv1xAhhaYGm41/CuhnrOW3LPpjYWbrlXQh+9WJxHvO8UUI6FqEy6TV +yv5Cn3fo4wSr2wtkbFOMKWDCscZLtikxJmsQLtuk6YRGOjgX+fliYIckIfxDMI5z +37zSCNUSweIlUAGsLzLKSMovnHVX89ICsThC0wtuQE8aZBg7DxvHqMIeg7jdCNTN +upF8EwdmpZUnKgghkKn6fXdczj4079wNWxnxuNyHQsg7IytPzmfbjJ9dGU/SzsEW +Mubn0mOF/h2O4laKQlrBYROXKkDLzo5hFG7AJsjI1q4F5MrL5q9m8Xagu+nAfhSe +52kLTr87SOSPaVCmf0QRTDXVHA7qyr3NhPABTIp6s3TRxsJ/KJmXTUIijRu1xM7q +FArdzrs9qWgn2VUfz+Yfsu6qQwsMfm6CSnOZ53/xKit+pWRqSd7pviZHJIUIFdpV +mgqYMfNwfahJIyEz17HKHp3OLVsa7ohUBBgRAgAMBQI6VOgnBRsMAAAAABIJEMdG +Njmy13leB2VHUEcAAQHlbQCg+N+fI3bzqF9+fB50J5sFHVHM7hYAn0+9AfDl5ncn +r4D7ReMDlYoIZwRRmQILBDxUyXkBEACgg6vxNPigg9FQz14CkPtR/dEq3sCjK1r4 ++2oyeoRno+pqZ6Z7ZfphgA/q5woweFAGOg17KD2WXegoQ5pXbFvP+w9j9zm3g59X +zTRSzZgScelTibPnKy6g8r8GDAY6IQraR6pxe4297/NznqvRvKpTt5g1XP5LyjVB +sEv9HAYJE1vyy10qSQRtEz3QunUzfELNC4kiYNMZOnmgaFeW4APIIhWDtrrxqW3O +fjp1K4DAhqcnayrfvYbOtqh0sxJ246kvVc3Bc9pH6wDw/yub2deuPq6BZBLBJwrt +u/20qD0nsZ9is/5j0aL1MZuVmr7xKYqeehyzJ1WdpJK52qng9natYedS+GefKDIw +1Jq7ppQNWfVduTNITFTF0JswggjQuPqKT8Td5GCywQWN/kGHbp6EdybiUXZ+9fp4 +eek0UB5M+srSwbkF4hQ0mBrqlsaoji4CuXjc0c+Zx1D0pGfqqBCmvEV1tLul3U8h +0TzR4opUA8mLKegQp5cjh/dHz7zTPDxVgSr3blJ9FxI1Z69th/+jJj3q6joo3uW/ +5y8qQCrzdSCzs+TDEWwucZtJIuIhTct8AMPY/Ayt+Pf9jXfI+xSQgz3r7Eu5o+rE +u02/cthaOc4b3KYDtNkjLKszgiext1BYOq06R+Yyh2qgsg9azzkfudvvpwhCpJ7E +OxcdaP3bxwAGKbQlRGF2aWQgTS4gU2hhdyA8ZHNoYXdAamFiYmVyd29ja3kuY29t +PokCNAQTAQIAHgUCPFTJeQIbAwYLBwoDBAIDFQMCAxYCAQIeAQIXgAAKCRDbaY1x +mSQlYH7aD/wMq9ksbvAf9drjVP2u4rjZhLkHyc1zCp7rMXc5CdNgDNVyhl7+co/q +MeQBwk8SYEVedrZZ5Q7qjygjkKWp3qrLlw5PSydwCHaf5mlVg5E+5gt+RTkOi6FX +dE/5c0IrIB+MNI3jt3IeOqEhITWcnjDk4gIxm4z43tvXvf/fY33ohrQknApN9uYI +SoElzYGgnEZqX6P3p/8FB2+27A3t/Eshr6lLvVNEMgOlBY8te9TFvMJTMeSJXIQV +pvbz/LMF8uEboWVzRC77y7RcD8p+JP9V97qZGsiOYB+2MPGEvAhEPHxQZAbaBF+e +BFLzev+xmI36fHlFnAFiWikp0tYVLROgBhVGJUOJlDK+olfpxUqF+N8MfjeS01aH +Ly+Y6rkzC26AC/9j+Adka9mBXEiiA1vQcBfO4U45QhgDAl00yUW1gV4oNGZ9Yqsl +OhS/VHB61CjWwjnV3Jwkhscxux3rjj6TAwn5QmoO9kr3CqH1rzQXxTVruCJuwyuI +6aNeywINoubgDhqhOCPfqyzgdxfp5UAhy54ge9dqjfgHI2Q3WxxhD3mCdYgN89GZ +NpuH2lJkJZrRl7BimjqDeTlKYscZ1anrRgRpSoFDdUcMncySzW6cB1WSImj1aNWp +q58FxoJWcTy6lNesINeRjZ/r1eJBeN55P8+7DKGIsGkpftsqgXAqVbkCDQQ8VMsE +EAgA7lKuNHz6iYb+2pAZbxrjp5AHV86pbtVJQBWpGWkGLERGb6w2hYTL8YXr7Jgt +eBmy1a/+l5ZYjnZFQ8603eZRC1g+/krruWmfiJxE/HtHVcVSDUxXNJiE67DpSdGP +f8icIx3c91Xkui9ifS3VMSj1ezWLm5/OYF1utTQ5QiwrvzTuaCs8jWDUzxI77Fcz +QYQELuDmHevde4Ke66MeWCJabs9OQ6i61vurJrj1WQQ9pvXOzcbdoQFtAF/vGK82 +rnr0p5cDyes3S5lCKC4nIhvokHotCf63YUU6afG9OLp/ASlcp2h21vmtDp7xSg6D +7Ivn5cHtHnBvChG6vjQ9IO5gdwADBQgAnNF7z5VcV00LbYQxN1vX77iKwJ1aEZVS +YMrJnvthtJPM5alAsOQRRe85pgZsBfd2xgKbDZFsQaPei+n59nMPTxl68YsrYOWa +Be9IRnEKBYIHSVwDAGsEdxyOKgphNO7cQKcpRWdeqi9FQ11cWVLZrSqChmT9Z6uY +GLDabKwAhYl6TrEQ2J9OzM586LARZHb8m2MOcGrla+XZZannjEVfaei5on8IuhOL +alx/vx74C1qLi9B1fI/JyCsJlMQujkDrpz80hwIyavutLB9TdQZn8TuNqL/m7cpU +1YMbNIa/1Ow2Cio7zrhr/FvTX4KgMaGq6ukx7qWDDbME96BF57IMtIkCIgQYAQIA +DAUCPFTLBAUJEswDAAAKCRDbaY1xmSQlYPGsD/40gsxyQv4M8BFfPgnPEOYlSEBw +pibr+XRdq7q98n3F9ZlXjJHq74RhX6aotL10wpeMb6fcFKhmaMu8Nhx4PUP9+h11 +I7EwmMeLn2prG/sSbsgCY4tsEW08NbDzcXdj6+KvekpE6lYmOa4ORQTEODx81d9R +8DxcqUCYHYn+iYMbEDnBZmHgPc5hkGvBNj2F+dGs4n0iBvxFSBoTSzHb9XksG3/c +q8DdW59McJw1/nTyN2kLIvGjNqSeV+2P2oeh5NRJAHs9X5W+Zar+sqvlHDa1e0jq +2SrMhWdOD1qgTX3BzFyuhWW3IJLdcyFEp6NsC/L2eJdkWwclT1xhEvm8LEsB21nd +E2UNpIjOUcdFvEnYa84Di8ZpIvEvngG6q9tm5K14DXZYQczsN+rrOXgTYfxbEuCz +pFCg1DZaRQmWkXcywzo7F2YUgw1nFe9TlIrLJgXZcjg+ho3UNmquVr+qNV1IzYCk +E6I70J/Q3fuXOfVdM2V0JQTaWfBOUFowwVNyzI5XSl8TTwslsGN8roEAGBR33Jwh +By6TldhErnR1pvIOVt0kkGXbEqIIYONvfsdd2LIFZUfyegh8oFCJNDmKObKnuVyZ +H53Q3bgTn06D5TdBaCK9usVqUe+JZ1K4VLy+20kSiBqaLkel3417o+bqdpL3Uu8g +Xy1bsOhyo9m79ug8orkBogQ8VMvbEQQA9YjnqxRaPgKrbhTQqrzGMYBuP4QlbsQe +EDA3y94jlPK++edfyUGUTnquXHDKmPnLwsqszYZCsC35nVP8FOsg0eATYYAj5A9u +PDUXGQkW1eNQFGoh5p4SxBQZKlVJCAJyVgMxXDtUwDbjQ9CkOONrv1YlajDz9h9y +HfFUjQrC47sAoOX8LBxMJVdAqGMOQGcI2lTWTfq1BACabalqZ3571+ePoAEsqSxZ +elhHA/Se6oxlfxWNQilDGsgUSm53l7yeJn+8qZuiRm49wMlPZnzLA5isMAh0UyoT +SnPs8lnZDLbo4/s4H2Jz0+MahJSYtNtSKTNhuJv7Fh/kQGVltAaniUQeecoJK7Yx +hKbnvsXKzg7YEL2DLKDA4AP/RDeDRhK7ehXbkeONeJsOPjvjdATxSa7Io+GIUFB1 +CSLgaHfC43b8j7S5pEiZ8MOW+kwnP35G89h1K89nFpC47Xt8y/5DH4Z/tw3SdaEI +r8TSL3u/UOK4gZEc5uVhCGBAX/BdIYFWdO2UUjEaO3ox38lgH0HfNscqgN5zCEEc +6lmJAiIEGAECAAwFAjxUy9sFCRLMAwAACgkQ22mNcZkkJWAthQ//QCSN1sFaeqFQ +Eki7fg6E0n+t7mO+V1llNymp7G8Pq3iSI2d99oijVk2BQnrbhdLy+wjl9Lyyzfvv +aQ04QwAUvJNRgIaOpxkYb3z2tc31ho9eOYsQRmKxVzGWw1ii1OEnMBylsAaG58Gp +FI/5MTfucIlJBvXoESkHSoiyov2Pd1c3hJ/6OuFYbn5dvYplBi2K3pAq12OCmWti +cFvPTBpVlvTED0h+I133oO1e1Rx999u1/PQgLem5qfuz3wLv9r8qkXgy1AqdOEBN +svXSo09yWaDTKaZWb6k7viOq6k2aDOi4mr8qgrf8obs6fpOfg6WQw+DRL/T9KUHF +0EUSPVEMkbMc1V2iHURqXBGnIsa5JAi1eV1cMrp9T25DXWHlEfXRnPPjzTSJyJh2 +FmL9NnQrsmHf8f7DiR7uzCgA8+SZqRmr6o2j0FAPUrV4EmMYB7wTYPwPT7EXXmYs +8m0ovamXwGbIwT2Z/EGhOc3UdAQF232o156m097tib5HMbTT+8AcjX3TaeXDJpjI +35WybfJ8F2LEWmJsQwPC9MMCfy7SlW8BUqTBaelPvSYoKdLT6FOxtnoAVYn10WRI +F7LESySJqENspSpv3ACJ/q1jZN6cXYKFlvKLR5Be/MWtnZ2AXqwHmR/XYGtXI6FR +mNd6xrb+mP2QwkihMezVT+y2Q/EogXSJAmoEGAECAAwFCRLMAwAFAkQS4BkAUkcg +BBkRAgAGBQJEEuACAAoJEOJmXIdJ4cvJKsUAn3R2myTGfaAyxiDwL9l3ObofNnX9 +AJ46M4YTuhT9ETVc15IOaHY5VCLcUQkQ22mNcZkkJWCOtg//RVzC6tHMnmZXXA6j +slgca2yf/q0zJIULR9azhcraU3yy8OzjVorX1i5Xh5Rr3SmZkHiNUMrOK0jCzyM9 +ykBa58WOwwN1sZoNUQpUtmYja9kj/y444Atf0iIFW9TT4O31j25qEjz7cLZtmv+T +nzcSIaZekJrIZ/8D74eDqNrfy/WaAi0JK2iMiw4dqwLtIc2W7UTtXfSgiAtNrkp4 +smrO6AUI2Xas7D+3zZiMlIv//W3ZSTF0vHtyBdmvcEPrs6DdjhsM+L7QHLnxD7HD +86cvVh+9SzHelc5erhSWbwKMcZKykQ3uHhU9XCt60MYdbc8HHW92g0e9nEipZ7iS +23uDmzoKvfihtho2+j1w5uKM/S6N/fditlWJ9qHvLHVPLNKPp4DEHo4ns56LCY1c +RUX7N4TOWu2iVSdtzg8NFvhfnKyWkUTCYFuU64Jiq9XcJLMAn2AY02RzQcF8Lwbg +zdyINK9pC0y0lH9ZrN6QyGinxILPVtwLsWO17JpDvKQf4+rmR9nHQSsvGJ/FjCDy +dMx5HaT+TfC4KRR8BBgTDgZkq6cllbeC1qgCz3LXgai9pIlvT9httrVcpOL0QHnK +M5jd7R8JZ1dt5qlltuWsC8Dw52kEGiBn095qmY1FFd02BxL7y7sxHp81m31yTErh +o+HQlcXTIscl65wt2LwowPG0n2iZAQ0EQbPS8gEIAMtvZJvlBs6FEjN86De70Xff +yArVdlYkbwnBc/wNIZtASh/T5ihP/tsD7eHWWOHcsbSbwlQR2iWvEvP/wyC67ZMD +ZRCIzBFpEKFJW8GCQJFiSv3v6QKU2CaL48u5Q3XPi2ymp0TvrWdFW9SXbHhe8tMn +bWFTl5cYawL6oU/gR97wHmQf4V7EB+cU8/Oi7caNsNti/gJiLSnKFPGZq7HInJCt +D8xBS3REVGQvyoLNYJHYGYfeMzczRa3SgqfwLz59Yi1SHlT1/O/8r0Z479JXz7N0 +vgyt2oOy2Cpc2zbsf5Z4iBteVQYizSY40TpO0pnk9cbnMUzVvPW8N0Bhtjh5RYMA +EQEAAbQlUEdQIEdsb2JhbCBEaXJlY3RvcnkgVmVyaWZpY2F0aW9uIEtleYkBVgQQ +AQIAQAUCQlG0cAcLCQgHAwIKAhkBGRhsZGFwOi8va2V5c2VydmVyLnBncC5jb20F +GwMAAAADFgIBBR4BAAAABBUIAgoACgkQlxC4m8pXrXz35ggAnVHdAh2KqrvwSnPo +s73YdlVbeF9Lcbxs4oYPDCk6AHiDpjr2nxu48i1BiLea7aTEEwwAkcIa/3lCLP02 +NjGXq5gRnWpW/d0xtsaDDj8yYWusWGhEJsUlrq5Cz2KjwxNQHXRhHXEDR8vq9uzw +5EjCB0u69vlwNmo8+fa17YMNVdXaXsmXJlJciVHazdvGoscTzZOuKDHdaJmY8nJc +Cydk4qsFOiGOcFm5UOKPnzdBh31NKglqw/xh+1nTA2z5orsY4jVFIB6sWqutIcVQ +Yt/J78diAKFemkEOQe0kU5JZrY34E8pp4BmS6mfPyr8NtHFfMOAE4m8acFeaZK1X +6+uW59HMnv8AAA1ZARAAAQEAAAAAAAAAAAAAAAD/2P/gABBKRklGAAEBAAABAAEA +AP/bAEMACgcHCAcGCggICAsKCgsOGBAODQ0OHRUWERgjHyUkIh8iISYrNy8mKTQp +ISIwQTE0OTs+Pj4lLkRJQzxINz0+O//bAEMBCgsLDg0OHBAQHDsoIig7Ozs7Ozs7 +Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7O//AABEI +AJAAeAMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/ +xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHB +FVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2Rl +ZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6 +wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEB +AQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQID +EQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkq +NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqS +k5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl +5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/APZqKrX99BptnJd3L7YoxkmuGvvi +zZRkrZWbykdGbgVpClOp8KJlOMdz0KivILj4p6xM2IYYoV/Op7PxX4mv18xJSVBz +leP61v8AVKiV5WRHtovY9YorzD/hMdat/vygsOoIqeD4l3URAubVJB3K8Gk8JVWy +uHtYnpFFc5oXjXTtcnFsivFORna3+NdEDmueUXF2kjRNPVC0UUVIwooooAKKKKAC +iiigDmPiG5XwjdYPXAP614dX0D4l0+HVNKNncFxHK3JQgEYBPGQfSuCfwBpCnia9 +/GVP/iK9DC4iFKDUjnq05Sd0eeL94V6X4N1HTRpqxzzLE6DnPfiq0HgXQHdkku75 +GHT51/8AiKst4H0aE4W/vRj/AGkP/slXWr0asbNsmFOcHcx9euLee/le1x5WTgjo +ea5+Z+TXayeFNMQbf7QvMdeqf/EUz/hCtLkUN9qvSD38xP8A4irhiqUUkmJ0pt3O +f8Iz+V4ihcsFA6knHpXr0ev6QkeJNUtAw6jzlyP1rzy48HaZaW7TxvcyOrKNsrKV +OWA6BR61u6TpkVqRIqlcrj5Rx+NcWJqRqT5om1OLirM6mPX9GmbbHqtmzennrn+d +X1ZXUMjBlPQg5BrnjAjqcbWHtzWFqGmySTma1le1dchXtXMZx9R1/Guexpc9Aorh +YPFOq6Y6pdj7ZF0zIAr/AIMOPzH411Ola7Yawh+zSkSKMvC4w6/h6e4yKLBc0aKK +KQwooooApalykQ9XP/oLVjyxYrZ1H7kR/wBv/wBlIqgyhhQMwJhcxu6xoQCScget +OF7cxho3gLg9xkdsdutLdX0yX9xAoQLCyqPlznKK2T/31UJvJT12f98iiwiQzyAb +I1IyB1HsBVqGFktowwwQKzzdSEEfKP8AgIq3b3BEcLt92WJHYDoCygnH50WAS9H/ +ABL5s+sf/o1KsW88giwiqAvdjUWojFi5B4Zo/wAfnU1pWq7rXaCFyOuKEBE1yduT +GwPQ7KJQhGOM46VbMC+UF4DAdcVmTEQyMsKCZ+h5wFpiM2/hmcsiIrA9FZeDXOSN +LpV0jvM0LZzE65BjP+9XVTabn5zJJuzncH5qneQhovLbkAdG+b+dUhM3/DPipdUI +sb3al6B8rDhZgO49D6j8R6Dpa8ZuQ0Tq0ZMbxkFWTgqR0Ir0jwn4hGvacfNIF5b4 +WdR39GHsf5g0SjbUEzeoooqCipqA/cxn0lX9Tj+tUK1LqLzoGTODwQfQg5B/OuT8 +Sa1ceHdOe8ktIpwHCKquUySfoaAKl4P+Jvf/APXVP/RUdQkVBpWp/wBuxXGpfZ/s +/nTY8vfv27UVeuBnpnpVoiqER1biH+h2v/XtF/6AtVSKyLfxbcTRrBbaMZPs6CEy +Nc4Vio25+77dM0mM37yUiwCHp5yAfqf6VrWcuIV5rkGu9X1Mxoba3tY0fdtDFyxx +jJPtk+nWtaGW9tlCzOhQ8BgpBzRYRszagm4wJl5Dxhe1SRQJBEBwTUFpDFHECMHP +OfX3qSSXjrTSFciuG4NY143WtC4k4NZN2/WrRLMa96motC1g6Dr0F6WIhJ8uceqH +qfw4P4U+7PWsi6GVbNVa4j3kHIyKKwvBd+2oeFbN5G3Swr5MnsV4598YP40Vgam9 +XnvxamC6bp9uD/rJyzD6DivQq82+LikLpkn8Jdh+OKqO4nsQeCUB0cAjI+0N/Stq +6EUV05Kjy1PIrgfDRZfEun7XYK0hyMnB+U9q72/G9rmqejEtUQyXFrKu2FAreuSe +KwNBVAhyo4dv/QjWH4w1EpEtpbJK5Rw00kf/ACz46HFGh+JrFLVYwjNKi8qpAB/E +8ikgZ6BC6DoBSX91aCExXEwTcueOoHr7c1zOkand32pFmncooLGMN8voAB+NdDvz +w2Rx3FOxNy1p1xA9kgtpxNGoxuByfxqSSXjrWJcWKSXcVzHLLC8ZBPksF3Y9eKq3 ++o6z9tkitLeERZBWWTGMf5/GgDYnl4NZlzJ1pWuZSkQkjBZgfMaM/Khx784NU55c +1SEU7lutZdzMkEUk7jcI13bfU9hV2d81n3EaTxvDJ9yQbSfT0P51Qju/g5ePc+H9 +QSRtzLelyf8AeVf8KKg+C8Lw6bqyuOVuVU/ULRWD3NVselVw3xYtDN4ZhugOba4U +n6EY/wAK7ms/XdNXWNDvNPb/AJbxFV9m7frihaMGeM+GW3eIdOP/AE0b/wBAau/k ++d7n61514X3xeJbOCUFZIpXVgexCsDXocJ3y3A/2hVy3FE4RrOWw1KWK4BVmdnRh +0dSeoqeewtL6ER3EKuobcCPlIOMZBFaPjCdI5LK2APmbjIT6LjH8z+lZ0MhKiqjq +iXozJn0q/wBPDTW8wuoYxu2kFZQP5HFbnhbUftdjK6XHmoJOAG3beP61IjHjnmqk +ulIblbm0mlspsbXa2wvmL6EevvRYR0T3AjRmkYIqjcxY4AFZsmv6WJGX7Upx/EEJ +U/Q965nW3n0+KOyjup3t5MvslfcQQfXrjvisNpn67jQI9DlvLfyvN+0weXjO/wAw +YxVadyADkEMMgg5BHsa8/eVvb64q7pWtS2MojkLvbNkNGD09xnoaYHSStmqc7fIa +LbUIL9ZPKWRHjGSGIORnGcio7hZJCkMSl5JWCoo6kngCncD1L4XW3l+GZrraR9su +3lGfQAL/ADU0V0miaamj6LZ6cmD9niCsR3b+I/icmisHuaov0UUUhnmnifw8dN8e +2Gr26/6Peu3mY/hkCN/Mc/nV3T333Mw9XFbvi84tLU+k4/8AQTXN6M+6+ceriq6C +MDxbeQXmsxW0ChmtQVkkHcnHy/hj9aggj4FN/sqawv5ba6XEqsTnswJ4YHvWjDb9 +OK0WiIe4xIjUkhS3heeXOyNSzY64FXI7f2pbvTvtdlNbklBKhTco5XI60XFY881S ++m1OcSSIqKowiKOFH9TVAxH0rYl0y4s7h7W6C+anO5ejr2YU02ftSuFjGaEntTRb +knpWz9jPcU+OwLNhVyadxWKmlKbSdn2btyFcEkda9C+H+hR6prH9sPGwt7I4QNgh +pcdvXbnP1IrB0Pw5c63qIsLT5duDcT4ysC/1Y9h/SvZtO0+20rT4bGzj8uCFdqjv +7k+pJ5JqJMuKLVFFFQWFFFFAHOeMj/oVr/18Afoa57Tk8jW0j/vOK7PWdOGo2qru +2vG4dDjIyPWuTuoL6G9842QLg8MjjH68imnoBB42U2L2uqlfMhX9zKijLLnkMPbg +5qvpz2WoRiS0nR89s8irFxDqWoMguCFjjOVjTpn1J7msbU/DTiT7RaBrebruj4z+ +FNMTR0sdm47Zqwtqf7tcRDq/ifTDtbFwo/vjmr8XjvU4+JtLyfY07iNPXPDa6lGr +xnyriP8A1coXOPYjuK506FfwP5VwiOcZDxghSPx71oS+PdQYYi0rn3NZeoa14k1W +UCAC2jxjhcn3NIB82nQWcRlvZ0hQcncafp2nz6xIotEazsj965kX53H+wp/mf1qP +SvDVxJdC5vi9xIDkGU7sfSu1tLOQYGDRcLGzoNrZaVYpZ2MQjjBye7Ox6sT3NbKn +IzWTZ27LjNaqDC1JQ+iiigAooooAQjNRPbRueVFTUUAVjZRdlFQvpsT/AMNX6KAM +eTQ4H6oPyqBvDdqf+WS/lW/RQBz48NWoP+qX8qmTQbdOiD8q2qKAM1NKiTooqwln +GnQVaooAYsYXoKdS0UAFFFFAH//ZiQFOBBABAgA4BQJCUbRwBwsJCAcDAgoZGGxk +YXA6Ly9rZXlzZXJ2ZXIucGdwLmNvbQUbAwAAAAMWAgEFHgEAAAAACgkQlxC4m8pX +rXxIEgf+P5EZwy4eZWhmrj5duYK6edt+3hPRNrijqbE2RzrCTk/0+lwT2LHO2NXK +wya/aLhjvjp0Jj0HW1+FBbXRLf0fOtgeHcjhrbBv3NCeJkJ/VedsJ7V5Gyw2FOkt +VdedcoSxz0TAPky2I8gKW5khcHTxnHa4lJn7+L1OpIzkRS4mT6VeqBcZSJNpJc3r +cj/gGdsXMLDxJpJPt3ueiTjlQL0j/6BwpU76hgROCuxTsAvq6TXpgP0ml9hkcQWa +lihL6pDe0t88IbeBpL92MFlZaQ23nPt7qxtGSjj1cSPcRSHfceCOs6Uvy4k1uGVn +k14gtzEeoZMeOL7nAwQMGN81P8LqbZiOBEO3+scBBADQmRl6K1zJAyqTbEZ3/mYa +hzj5g3BCjw5KZXAi9jxQAje0GiuEXqFr2eJqplTi92V1OdcxTSPWg9yQCE6BE9o6 +9oRmFhRMXQX/XmmIAXl2RlDp2yZdVSQ81gxlOmRzacD4gAIGI6bKAYGQsW5e8dFb +WLpI3PbyJEf9RlxguL/aIQAggVZQmbQmV2VybmVyIEtvY2ggKGRpc3Qgc2lnKSA8 +ZGQ5am5AZ251Lm9yZz6IvAQTAQIAJgUCQ7f6yAIbAwUJBaOagAYLCQgHAwIEFQII +AwQWAgMBAh4BAheAAAoJEFO2INAc4MYweaMEAIdDDtJLkO4TOgCo/GCuG0RmqRwZ +niJ4mnq/WOr8F4BK3w1HIuwVEE8V6BRU4Chx8wc9/W83krckIE5uaZRmjhCXCWsi +K9Ow2ngbXAv3TKFVCbMMmyjBbT+31M9OT0Sowob8a1s4Xv2J+gQJjxfumMUKNlvf +K86tEx0ucCiY15h8 +=yJFz +-----END PGP PUBLIC KEY BLOCK----- |