Network Working Group                                        Jon Callas
Category: INTERNET-DRAFT                             Network Associates
draft-ietf-openpgp-formats-01.txt                      Lutz Donnerhacke
draft-ietf-openpgp-formats-02.txt
Expires Aug Oct 1998                                       Lutz Donnerhacke
April 1997                           IN-Root-CA Individual Network e.V.
March 1997

                                                             Hal Finney
                                                     Network Associates

                                                          Rodney Thayer
                                                       Sable Technology

                  OP Formats -

                         OpenPGP Message Format
                   draft-ietf-openpgp-formats-01.txt
                    draft-ietf-openpgp-formats-02.txt

   Copyright 1998 by The Internet Society. All Rights Reserved.

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet- Drafts Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

Abstract

   This document is maintained in order to publish all necessary
   information needed to develop interoperable applications based on
   the
OP OpenPGP format. It is not a step-by-step cookbook for writing an
application, it
   application. It describes only the format and methods needed to
   read, check, generate and write conforming packets crossing any
   network. It does not deal with storing storage and implementation questions albeit it is questions.
   It does, however, discuss implementation issues necessary to avoid
   security flaws.

   Open-PGP software uses a combination of strong public-key and
conventional
   symmetric cryptography to provide security services for electronic
   communications and data storage.  These services include
   confidentiality, key management, authentication and digital
   signatures. This document specifies the message formats used in OP.
   OpenPGP.

Table of Contents

            Status of this Memo                                       1
            Abstract                                                  1
            Table of Contents                                         2
   1.       Introduction
1.1                                              5
   1.1.     Terms                                                     5
   2.       General functions
2.1                                         5
   2.1.     Confidentiality via Encryption
2.2                            5
   2.2.     Authentication via Digital signature
2.3                      6
   2.3.     Compression
2.4                                               7
   2.4.     Conversion to Radix-64                                    7
   3.       Data Element Formats
3.1                                      7
   3.1.     Scalar numbers
3.2                                            7
   3.2.     Multi-Precision Integers
3.3                                  7
   3.3.     Key IDs
3.4                                                   8
   3.4.     Text
3.5                                                      8
   3.5.     Time fields
3.6                                               8
   3.6.     String-to-key (S2K) specifiers
3.6.1                            8
   3.6.1.   String-to-key (S2k) specifier types
3.6.1.1                       8
   3.6.1.1. Simple S2K
3.6.1.2                                                8
   3.6.1.2. Salted S2K
3.6.1.3                                                9
   3.6.1.3. Iterated and Salted S2K
3.6.2                                   9
   3.6.2.   String-to-key usage
3.6.2.1                                      10
   3.6.2.1. Secret key encryption
3.6.2.2 Conventional                                    10
   3.6.2.2. Symmetric-key message encryption
3.6.3 String-to-key algorithms
3.6.3.1 Simple S2K algorithm
3.6.3.2 Salted S2K algorithm
3.6.3.3 Iterated-Salted S2K algorithm                         11
   4.       Packet Syntax
4.1                                            11
   4.1.     Overview
4.2                                                 11
   4.2.     Packet Headers
4.3                                           11
   4.2.1.   Old-Format Packet Lengths                                12
   4.2.2.   New-Format Packet Lengths                                12
   4.2.2.1. One-Octet Lengths                                        13
   4.2.2.2. Two-Octet Lengths                                        13
   4.2.2.3. Five-Octet Lengths                                       13
   4.2.2.4. Partial Body Lengths                                     13
   4.2.3.   Packet Length Examples                                   13
   4.3.     Packet Tags                                              14
   5.       Packet Types
5.1                                             14
   5.1.     Public-Key Encrypted Session Key Packets (Tag 1)
5.2         14
   5.2.     Signature Packet (Tag 2)
5.2.1                                 16
   5.2.1.   Signature Types                                          16
   5.2.2.   Version 3 Signature Packet Format
5.2.2                        18
   5.2.3.   Version 4 Signature Packet Format
5.2.2.1                        19
   5.2.3.1. Signature Subpacket Specification
5.2.2.2                        20
   5.2.3.2. Signature Subpacket Types
5.2.3                                21
   5.2.3.3. Signature Types
5.2.4 creation time                                  22
   5.2.3.4. Issuer                                                   22
   5.2.3.5. Key expiration time                                      22
   5.2.3.6. Preferred symmetric algorithms                           22
   5.2.3.7. Preferred hash algorithms                                23
   5.2.3.8. Preferred compression algorithms                         23
   5.2.3.9. Signature expiration time                                23
   5.2.3.10.Exportable                                               23
   5.2.3.11.Revocable                                                23
   5.2.3.12.Trust signature                                          24
   5.2.3.13.Regular expression                                       24
   5.2.3.14.Revocation key                                           24
   5.2.3.15.Notation Data                                            25
   5.2.3.16.Key server preferences                                   25
   5.2.3.17.Preferred key server                                     25
   5.2.3.18.Primary user id                                          26
   5.2.3.19.Policy URL                                               26
   5.2.3.20.Key Flags                                                26
   5.2.3.21.Signer's User ID                                         27
   5.2.4.   Computing Signatures
5.3                                     27
   5.3.     Symmetric-Key Encrypted Session-Key Packets (Tag 3)
5.4      28
   5.4.     One-Pass Signature Packets (Tag 4)
5.5                       29
   5.5.     Key Material Packet
5.5.1                                      29
   5.5.1.   Key Packet Variants
5.5.1.1                                      29
   5.5.1.1. Public Key Packet (Tag 6)
5.5.1.2                                29
   5.5.1.2. Public Subkey Packet (Tag 14)
5.5.1.3                            30
   5.5.1.3. Secret Key Packet (Tag 5)
5.5.1.4                                30
   5.5.1.4. Secret Subkey Packet (Tag 7)
5.5.2                             30
   5.5.2.   Public Key Packet Formats
5.5.3                                30
   5.5.3.   Secret Key Packet Formats

5.6                                32
   5.6.     Compressed Data Packet (Tag 8)
5.7                           33
   5.7.     Symmetrically Encrypted Data Packet (Tag 9)
5.8              34
   5.8.     Marker Packet (Obsolete Literal Packet) (Tag 10)
5.9         34
   5.9.     Literal Data Packet (Tag 11)
5.10                             35
   5.10.    Trust Packet (Tag 12)
5.11                                    35
   5.11.    User ID Packet (Tag 13)                                  36
   6.       Radix-64 Conversions
6.1                                     36
   6.1.     An Implementation of the CRC-24 in "C"
6.2                   36
   6.2.     Forming ASCII Armor
6.3                                      37
   6.3.     Encoding Binary in Radix-64
6.4                              39
   6.4.     Decoding Radix-64
6.5                                        40
   6.5.     Examples of Radix-64
6.6                                     40
   6.6.     Example of an ASCII Armored Message                      41
   7.       Cleartext signature framework                            41
   7.1.     Dash-Escaped Text                                        42
   8.       Regular expressions Expressions                                      42
   9.       Constants
9.1                                                43
   9.1.     Public Key Algorithms
9.2                                    43
   9.2.     Symmetric Key Algorithms
9.3                                 43
   9.3.     Compression Algorithms
9.4                                   44
   9.4.     Hash Algorithms                                          44
   10.      Packet Composition
10.1                                       44
   10.1.    Transferable Public Keys
10.2 OP                                 44
   10.2.    OpenPGP Messages                                         45
   11.      Enhanced Key Formats
11.1                                     46
   11.1.    Key Structures
11.2 V4                                           46
   11.2.    Key IDs and Fingerprints                                 47
   12.      Notes on Algorithms                                      48
   12.1.    Symmetric Algorithm Preferences                          48
   12.2.    Other Algorithm Preferences                              48
   12.2.1.  Compression Preferences                                  49
   12.2.2.  Hash Algorithm Preferences                               49
   12.3.    Plaintext                                                49
   12.4.    RSA                                                      49
   12.5.    Elgamal                                                  49
   12.6.    DSA                                                      50
   12.7.    OpenPGP CFB mode                                         50
   13.      Security Considerations
13.                                  51
   14.      Authors and Working Group Chair
14.  References                          52
   15.      References                                               53
   16.      Full Copyright Statement                                 54

1. Introduction

   This document provides information on the message-exchange packet
   formats used by OP OpenPGP to provide encryption, decryption, signing,
   key management and functions. It builds on the foundation provided
   in RFC 1991 "PGP Message Exchange Formats."

1.1

1.1. Terms

OP

     * OpenPGP - OpenPGP. This is a definition for security software that uses
       PGP 5.x as a basis.

     * PGP - Pretty Good Privacy. PGP is a family of software systems
       developed by Philip R. Zimmermann from which OP OpenPGP is based.

     * PGP 2.6.x - This version of PGP has many variants, hence the
       term PGP 2.6.x. It used only RSA RSA, MD5, and IDEA for its cryptography.
       cryptographic transforms.

     * PGP 5.x - This version of PGP is formerly known as "PGP 3" in
       the community and also in the predecessor of this document,
       RFC1991. It has new formats and corrects a number of problems in
       the PGP 2.6.x. 2.6.x design. It is referred to here as PGP 5.x because
       that software was the first release of the "PGP 3" code base.

   "PGP", "Pretty Good", and "Pretty Good Privacy" are trademarks of
   Network Associates, Inc.

2. General functions

OP

   OpenPGP provides data integrity services for messages and data files
   by using these core technologies:

      -digital signature
      -encryption
      -compression
      -radix-64

     - digital signatures

     - encryption

     - compression

     - radix-64 conversion

   In addition, OP OpenPGP provides key management and certificate services.

2.1 Confidentiality via Encryption

OP offers two encryption options to
   services, but many of these are beyond the scope of this document.

2.1. Confidentiality via Encryption

   OpenPGP uses two encryption methods to provide confidentiality:
conventional (symmetric-key)
   symmetric-key encryption and public key encryption. With public-key
   encryption, the message object is actually encrypted using a
conventional symmetric encryption
   algorithm.  In this mode, each conventional  Each symmetric key is used only once.  That is, a A new key "session
   key" is generated as a random number for each message. Since it is
   used only once, the "session key" session key is bound to the message and
   transmitted with it.  To protect the key, it is encrypted with the
   receiver's public key. The sequence is as follows:

   1.  The sender creates a message.

   2.  The sending OP OpenPGP generates a random number to be used as a
       session key for this message only.

   3.  The session key is encrypted using each recipient's public key.
       These "encrypted session keys" start the message.

   4.  The sending OP OpenPGP encrypts the message using the session key,
       which forms the remainder of the message. Note that the message
       is also usually compressed.

   5.  The receiving OP OpenPGP decrypts the session key using the
       recipient's private key.

   6.  The receiving OP OpenPGP decrypts the message using the session
       key. If the message was compressed, it will be decompressed.

   With symmetric-key encryption, an object may encrypted with a
   symmetric key derived from a passphrase (or other shared secret), or
   a two-stage mechanism similar to the public-key method aboved can be
   used where a session key is itself encrypted with a symmetric
   algorithm keyed from a shared secret.

   Both digital signature and confidentiality services may be applied
   to the same message. First, a signature is generated for the message
   and attached to the message. Then, the message plus signature is
   encrypted using a conventional symmetric session key. Finally, the session key is
   encrypted using public-key encryption and prepended to the encrypted
   block.

2.2

2.2. Authentication via Digital signature

   The digital signature uses a hash code or message digest algorithm,
   and a public-key signature algorithm. The sequence is as follows:

   1.  The sender creates a message.

   2.  The sending software generates a hash code of the message message.

   3.  The sending software generates a signature from the hash code
       using the sender's private key.

   4.  The binary signature is attached to the message.

   5.  The receiving software keeps a copy of the message signature.

   6.  The receiving software generates a new hash code for the
       received message and verifies it using the message's signature.
       If the verification is successful, the message is accepted as
       authentic.

2.3

2.3. Compression

OP

   OpenPGP implementations MAY compress the message after applying the
   signature but before encryption.

2.4

2.4. Conversion to Radix-64

OP's

   OpenPGP's underlying native representation for encrypted messages,
   signature certificates, and keys is a stream of arbitrary octets.
   Some systems only permit the use of blocks consisting of seven-bit,
   printable text. For transporting OP's OpenPGP's native raw binary octets
   through channels that are not safe to raw binary data, a printable
   encoding of these binary octets is needed.  OP  OpenPGP provides the
   service of converting the raw 8-bit binary octet stream to a stream
   of printable ASCII characters, called Radix-64 encoding or ASCII
   Armor.

   Implementations SHOULD provide Radix-64 conversions.

   Note that many applications, particularly messaging applications,
   will want more advanced features as described in the OpenPGP-MIME
   document, RFC2015. An application that implements OP OpenPGP for
   messaging SHOULD also implement OpenPGP-MIME.

3. Data Element Formats

   This section describes the data elements used by OP.

3.1 OpenPGP.

3.1. Scalar numbers

   Scalar numbers are unsigned, and are always stored in big-endian
   format. Using n[k] to refer to the kth octet being interpreted, the
   value of a two-octet scalar is ((n[0] << 8) + n[1]). The value of a
   four-octet scalar is ((n[0] << 24) + (n[1] << 16) + (n[2] << 8) +
   n[3]).

3.2

3.2. Multi-Precision Integers

   Multi-Precision Integers (also called MPIs) are unsigned integers
   used to hold large integers such as the ones used in cryptographic
   calculations.

   An MPI consists of two pieces: a two-octet scalar that is the length
   of the MPI in bits followed by a string of octets that contain the
   actual integer.

   These octets form a big-endian number; a big-endian number can be
   made into an MPI by prefixing it with the appropriate length.

   Examples:

   (all numbers are in hexadecimal)

   The string of octets [00 01 01] forms an MPI with the value 1. The
   string [00 09 01 FF] forms an MPI with the value of 511.

   Additional rules:

   The size of an MPI is ((MPI.length + 7) / 8) + 2. 2 octets.

   The length field of an MPI describes the length starting from its
   most significant non-zero bit. Thus, the MPI [00 02 01] is not
   formed correctly. It should be [00 01 01].

3.3

3.3. Key IDs

   A Key ID is an eight-octet number scalar that identifies a key.
   Implementations SHOULD NOT assume that Key IDs are unique. The
   section, "Enhanced Key Formats" below describes how Key IDs are
   formed.

3.4

3.4. Text

   The default character set for text is the UTF-8 [RFC2044] encoding
   of Unicode [ISO10646].

3.5

3.5. Time fields

   A time field is an unsigned four-octet number containing the number
   of seconds elapsed since midnight, 1 January 1970 UTC.

3.6

3.6. String-to-key (S2K) specifiers

   String-to-key (S2K) specifiers are used to convert passphrase
   strings into conventional symmetric-key encryption/decryption keys.  They are
   used in two places, currently: to encrypt the secret part of private
   keys in the private keyring, and to convert passphrases to
   encryption keys for
conventionally symmetrically encrypted messages.

3.6.1

3.6.1. String-to-key (S2k) specifier types

   There are three types of S2K specifiers currently supported, as
   follows:

3.6.1.1

3.6.1.1. Simple S2K

   This directly hashes the string to produce the key data.  See below
   for how this hashing is done.

       Octet 0:        0x00
       Octet 1:        hash algorithm

3.6.1.2 Salted S2K

This includes a "salt" value in the

   Simple S2K specifier -- some arbitrary
data -- that gets hashed along with hashes the passphrase string, to help
prevent dictionary attacks.

    Octet 0:        0x01
    Octet 1:        hash algorithm
    Octets 2-9:     8-octet salt value

3.6.1.3 Iterated and Salted S2K

This includes both a salt and an octet count. produce the session key.  The salt
   manner in which this is combined
with done depends on the passphrase and size of the resulting value is hashed repeatedly.  This
further increases session key
   (which will depend on the amount cipher used) and the size of work an attacker must do to try
dictionary attacks.

    Octet 0:        0x04
    Octet 1: the hash algorithm
    Octets 2-9:     8-octet salt value
    Octets 10-13:   count, a four-octet, unsigned value

Note that
   algorithm's output. If the value 0x03 for octet 0 of a S2K specifier hash size is reserved; it
denotes an obsolete form greater than or equal to the
   session key size, the high-order (leftmost) octets of the Interated and Salted S2K.

3.6.2 String-to-key usage

Implementations SHOULD use salted or iterated-and-salted S2K
specifiers, as simple S2K specifiers hash are more vulnerable to dictionary
attacks.

3.6.2.1 Secret
   used as the key.

   If the hash size is less than the key encryption

An S2K specifier can be stored in size, multiple instances of
   the secret keyring to specify how hash context are created -- enough to
convert produce the passphrase to a required key that unlocks the secret
   data.  Older
versions These instances are preloaded with 0, 1, 2, ... octets of PGP just stored a cipher algorithm
   zeros (that is to say, the first instance has no preloading, the
   second gets preloaded with 1 octet preceding of zero, the third is preloaded
   with two octets of zeros, and so forth).

   As the
secret data or a zero is hashed, it is given independently to indicate that each hash
   context. Since the secret data was unencrypted.
The MD5 contexts have been initialized differently, they
   will each produce different hash function was always used to convert output.  Once the passphrase is
   hashed, the output data from the multiple hashes is concatenated,
   first hash leftmost, to a produce the key for data, with any excess octets
   on the specified cipher algorithm.

For compatibility, when an right discarded.

3.6.1.2. Salted S2K specifier is used, the special

   This includes a "salt" value 255
is stored in the position where S2K specifier -- some arbitrary
   data -- that gets hashed along with the passphrase string, to help
   prevent dictionary attacks.

       Octet 0:        0x01
       Octet 1:        hash algorithm octet would have
been in the old data structure.  This
       Octets 2-9:     8-octet salt value

   Salted S2K is then followed immediately by a
one-octet algorithm identifier, and then by exactly like Simple S2K, except that the S2K specifier as
encoded above.

Therefore, preceding input to the secret data there will be one
   hash function(s) consists of these
possibilities:

    0           secret data is unencrypted (no pass phrase)
    255 the 8 octets of salt from the S2K
   specifier, followed by algorithm octet the passphrase.

3.6.1.3. Iterated and Salted S2K specifier
    Cipher alg  use Simple S2K algorithm using MD5 hash

   This last possibility, the cipher algorithm number with includes both a salt and an implicit use
of MD5 octet count.  The salt is provided for backward compatibility; it should be understood,
but not generated.

These are followed by an 8-octet Initial Vector for the decryption of combined
   with the secret values, if they are encrypted, passphrase and then the secret key
values themselves.

3.6.2.2 Conventional message encryption

PGP 2.X always used IDEA with Simple string-to-key conversion when
conventionally encrypting a message.  PGP 5 can create a Conventional
Encrypted Session Key packet at the front of a message. resulting value is hashed repeatedly.
   This can be
used to allow S2K specifiers to be used for further increases the passphrase conversion,
to allow other ciphers than IDEA to be used, or to create messages with
a mix amount of conventional ESKs and public key ESKs.  This allows a message work an attacker must do to be decrypted either with try
   dictionary attacks.

       Octet  0:        0x03
       Octet  1:        hash algorithm
       Octets 2-9:      8-octet salt value
       Octet  10:       count, a passphrase or one-octet, coded value
   The count is coded into a public key.

3.6.3 String-to-key algorithms

3.6.3.1 Simple S2K algorithm

Simple S2K hashes the passphrase to produce one-octet number using the session key. following
   formula:

       #define EXPBIAS 6
           count = ((Int32)16 + (c & 15)) << ((c >> 4) + EXPBIAS);

   The
manner above formula is in which this C, where "Int32" is done depends on the size of the session key
(which will depend on the cipher used) and the size of the hash
algorithm's output. If the hash size is greater than or equal to the
session key size, the leftmost octets of the hash are used as the key.

If the hash size is less than the key size, multiple instances of the
hash context are created -- enough to produce the required key data.
These instances are preloaded with 0, 1, 2, ... octets of zeros (that
is to say, the first instance has no preloading, the second gets
preloaded with 1 octet of zero, the third is preloaded with two octets
of zeros, a type for a 32-bit
   integer, and so forth).

As the data is hashed, it is given independently to each hash context.
Since the contexts have been initialized differently, they will each
produce different hash output.  Once the passphrase is hashed, the
output data from the multiple hashes is concatenated, first hash

leftmost, to produce the key data, with any excess octets on the right
discarded.

3.6.3.2 Salted S2K algorithm

Salted S2K variable "c" is exactly like Simple S2K, except that the input to the
hash function(s) consists of the 8 octets of salt from the S2K
specifier, followed by the passphrase.

3.6.3.3 Iterated-Salted S2K algorithm coded count, Octet 10.

   Iterated-Salted S2K hashes the passphrase and salt data multiple
   times. The total number of octets to be hashed is specified in the four-octet
   encoded count in the S2K specifier.  Note that the resulting count
   value is an octet count of how many octets will be hashed, not an
   iteration count.

   Initially, one or more hash contexts are set up as with the other
   S2K algorithms, depending on how many octets of key data are needed.
    Then the salt, followed by the passphrase data is repeatedly hashed
   until the number of octets specified by the octet count has been
   hashed.  The one exception is that if the octet count is less than
   the size of the salt plus passphrase, the full salt plus passphrase
   will be hashed even though that is greater than the octet count.
   After the hashing is done the data is unloaded from the hash
   context(s) as with the other S2K algorithms.

4.  Packet Syntax

This section describes the packets used by OP.

4.1 Overview

An OP message is constructed from a number of records that

3.6.2. String-to-key usage

   Implementations SHOULD use salted or iterated-and-salted S2K
   specifiers, as simple S2K specifiers are
traditionally called packets.  A packet is a chunk of data that has a
tag specifying its meaning. more vulnerable to
   dictionary attacks.

3.6.2.1. Secret key encryption

   An OP message, keyring, certificate, and
so forth consists of S2K specifier can be stored in the secret keyring to specify how
   to convert the passphrase to a number of packets.  Some key that unlocks the secret data.
   Older versions of those packets may
contain other OP packets (for example, PGP just stored a compressed cipher algorithm octet preceding
   the secret data packet, when
uncompressed, contains OP packets).

Each packet consists of or a packet header, followed by zero to indicate that the packet body. secret data was
   unencrypted. The packet header MD5 hash function was always used to convert the
   passphrase to a key for the specified cipher algorithm.

   For compatibility, when an S2K specifier is of variable length.

4.2 Packet Headers

The first octet of used, the packet header special value
   255 is called stored in the "Packet Tag." It
determines position where the format of hash algorithm octet would
   have been in the header old data structure.  This is then followed
   immediately by a one-octet algorithm identifier, and denotes then by the packet contents.
The remainder of S2K
   specifier as encoded above.

   Therefore, preceding the packet header secret data there will be one of these
   possibilities:

       0:           secret data is unencrypted (no pass phrase)
       255:         followed by algorithm octet and S2K specifier
       Cipher alg:  use Simple S2K algorithm using MD5 hash
   This last possibility, the length cipher algorithm number with an implicit
   use of the packet.

Note that the most significant bit MD5 and IDEA, is the left-most bit, called bit 7.
A mask provided for this bit is 0x80 in hexadecimal.

       +---------------+
  PTag |7 6 5 4 3 2 1 0|
       +---------------+
  Bit 7 -- Always one
  Bit 6 -- New packet format backward compatibility; it MAY
   be understood, but SHOULD NOT be generated, and is deprecated.

   These are followed by an 8-octet Initial Vector for the decryption
   of the secret values, if set

PGP 2.6.X only uses old format packets.  Thus, software that
interoperates with those versions they are encrypted, and then the secret key
   values themselves.

3.6.2.2. Symmetric-key message encryption

   OpenPGP can create a Symmetric-key Encrypted Session Key (ESK)
   packet at the front of PGP must only use old format
packets.  If interoperability a message.  This is not an issue, either format may used to allow S2K
   specifiers to be
used.  Note that old format packets have four bits used for the passphrase conversion or to create
   messages with a mix of content tags, symmetric-key ESKs and
new format packets have six; some features cannot public-key ESKs. This
   allows a message to be decrypted either with a passphrase or a
   public key.

   PGP 2.X always used and still IDEA with Simple string-to-key conversion when
   encrypting a message with a symmetric algorithm. This is deprecated,
   but MAY be
backwards-compatible.

Old format packets contain:
  Bits 5-2 -- content tag
  Bits 1-0 - length-type

New format packets contain:
  Bits 5-0 -- content tag

The meaning of used for backwards-compatibility.

4. Packet Syntax

   This section describes the length-type in old-format packets is:

0 - The packet has a one-octet length.  The header used by OpenPGP.

4.1. Overview

   An OpenPGP message is 2 octets long.

1 - The constructed from a number of records that are
   traditionally called packets. A packet has is a two-octet length.  The header is 3 octets long.

2 - The packet chunk of data that has a four-octet length.  The header is 5 octets long.

3 - The packet is of indeterminate length.  The header is 1 byte long,
   tag specifying its meaning. An OpenPGP message, keyring,
   certificate, and the application must determine how long the packet is.  If the
packet is in so forth consists of a file, this means that the packet extends until the end number of the file.  In general, an application should not use indeterminate
length packets except where the end packets. Some of the data will be clear from the
context.

New format
   those packets have three possible ways of encoding length.  A
one-octet Body Length header encodes packet lengths of up to 191
octets, and may contain other OpenPGP packets (for example, a two-octet Body Length header encodes
   compressed data packet, when uncompressed, contains OpenPGP
   packets).

   Each packet lengths consists of
192 to 8383 octets.  For cases where longer a packet body lengths are
needed, or where header, followed by the length packet
   body. The packet header is of variable length.

4.2. Packet Headers

   The first octet of the packet body header is not known in advance
by called the issuer, Partial Body Length headers can be used.  These are
one-octet length headers that encode "Packet Tag." It
   determines the length of only part format of the
data packet.

Each Partial Body Length header is followed by a portion of and denotes the packet
body data. contents.
   The Partial Body Length remainder of the packet header specifies this portion's
length.  Another is the length header (of one of the three types) follows packet.

   Note that
portion.  The last length header in the packet must always be a regular
Body Length header.  Partial Body Length headers may most significant bit is the left-most bit, called bit
   7. A mask for this bit is 0x80 in hexadecimal.

              +---------------+
         PTag |7 6 5 4 3 2 1 0|
              +---------------+
         Bit 7 -- Always one
         Bit 6 -- New packet format if set
   PGP 2.6.x only uses old format packets. Thus, software that
   interoperates with those versions of PGP must only use old format
   packets. If interoperability is not an issue, either format may be
   used. Note that old format packets have four bits of content tags,
   and new format packets have six; some features cannot be used for
the non-final parts and
   still be backwards-compatible.

   Old format packets contain:

         Bits 5-2 -- content tag
         Bits 1-0 - length-type

   New format packets contain:

         Bits 5-0 -- content tag

4.2.1. Old-Format Packet Lengths

   The meaning of the packet.

A length-type in old-format packets is:

   0 - The packet has a one-octet Body Length length. The header encodes is 2 octets long.

   1 - The packet has a length of from 0 to 191
octets. This type of length two-octet length. The header is recognized because the one octet
value 3 octets long.

   2 - The packet has a four-octet length. The header is less than 192. 5 octets long.

   3 - The body length packet is equal to:

bodyLen = length_octet;

A two-octet Body Length header encodes a length of from 192 to 8383
octets.  It indeterminate length.  The header is recognized because its first 1 octet
       long, and the implementation must determine how long the packet
       is. If the packet is in the range 192 a file, this means that the packet
       extends until the end of the file. In general, an implementation
       should not use indeterminate length packets except where the end
       of the data will be clear from the context. The new format
       headers described below have a mechanism for precisely encoding
       data of indeterminite length.

4.2.2. New-Format Packet Lengths

   New format packets have four possible ways of encoding length:

    1. A one-octet Body Length header encodes packet lengths of up to
       191 octets.

    2. A two-octet Body Length header encodes packet lengths of 192 to
       8383 octets.

    3. A five-octet Body Length header encodes packet lengths of up to
       4,294,967,295 (0xFFFFFFFF) octets in length. (This actually
       encodes a four-octet scalar number.)

    4. When the length of the packet body is not known in advance by
       the issuer, Partial Body Length headers encode a packet of
       indeterminite length, effectively making it a stream.

4.2.2.1. One-Octet Lengths

   A one-octet Body Length header encodes a length of from 0 to 191
   octets. This type of length header is recognized because the one
   octet value is less than 192.  The body length is equal to:

       bodyLen = length_octet;

4.2.2.2. Two-Octet Lengths

   A two-octet Body Length header encodes a length of from 192 to 8383
   octets.  It is recognized because its first octet is in the range
   192 to 223.  The body length is equal to:

       bodyLen = (1st_octet - 192) * 256 + (2nd_octet) + 192

4.2.2.3. Five-Octet Lengths

   A five-octet Body Length header consists of a single octet holding
   the value 255, followed by a four-octet scalar. The body length is
   equal to:

        bodyLen = (2nd_octet << 24) | (3rd_octet << 16) |
                  (4th_octet << 8)  | 5th_octet

4.2.2.4. Partial Body Lengths

   A Partial Body Length header is one octet long and encodes a the
   length of only part of the data packet. This length
which is a power of 2,
   from 1 to 2147483648 1,073,741,824 (2 to the 31st 30th power).  It is recognized because by
   its one octet value that is greater than or equal to
224. 224, and less
   than 255. The partial body length is equal to:

       partialBodyLen = 1 << (length_octet & 0x1f);

Examples:

A

   Each Partial Body Length header is followed by a portion of the
   packet body data. The Partial Body Length header specifies this
   portion's length. Another length header (of one of the three types)
   follows that portion. The last length header in the packet must not
   be a partial Body Length header.  Partial Body Length headers may
   only be used for the non-final parts of the packet.

4.2.3. Packet Length Examples

   A packet with length 100 may have its length encoded in one octet:
   0x64. This is followed by 100 octets of data.

   A packet with length 1723 may have its length coded in two octets:
   0xC5, 0xFB.  This header is followed by the 1723 octets of data.

   A packet with length 100000 may have its length encoded in five
   octets: 0xFF, 0x01, 0x86, 0xA0.

   It might also be encoded in the following octet stream: 0xE1, first
   two octets of data, 0xE0, next one octet of data, 0xEF, next 32768
   octets of data, 0xF0, next 65536 octets of data, 0xC5, 0xDD, last
   1693 octets of data.  This is just one possible encoding, and many
   variations are possible on the size of the Partial Body Length
   headers, as long as a regular Body Length header encodes the last
   portion of the data. Note also that the last Body Length header can
   be a zero-length header.

   An implementation MUST only use Partial Body Lengths for data
   packets, be they literal, compressed, or encrypted. The first
   partial length MUST be at least 512 octets long.

   Please note that in all of these explanations, the total length of
   the packet is the length of the header(s) plus the length of the
   body.

4.3

4.3. Packet Tags

   The packet tag denotes what type of packet the body holds. Note that
   old format packets headers can only have tags less than 16, whereas new
   format
packets headers can have tags as great as 63. The defined tags (in
   decimal) are:

       0        -- Reserved. A Reserved - a packet tag must not have a tag with this value. value
       1        -- Public-Key Encrypted Session Key Packet
       2        -- Signature Packet
       3        -- Symmetric-Key Encrypted Session Key Packet
       4        -- One-Pass Signature Packet
       5        -- Secret Key Packet
       6        -- Public Key Packet
       7        -- Secret Subkey Packet
       8        -- Compressed Data Packet
       9        -- Symmetrically Encrypted Data Packet
       10       -- Marker Packet
       11       -- Literal Data Packet
       12       -- Trust Packet
       13       -- Name User ID Packet
       14       -- Subkey Packet
15       -- Reserved
       60 to 63 -- Private or Experimental Values

5. Packet Types

5.1

5.1. Public-Key Encrypted Session Key Packets (Tag 1)

   A Public-Key Encrypted Session Key packet holds the session key used
   to encrypt a message that is itself encrypted with a public key. message. Zero or more Encrypted Session Key packets and/or Conventional Encrypted Session Key
packets
   (either Public-Key or Symmetric-Key) may precede a Symmetrically
   Encrypted Data Packet, which holds an encrypted message.  The
   message is encrypted with a the session key, and the session key is
   itself encrypted and stored in the Encrypted Session Key packet(s).
   The Symmetrically Encrypted Data Packet is preceded by one
   Public-Key Encrypted Session Key packet for each OP OpenPGP key to
   which the message is encrypted.  The recipient of the message finds
   a session key that is encrypted to their public key, decrypts the
   session key, and then uses the session key to decrypt the message.

   The body of this packet consists of:

     - A one-octet number giving the version number of the packet type.
       The currently defined value for packet version is 3. An
       implementation should accept, but not generate a version of 2,
       which is equivalent to V3 in all other respects.

     - An eight-octet number that gives the key ID of the public key
       that the session key is encrypted to.

     - A one-octet number giving the public key algorithm used.

     - A string of octets that is the encrypted session key. This
       string takes up the remainder of the packet, and its contents
       are dependent on the public key algorithm used.

   Algorithm Specific Fields for RSA encryption

     - multiprecision integer (MPI) of RSA encrypted value m**e mod n.

   Algorithm Specific Fields for Elgamal encryption:

     - MPI of DSA Elgamal (Diffie-Hellman) value g**k mod p.

     - MPI of DSA Elgamal (Diffie-Hellman) value m * y**k mod p.

   The encrypted value "m" in the above formulas is derived from the session key
   as follows.  First the session key is prepended prefixed with a one-octet
   algorithm identifier that specifies the conventional symmetric encryption
   algorithm used to encrypt the following Symmetrically Encrypted Data
   Packet.  Then a two-octet checksum is appended which is equal to the
   sum of the preceding octets, including the algorithm identifier and
   session key, modulo 65536.  This value is then padded as described
   in PKCS-1 block type 02 [PKCS1] to form the "m" value used in the
   formulas above.

   Note that when an implementation forms several PKESKs with one
   session key, forming a message that can be decrypted by several
   keys, the PKCS-1 the implementation MUST make new padding for each
   key.

   An implementation MAY accept or use a Key ID of zero as a "wild
   card" or "speculative" Key ID. In this case, the receiving
   implementation would try all available private keys, checking for a
   valid decrypted session key. This format helps reduce traffic
   analysis of messages.

5.2

5.2. Signature Packet (Tag 2)

   A signature packet describes a binding between some public key and
   some data. The most common signatures are a signature of a file or a
   block of text, and a signature that is a certification of a user ID.

   Two versions of signature packets are defined.  Version 3 provides
   basic signature information, while version 4 provides an expandable
   format with subpackets that can specify more information about the
   signature. PGP 2.6.X 2.6.x only accepts version 3 signatures.

   Implementations MUST accept V3 signatures. Implementations SHOULD
   generate V4 signatures, unless there is a need to signatures.  Implementations MAY generate a V3 signature
   that can be verified by old implementations. PGP 2.6.x.

   Note that if an implementation is creating an encrypted and signed
   message that is encrypted to a V3 key, it is reasonable to create a
   V3 signature.

5.2.1 Version 3 Signature Packet Format

A version 3

5.2.1. Signature packet contains:
    - One-octet version Types

   There are a number (3).
    - One-octet length of following hashed material.  MUST be 5.
    - One-octet possible meanings for a signature, which are
   specified in a signature type.
    - Four-octet creation time.
    - Eight-octet key ID of signer.
    - One-octet public key algorithm.
    - One-octet hash algorithm.
    - Two-octet field holding left 16 bits type octet in any given signature. These
   meanings are:

   0x00: Signature of signed hash value.
    - One a binary document.
       Typically, this means the signer owns it, created it, or more multi-precision integers comprising
       certifies that it has not been modified.

   0x01: Signature of a canonical text document.
       Typically, this means the signature.
      This portion is algorithm specific, as described below. signer owns it, created it, or
       certifies that it has not been modified.  The data being signed is hashed, and then the signature type and
creation time from will be
       calculated over the text data with its line endings converted to
       <CR><LF> and trailing blanks removed.

   0x02: Standalone signature.
       This signature packet are hashed (5 additional
octets).  The resulting hash value is used in the a signature algorithm.
The high 16 bits (first two octets) of the hash are included in the

signature packet only its own subpacket
       contents. It is calculated identically to provide a quick test to reject some invalid
signatures.

    Algorithm Specific Fields for RSA signatures:
    - multiprecision integer (MPI) of RSA signature value m**d.

    Algorithm Specific Fields for DSA signatures:
    - MPI of DSA value r.
    - MPI over a
       zero-length binary document. Note that it doesn't make sense to
       have a V3 standalone signature.

   0x10: Generic certification of DSA value s.

The signature calculation is based on a hash User ID and Public Key packet.
       The issuer of the signed data, this certification does not make any particular
       assertion as
described above.  The details to how well the certifier has checked that the
       owner of the calculation are different for DSA
signature than for RSA signatures.

With RSA signatures, the hash value key is encoded as described in PKCS-1
section 10.1.2, "Data encoding", producing an ASN.1 value of fact the person described by the user ID.
       Note that all PGP "key signatures" are this type
DigestInfo, of
       certification.

   0x11: Persona certification of a User ID and then padded using PKCS-1 block type 01 [PKCS1].  This
requires inserting the hash value as an octet string into an ASN.1
structure. Public Key packet.
       The object identifier for issuer of this certification has not done any verification
       of the type claim that the owner of hash being used this key is
included in the structure. user ID
       specified.

   0x12: Casual certification of a User ID and Public Key packet.
       The hexadecimal representations for issuer of this certification has done some casual
       verification of the
currently defined hash algorithms are:

    - MD5:          0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d, 0x02, 0x05
    - SHA-1:        0x2b, 0x0e, 0x03, 0x02, 0x1a
    - RIPEMD-160:   0x2b, 0x24, 0x03, 0x02, 0x01

The ASN.1 OIDs are:
    - MD5:       1.2.840.113549.2.5
    - SHA-1:     1.3.14.3.2.26
    - RIPEMD160: 1.3.36.3.2.1

DSA signatures SHOULD use hashes with claim of identity.

   0x13: Positive certification of a size User ID and Public Key packet.
       The issuer of 160 bits, to match q,
the size this certification has done substantial
       verification of the group generated by claim of identity.

       Please note that the DSA key's generator value.  The
hash function result vagueness of these certification claims is treated as
       not a 160 bit number and used directly
in flaw, but a feature of the DSA signature algorithm.

5.2.2 Version 4 Signature Packet Format

A version 4 Signature packet contains:
    - One-octet version number (4).
    - One-octet signature type.
    - One-octet public key algorithm.
    - One-octet hash algorithm.
    - Two-octet octet count for following hashed subpacket data.
    - Hashed subpacket data. (zero or more subpackets)
    - Two-octet octet count system. Because PGP places
       final authority for following unhashed subpacket data.
    - Unhashed subpacket data. (zero or more subpackets)
    - Two-octet field holding left 16 bits validity upon the receiver of signed hash value.
    - One or a
       certification, it may be that one authority's casual
       certification might be more multi-precision integers comprising the signature. rigorous than some other authority's
       positive certification. These classifications allow a
       certification authority to issue fine-grained claims.

   0x18: Subkey Binding Signature
       This portion is algorithm specific, as described above.

The data being signed is hashed, and then the signature data from the
version number through the hashed subpacket data is hashed.  The
resulting hash value is what is signed.  The left 16 bits of a statement by the hash
are included in top-level signing key
       indicates that it owns the subkey. This signature packet to provide is calculated
       directly on the subkey itself, not on any User ID or other
       packets.

   0x1F: Signature directly on a quick test to reject
some invalid signatures.

There are two fields consisting of key
       This signature subpackets.  The first
field is hashed with calculated directly on a key.  It binds the rest of
       information in the signature data, while the second
is unhashed.  The second set of subpackets is not cryptographically
protected by to the signature key, and should include only advisory
information.

The algorithms is
       appropriate to be used for converting subpackets which provide information
       about the hash function result to a signature
are described above.

5.2.2.1 Signature Subpacket Specification

The subpacket fields consist of zero or more signature subpackets.
Each set of subpackets key, such as the revocation key subpacket. It is preceded by a two-octet count of also
       appropriate for statements that non-self certifiers want to make
       about the length
of key itself, rather than the set of subpackets.

Each subpacket consists of binding between a subpacket header key and
       a body. name.

   0x20: Key revocation signature
       The header
consists of:

    - subpacket length (1 or 2 octets):
      Length includes the type octet but not this length,
      1st octet <  192, then length signature is octet value
      1st octet >= 192, then length calculated directly on the key being revoked.
       A revoked key is 2 octets and equal not to
        (1st octet - 192) * 256 + (2nd octet) + 192

    - subpacket type (1 octet):
      If bit 7 be used.  Only revocation signatures by
       the key being revoked, or by an authorized revocation key,
       should be considered valid revocation signatures.

   0x28: Subkey revocation signature
       The signature is set, subpacket understanding calculated directly on the subkey being
       revoked.  A revoked subkey is critical,
       2 = signature creation time,
       3 = not to be used.  Only revocation
       signatures by the top-level signature expiration time,
       4 = exportable,
       5 = trust signature,
       6 = regular expression,
       7 = revocable,
       9 = key expiration time,
      10 = placeholder for backwards compatibility
      11 = preferred symmetric algorithms,
      12 = which is bound to this
       subkey, or by an authorized revocation key,
      16 = issuer key ID,
      20 = notation data,
      21 = preferred hash algorithms,
      22 = preferred compression algorithms,
      23 = key server preferences,
      24 = preferred key server,
      25 = primary user id,
      26 = policy URL,

27 = key flags, 28 = Signer's should be considered
       valid revocation signatures.

   0x30: Certification revocation signature
       This signature revokes an earlier user id

    - subpacket specific data:

An implementation SHOULD ignore any subpacket that it does not
recognize.

Bit 7 of the subpacket type is the "critical" bit.  If set, it denotes
that ID certification
       signature (signature class 0x10 through 0x13). It should be
       issued by the subpacket is one same key which is critical that the evaluator of issued the revoked signature recognize.  If or an
       authorized revocation key The signature should have a subpacket is encountered which is marked
critical but is unknown to the evaluating software, the evaluator
SHOULD consider later
       creation date than the signature to be it revokes.

   0x40: Timestamp signature.
       This signature is only meaningful for the timestamp contained in error.

An evaluator may "recognize" a subpacket, but not implement
       it.

5.2.2. Version 3 Signature Packet Format

   The
purpose body of the critical bit is to allow the signer to tell an evaluator
that it would prefer a new, unknown feature to generate an error than
be ignored.

5.2.2.2 version 3 Signature Subpacket Types

Several types Packet contains:

     - One-octet version number (3).

     - One-octet length of subpackets are currently defined.  Some subpackets
apply to the following hashed material.  MUST be 5.

         - One-octet signature itself and some are attributes of the key.
Subpackets that are found on a self-signature are placed on a user name
certification made by the type.

         - Four-octet creation time.

     - Eight-octet key itself.  Note that a ID of signer.

     - One-octet public key may have more
than one user name, and thus may have more than one self-signature, and
differing subpackets.

A self-signature is a binding signature made by the key the signature
refers to.  There are three types algorithm.

     - One-octet hash algorithm.

     - Two-octet field holding left 16 bits of self-signatures, signed hash value.

     - One or more multi-precision integers comprising the certification
signatures (types 0x10-0x13), signature.
       This portion is algorithm specific, as described below.

   The data being signed is hashed, and then the direct-key signature (type 0x1f), type and
   creation time from the subkey binding signature (type 0x18).  For certification
self-signatures, username may have a self-signature, and thus different
subpackets in those self-signatures.  For subkey binding signatures,
each subkey in fact has a self-signature.  Subpackets that appear packet are hashed (5 additional
   octets).  The resulting hash value is used in a
certification self-signature apply to the username, and subpackets that
appear signature
   algorithm. The high 16 bits (first two octets) of the hash are
   included in the subkey self-signature apply signature packet to the subkey.  Lastly,
subpackets provide a quick test to reject
   some invalid signatures.

   Algorithm Specific Fields for RSA signatures:

     - multiprecision integer (MPI) of RSA signature value m**d.

   Algorithm Specific Fields for DSA signatures:

     - MPI of DSA value r.

     - MPI of DSA value s.

   The signature calculation is based on a hash of the direct key signed data, as
   described above.  The details of the calculation are different for
   DSA signature apply to than for RSA signatures.

   With RSA signatures, the entire key.

Implementing software should interpret a self-signature's preference
subpackets as narrowly hash value is encoded as possible.  For example, suppose a key has two
usernames, Alice and Bob.  Suppose that Alice prefers the symmetric
algorithm CAST5, described in
   PKCS-1 section 10.1.2, "Data encoding", producing an ASN.1 value of
   type DigestInfo, and Bob prefers IDEA or Triple-DES.  If the software
locates this key via Alice's name, then padded using PKCS-1 block type 01 [PKCS1].
    This requires inserting the preferred algorithm is
CAST5, if software locates the key via Bob's name, then hash value as an octet string into an
   ASN.1 structure. The object identifier for the preferred
algorithm type of hash being
   used is IDEA.  If included in the key is located by key id, then algorithm of structure.  The hexadecimal representations
   for the default user name currently defined hash algorithms are:

     - MD2:          0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x02

     - MD5:          0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05

     - RIPEMD-160:   0x2B, 0x24, 0x03, 0x02, 0x01

     - SHA-1:        0x2B, 0x0E, 0x03, 0x02, 0x1A

   The ASN.1 OIDs are:

     - MD5:       1.2.840.113549.2.2

     - MD5:       1.2.840.113549.2.5

     - RIPEMD160: 1.3.36.3.2.1

     - SHA-1:     1.3.14.3.2.26

   DSA signatures SHOULD use hashes with a size of 160 bits, to match
   q, the key provides size of the default symmetric
algorithm.

A subpacket may be found either in group generated by the hashed or unhashed subpacket
sections of a signature.  If a subpacket DSA key's generator value.
    The hash function result is not hashed, then the
information treated as a 160 bit number and used
   directly in it cannot be considered definitive because it is not
part of the DSA signature proper.

Subpacket types: algorithm.

5.2.3. Version 4 Signature creation time (4 octet time field) Packet Format

   The time the signature was made.  Always included with new
        signatures.

    Issuer (8 octet key ID)

        The OP key ID body of the a version 4 Signature Packet contains:

     - One-octet version number (4).

     - One-octet signature type.

     - One-octet public key issuing the signature.

    Key expiration time (4 algorithm.

     - One-octet hash algorithm.

     - Two-octet scalar octet time field)

        The validity period count for following hashed subpacket
       data.

     - Hashed subpacket data. (zero or more subpackets)

     - Two-octet scalar octet count for following unhashed subpacket
       data.

     - Unhashed subpacket data. (zero or more subpackets)

     - Two-octet field holding left 16 bits of signed hash value.

     - One or more multi-precision integers comprising the key. signature.
       This portion is algorithm specific, as described above.

   The data being signed is hashed, and then the number of seconds
        after signature data from
   the key creation time that version number through the key expires.  If this hashed subpacket data (inclusive) is
        not present or has a
   hashed. The resulting hash value is what is signed.  The left 16
   bits of zero, the key never expires. This
        is found only on hash are included in the signature packet to provide a self-signature.

    Preferred symmetric algorithms (array
   quick test to reject some invalid signatures.

   There are two fields consisting of one-octet values)

        Symmetric algorithm numbers that indicate which algorithms signature subpackets.  The first
   field is hashed with the
        key holder prefers to use.  This rest of the signature data, while the
   second is an ordered list unhashed.  The second set of octets
        with subpackets is not
   cryptographically protected by the most preferred listed first.  It signature and should be assumed
        that include only
   advisory information.

   The algorithms listed are supported by for converting the recipient's
        software.  Algorithm numbers in section 6. This is only found
        on a self-signature.

    Preferred hash algorithms (array of one-octet values)

        Message digest algorithm numbers that indicate which algorithms
        the key holder prefers function result to receive.  Like the preferred
        symmetric algorithms, the list is ordered. Algorithm numbers
        are in section 6. This is only found on a self-signature.

    Preferred compression algorithms (array of one-octet values)

        Compression algorithm numbers that indicate which algorithms
        the key holder prefers to use.  Like the preferred symmetric
        algorithms, the list is ordered.  Algorithm numbers
   signature are described in a section 6.  If this below.

5.2.3.1. Signature Subpacket Specification

   The subpacket is not included, ZIP is
        preferred. A fields consist of zero denotes that uncompressed data is preferred;
        the key holder's software may not have compression software.
        This or more signature subpackets.
   Each set of subpackets is only found on preceded by a self-signature.

    Signature expiration time (4 octet time field)
        The validity period two-octet scalar count of
   the signature.  This is the number length of
        seconds after the signature creation time that the signature
        expires.  If this is not present or has a value set of zero, it
        never expires.

    Exportable (1 octet subpackets.

   Each subpacket consists of exportability, 0 for not, 1 for exportable)

        Signature's exportability status.  Packet body contains a
        boolean flag indicating whether subpacket header and a body.  The
   header consists of:

     - the signature is exportable.
        Signatures which are subpacket length (1,  2, or 5 octets)

     - the subpacket type (1 octet)

     - the subpacket specific data

   The length includes the type octet but not exportable are ignored during export
        and import operations.  If this packet length. Its format
   is not present the
        signature is assumed to be exportable.

    Revocable (1 octet of revocability, 0 for not, 1 for revocable)

        Signature's revocability status.  Packet body contains a
        boolean flag indicating whether the signature is revocable.
        Signatures which are not revocable have any later revocation
        signatures ignored.  They represent a commitment by the signer
        that he cannot revoke his signature for same as the life of his key.
        If this "new" format packet is not present, header lengths. That is:

       if the signature is revocable.

    Trust signature (1 octet "level" (depth), 1 1st octet of trust amount)

        Signer asserts that the key <  192, then length is not only valid, but also
        trustworthy, at the specified level.  Level 0 has the same
        meaning as an ordinary validity signature.  Level 1 means that octet value

       if the signed key 1st octet >= 192 and < 255, then length is asserted 2 octets and
       equal to be a valid trusted introducer,
        with (1st octet - 192) * 256 + (2nd octet) + 192

       if the 2nd 1st octet of = 255, then the body specifying subpacket length is a
       four-octet scalar found in octets 2 through 5, as per the degree packet
       header length.

   The value of trust.
        Level 2 means that the signed key is asserted to be trusted to
        issue level 1 trust signatures, i.e. that it is a "meta
        introducer".  Generally, a level n subpacket type octet may be:

       2 = signature creation time
       3 = signature expiration time
       4 = exportable
       5 = trust signature asserts that
        a
       6 = regular expression
       7 = revocable
       9 = key is trusted to issue level n-1 trust signatures.  The
        trust amount is in a range from 0-255, interpreted such that
        values less than 120 indicate partial trust and values of 120 expiration time
       10 = placeholder for backwards compatibility
       11 = preferred symmetric algorithms
       12 = revocation key
       16 = issuer key ID
       20 = notation data
       21 = preferred hash algorithms
       22 = preferred compression algorithms
       23 = key server preferences
       24 = preferred key server
       25 = primary user id
       26 = policy URL
       27 = key flags
       28 = Signer's user id
       100 to 110 = internal or greater indicate complete trust.  Implementations user-defined

   An implementation SHOULD
        emit values ignore any subpacket of 60 for partial trust and 120 for complete trust.

    Regular expression (null-terminated regular expression)

        Used in conjunction with trust signature packets (of level > 0)
        to limit the scope a type that it does
   not recognize.

   Bit 7 of trust which the subpacket type is extended.  Only signatures
        by the target key on user IDs which match "critical" bit.  If set, it
   denotes that the regular
        expression in subpacket is one that is critical for the body evaluator
   of this packet have trust extended by the trust packet.  The regular expression uses signature to recognize.  If a subpacket is encountered which
   is marked critical but is unknown to the same syntax
        as evaluating software, the Henry Spencer's "almost public domain" regular
        expression package.  A description of
   evaluator SHOULD consider the syntax in signature to be in error.

   An evaluator may "recognize" a
        section below.

    Revocation key (1 octet of class, 1 octet of algid, 20 octets subpacket, but not implement it. The
   purpose of
    fingerprint)

        Authorizes the specified key critical bit is to issue revocation
        self-signatures for this key.  Class octet must have bit 0x80
        set, other bits are for future expansion allow the signer to other kinds tell an
   evaluator that it would prefer a new, unknown feature to generate an
   error than be ignored.

   Implementations SHOULD implement "preferences".

5.2.3.2. Signature Subpacket Types

   A number of subpackets are currently defined.  Some subpackets apply
   to the signature authorizations. This is found on a self-signature.

        Authorizes itself and some are attributes of the specified key to issue revocation signatures for
        this key.  Class octet must have bit 0x80 set.  If the bit 0x40
        is set, then this means
   Subpackets that the revocation information is
        sensitive.  Other bits are for future expansion to other kinds
        of authorizations.  This is found on a self-signature.

        If the "sensitive" flag is set, self-signature are placed on a user
   id certification made by the keyholder feels this
        subpacket contains private trust information key itself. Note that describes a
        real-world sensitive relationship.  If this flag key may have
   more than one user id, and thus may have more than one
   self-signature, and differing subpackets.

   A self-signature is set,
        implementations SHOULD NOT export this a binding signature to other users
        except in cases where made by the data needs to be available: when key the
   signature is being sent to refers to. There are three types of self-signatures, the designated revoker, or when it
        is accompanied by a revocation
   certification signatures (types 0x10-0x13), the direct-key signature from that revoker.
        Note that it
   (type 0x1f), and the subkey binding signature (type 0x18). For
   certification self-signatures, each user ID may be appropriate to isolate this subpacket
        within have a separate signature so that it is not combined with
        other
   self-signature, and thus different subpackets which need to be exported.

    Notation Data (4 octets of flags, 2 octets of name length,
                   2 octets of value length, M octets of name data,
                   N octets of value data)

        This subpacket describes in those
   self-signatures. For subkey binding signatures, each subkey in fact
   has a "notation" on self-signature. Subpackets that appear in a certification
   self-signature apply to the signature username, and subpackets that appear in
   the
        issuer wishes subkey self-signature apply to make.  The notation has the subkey. Lastly, subpackets on
   the direct key signature apply to the entire key.

   Implementing software should interpret a name and self-signature's preference
   subpackets as narrowly as possible. For example, suppose a value,
        each key has
   two usernames, Alice and Bob. Suppose that Alice prefers the
   symmetric algorithm CAST5, and Bob prefers IDEA or Triple-DES. If
   the software locates this key via Alice's name, then the preferred
   algorithm is CAST5, if software locates the key via Bob's name, then
   the preferred algorithm is IDEA. If the key is located by key id,
   then algorithm of which are strings the default user id of octets.  There the key provides the
   default symmetric algorithm.

   A subpacket may be more than
        one notation found either in the hashed or unhashed subpacket
   sections of a signature.  Notations can be used for any
        extension If a subpacket is not hashed, then the issuer
   information in it cannot be considered definitive because it is not
   part of the signature cares to make. proper.

5.2.3.3. Signature creation time

   (4 octet time field)

   The
        "flags" field holds four octets of flags.

        All undefined flags time the signature was made.

   MUST be zero.  Defined flags are:
        First octet: 0x80 = human-readable. This note is text, a note
                            from one person to another, and has no
                            meaning to software.
        Other octets: none. present in the hashed area.

5.2.3.4. Issuer

   (8 octet key ID)

   The OpenPGP key ID of the key issuing the signature.

   MUST be present in the hashed area.

5.2.3.5. Key server preferences (N octets expiration time

   (4 octet time field)

   The validity period of flags) the key.  This is a list the number of flags that indicate preferences seconds after
   the key creation time that the key
        holder expires.  If this is not present
   or has about how a value of zero, the key never expires. This is handled found only on
   a key server.  All
        undefined flags MUST be zero.

       First octet: 0x80 = No-modify -- the key holder requests self-signature.

5.2.3.6. Preferred symmetric algorithms

   (sequence of one-octet values)
   Symmetric algorithm numbers that
                           this key only be modified or updated by indicate which algorithms the key
   holder or prefers to use.  The subpacket body is an authorized administrator ordered list of
   octets with the key server. most preferred listed first. It is assumed that only
   algorithms listed are supported by the recipient's software.
   Algorithm numbers in section 9. This is found only found on a
   self-signature.

5.2.3.7. Preferred hash algorithms

   (array of one-octet values)

   Message digest algorithm numbers that indicate which algorithms the
   key server (String) holder prefers to receive. Like the preferred symmetric
   algorithms, the list is ordered. Algorithm numbers are in section 6.
   This is only found on a URL self-signature.

5.2.3.8. Preferred compression algorithms

   (array of a key server one-octet values)

   Compression algorithm numbers that indicate which algorithms the key
   holder prefers be
        used for updates.  Note that keys with multiple user names can
        have a preferred key server for each user name.  Note also that
        since to use. Like the preferred symmetric algorithms, the
   list is ordered. Algorithm numbers are in section 6. If this
   subpacket is a URL, not included, ZIP is preferred. A zero denotes that
   uncompressed data is preferred; the key server can actually be holder's software may not
   have compression software. This is only found on a copy self-signature.

5.2.3.9. Signature expiration time

   (4 octet time field)

   The validity period of the key retrieved by ftp, http, finger, etc.

    Primary user id (1 octet, boolean) signature.  This is a flag in a user id's self the number of seconds
   after the signature creation time that states
        whether this user id is the main user id for this key.  It is
        reasonable for an implementation to resolve ambiguities in
        preferences, etc. by referring to the primary user id. signature expires. If
   this
        flag is absent, its value is zero.  If more than one user id in not present or has a key is marked as primary, the implementation may resolve the
        ambiguity in any way value of zero, it sees fit.

    Policy URL (String)

        This subpacket contains a URL never expires.

5.2.3.10. Exportable

   (1 octet of exportability, 0 for not, 1 for exportable)

   Signature's exportability status.  Packet body contains a document that describes boolean
   flag indicating whether the
        policy under signature is exportable. Signatures
   which are not exportable are ignored during export and import
   operations.  If this packet is not present the signature was issued.

    Key Flags (Octet string)

        This subpacket contains a list of binary flags that hold
        information about a key.  It is a string assumed
   to be exportable.

5.2.3.11. Revocable

   (1 octet of octets, and an
        implementation MUST NOT assume a fixed size.  This is so it can
        grow over time.  If revocability, 0 for not, 1 for revocable)

   Signature's revocability status.  Packet body contains a list is shorter than an implementation
        expects, boolean
   flag indicating whether the unstated flags signature is revocable.  Signatures
   which are considered to be zero.  The
        defined flags are:

        First octet:
        0x01 - This key may be used to certify other keys.
        0x02 - This key may be used to sign data.
        0x04 - This key may be used to encrypt communications.
        0x08 - This key may be used to encrypt storage.
        0x10 - The private component of this key may not revocable have been split by any later revocation signatures
   ignored.  They represent a secret-sharing mechanism.
        0x80 - The private component of this key may be in commitment by the signer that he cannot
   revoke his signature for the posession life of more than one person.

        Usage notes:

        The flags in his key.  If this packet may appear in self-signatures or in
        certification signatures.  They mean different things depending
        on who is making not
   present, the statement -- for example, a certification signature that has the "sign data" flag is stating revocable.

5.2.3.12. Trust signature

   (1 octet "level" (depth), 1 octet of trust amount)

   Signer asserts that the
        certification key is for that use.  On not only valid, but also trustworthy,
   at the other hand, specified level.  Level 0 has the
        "communications encryption" flag in a self-signature is stating
        a preference same meaning as an ordinary
   validity signature.  Level 1 means that a given the signed key be used for communications.  Note
        however, that it is asserted
   to be a thorny issue to determine what is
        "communications" and what is "storage." This decision is left
        wholly up to the implementation; valid trusted introducer, with the authors 2nd octet of this document
        do not claim any special wisdom on the issue, and realize body
   specifying the degree of trust. Level 2 means that
        accepted opinion may change.

        The "split key" (0x10) and "group key" (0x80) flags are placed
        on a self-signature only; they are meaningless on a
        certification signature.  They SHOULD the signed key is
   asserted to be placed only on trusted to issue level 1 trust signatures, i.e. that
   it is a
        direct-key signature (type 0x1f) or "meta introducer". Generally, a subkey level n trust signature (type
        0x18), one
   asserts that refers to the key the flag applies to.

    Signer's User ID

        This subpacket allows a keyholder key is trusted to state which user id issue level n-1 trust signatures.
   The trust amount is
        responsible for the signing.  Many keyholders use in a single key
        for different purposes, such as business communications as well
        as personal communications.  This subpacket allows range from 0-255, interpreted such a
        keyholder to state which that
   values less than 120 indicate partial trust and values of their roles is making a signature. 120 or
   greater indicate complete trust.  Implementations SHOULD implement "preferences".

5.2.3 Signature Types

There are a number emit values
   of possible meanings 60 for a signature, which are
specified partial trust and 120 for complete trust.

5.2.3.13. Regular expression

   (null-terminated regular expression)

   Used in a conjunction with trust signature type octet in any given signature.  These
meanings are:

    - 0x00: Signature packets (of level > 0) to
   limit the scope of a binary document.

Typically, this means trust which is extended.  Only signatures by the signer owns it, created it, or certifies that
it has not been modified.

    - 0x01: Signature of a canonical text document.

Typically, this means
   target key on user IDs which match the signer owns it, created it, or certifies that
it has not been modified.  The signature will be calculated over regular expression in the
text data with its line endings converted to <CR><LF>.

    - 0x02: Standalone signature.

This signature is a signature
   body of only its own subpacket contents.  It
is calculated identically to a signature over a zero-length binary
document.  Note that it doesn't make sense to this packet have a V3 standalone
signature.

    - 0x10: The certification of a User ID and Public Key trust extended by the trust packet. The issuer of this certification does not make any particular assertion
as to how well
   regular expression uses the certifier has checked that same syntax as the owner Henry Spencer's
   "almost public domain" regular expression package. A description of
   the key syntax is found in fact the person described by the user ID.  Note that all PGP "key
signatures" are this type of certification.

    - 0x11: This is a persona certification section below.

5.2.3.14. Revocation key

   (1 octet of a User ID and
            Public Key packet.

The issuer class, 1 octet of this certification has not done any verification algid, 20 octets of fingerprint)

   Authorizes the
claim that the owner of this specified key is the user ID specified.

    - 0x12: This is the casual certification of a User ID and
            Public Key packet.

The issuer of to issue revocation signatures for this certification has done some casual verification of
the claim
   key.  Class octet must have bit 0x80 set, other bits are for future
   expansion to other kinds of identity.

    - 0x13: signature authorizations. This is the positive certification of found
   on a User ID and
            Public Key packet.

The issuer of self-signature.

   Authorizes the specified key to issue revocation signatures for this certification has done substantial verification of
   key.  Class octet must have bit 0x80 set. If the claim of identity.

Please note bit 0x40 is set,
   then this means that the vagueness revocation information is sensitive.  Other
   bits are for future expansion to other kinds of these certification claims authorizations. This
   is not a
flaw, but found on a feature of self-signature.

   If the system.  Because PGP places final authority
for validity upon "sensitive" flag is set, the receiver of a certification, it may be keyholder feels this subpacket
   contains private trust information that one
authority's casual certification might be more rigorous than some other
authority's positive certification.  These classifications allow describes a
certification authority to issue fine-grained claims.

    - 0x18: This real-world
   sensitive relationship. If this flag is used for a signature by a set, implementations SHOULD
   NOT export this signature key to bind a
      subkey which will be used for encryption.

The signature is calculated directly on the subkey itself, not on any
User ID or other packets.

    - 0x1f: Signature directly on a key

This signature is calculated directly on a key.  It binds the
information users except in cases where the signature subpackets
   data needs to be available: when the key, and signature is appropriate being sent to be used for subpackets which provide information about the key, such
as the revocation key subpacket.  It
   designated revoker, or when it is also accompanied by a revocation
   signature from that revoker.  Note that it may be appropriate for statements to
   isolate this subpacket within a separate signature so that non-self certifiers want it is not
   combined with other subpackets which need to make about be exported.

5.2.3.15. Notation Data

       (4 octets of flags, 2 octets of name length (M),
                           2 octets of value length (N),
                           M octets of name data,
                           N octets of value data)

   This subpacket describes a "notation" on the key itself, rather than signature that the binding between
   issuer wishes to make. The notation has a key name and a name.

    - 0x20: This value, each of
   which are strings of octets. There may be more than one notation in
   a signature. Notations can be used for any extension the issuer of
   the signature cares to make. The "flags" field holds four octets of
   flags.

   All undefined flags MUST be zero. Defined flags are:

       First octet: 0x80 = human-readable. This note is used text, a note
                           from one person to revoke another, and has no
                           meaning to software.
       Other octets: none.

5.2.3.16. Key server preferences

   (N octets of flags)

   This is a key.

The signature list of flags that indicate preferences that the key
   holder has about how the key is calculated directly handled on a key server. All
   undefined flags MUST be zero.

   First octet: 0x80 = No-modify
       the key being revoked.  A
revoked holder requests that this key is not to only be used.  Only revocation signatures modified or
       updated by the key
being revoked, holder or by an authorized revocation key, should be
considered.

    - 0x28: This is used to revoke a subkey.

The signature administrator of the key server.

   This is calculated directly found only on the subkey being revoked.  A
revoked subkey a self-signature.

5.2.3.17. Preferred key server

   (String)

   This is not to be used.  Only revocation signatures by a URL of a key server that the
top-level signature key which is bound to this subkey, or by an
authorized revocation key, should holder prefers be considered.

    - 0x30: This signature revokes an earlier used
   for updates. Note that keys with multiple user ID certification
      signature (signature class 0x10 through 0x13).

It should be issued by the same ids can have a
   preferred key which issued server for each user id. Note also that since this is
   a URL, the revoked signature,
and should have key server can actually be a later creation date than copy of the signature it revokes.

    - 0x40: Timestamp signature. key retrieved by
   ftp, http, finger, etc.

5.2.3.18. Primary user id

   (1 octet, boolean)

   This signature is only meaningful for the timestamp contained in it.

5.2.4 Computing Signatures

All signatures are formed by producing a hash over the signature data,
and then using the resulting hash flag in the signature algorithm.

The a user id's self signature data that states whether
   this user id is simple to compute for document signatures (types
0x00 and 0x01), for which the document itself main user id for this key. It is reasonable for
   an implementation to resolve ambiguities in preferences, etc. by
   referring to the data.  For
standalone signatures, primary user id. If this flag is a null string.

When a signature absent, its value
   is made over zero. If more than one user id in a key, the hash data starts with the
octet 0x99, followed by a two-octet length of the key, and then body of
the key packet. (Note that this is an old-style packet header for a key
packet with two-octet length.) A subkey signature (type 0x18) then
hashes the subkey, using the same format marked as primary, the main key.  Key
revocation signatures (types 0x20 and 0x28) hash only the key being
revoked.

A certification signature (type 0x10 through 0x13) then hashes the user
name being bound to the key.  A V3 certification hashes the contents of
   implementation may resolve the name packet, without ambiguity in any header.  A V4 certification hashes the
constant 0xd4 (which is an old-style CTB with the length-of-length set
to zero), way it sees fit.

5.2.3.19. Policy URL

   (String)

   This subpacket contains a four-octet number giving the length URL of a document that describes the username, and
then the username data.

Once
   policy under which the data body is hashed, then signature was issued.

5.2.3.20. Key Flags

   (Octet string)

   This subpacket contains a trailer list of binary flags that hold information
   about a key. It is hashed.  A V3 signature
hashes five octets a string of the packet body, starting from the signature type
field. octets, and an implementation MUST
   NOT assume a fixed size. This data is the signature type, followed by the four-octet
signature so it can grow over time.  A V4 signature hashes the packet body starting from
its first field, the version number, through the end of the hashed

subpacket data.  Thus, If a list
   is shorter than an implementation expects, the fields hashed unstated flags are the signature version, the
signature type, the public
   considered to be zero. The defined flags are:

       First octet:

       0x01 - This key algorithm, the hash algorithm, the
hashed subpacket length, and the hashed subpacket body.

After all this has been hashed, the resulting hash field is may be used in the
signature algorithm, and placed at the end of the signature packet.

5.3 Symmetric-Key Encrypted Session-Key Packets (Tag 3)

The Symmetric-Key Encrypted Session Key packet holds the
conventional-cipher encryption of a session to certify other keys.

       0x02 - This key may be used to sign data.

       0x04 - This key may be used to encrypt a
message.  Zero or more Encrypted Session Key packets and/or
Conventional Encrypted Session Key packets communications.

       0x08 - This key may precede a Symmetrically
Encrypted Data Packet that holds an encrypted message. be used to encrypt storage.

       0x10 - The message is
encrypted with private component of this key may have been split by
       a session key, and the session secret-sharing mechanism.

       0x80 - The private component of this key is itself encrypted
and stored may be in the Encrypted Session Key
       possession of more than one person.

   Usage notes:

   The flags in this packet may appear in self-signatures or in
   certification signatures. They mean different things depending on
   who is making the Conventional
Encrypted Session Key packet.

If statement -- for example, a certification
   signature that has the Symmetrically Encrypted Data Packet "sign data" flag is preceded by one or more
Symmetric-Key Encrypted Session Key packets, each specifies stating that the
   certification is for that use. On the other hand, the
   "communications encryption" flag in a
passphrase which may self-signature is stating a
   preference that a given key be used to decrypt the message.  This allows a
message to be encrypted to for communications. Note
   however, that it is a number of public keys, and also thorny issue to one or
more pass phrases.  This packet type determine what is new,
   "communications" and what is not generated by
PGP 2.x or PGP 5.0.

The body "storage." This decision is left wholly
   up to the implementation; the authors of this packet consists of:
    - A one-octet version number. document do not claim
   any special wisdom on the issue, and realize that accepted opinion
   may change.

   The "split key" (0x10) and "group key" (0x80) flags are placed on a
   self-signature only; they are meaningless on a certification
   signature. They SHOULD be placed only currently defined version is
      4.
    - A one-octet number describing the symmetric algorithm used.
    - A string-to-key (S2K) specifier, length as defined above.
    - Optionally, on a direct-key signature
   (type 0x1f) or a subkey signature (type 0x18), one that refers to
   the encrypted session key itself, the flag applies to.

5.2.3.21. Signer's User ID

   This subpacket allows a keyholder to state which user id is decrypted
          with the string-to-key object.

If
   responsible for the encrypted session signing. Many keyholders use a single key for
   different purposes, such as business communications as well as
   personal communications. This subpacket allows such a keyholder to
   state which of their roles is not present (which can be detected on making a signature.

5.2.4. Computing Signatures

   All signatures are formed by producing a hash over the basis of packet length signature
   data, and S2K specifier size), then the S2K
algorithm applied to the passphrase produces the session key for
decrypting the file, using the symmetric cipher algorithm from the
Symmetric-Key Encrypted Session Key packet.

If resulting hash in the encrypted session key signature algorithm.

   The signature data is present, the result of applying the S2K
algorithm simple to compute for document signatures
   (types 0x00 and 0x01), for which the passphrase document itself is the data.
   For standalone signatures, this is used to decrypt just that encrypted
session key field, using CFB mode with an IV of all zeros.  The
decryption result consists of a one-octet algorithm identifier that
specifies null string.

   When a signature is made over a key, the conventional encryption algorithm used to encrypt hash data starts with the
following Symmetrically Encrypted Data Packet,
   octet 0x99, followed by a two-octet length of the key, and then body
   of the session key octets themselves.

Note: because an all-zero IV packet. (Note that this is used an old-style packet header for this decryption, the S2K
specifier MUST use a salt value, either
   a a Salted S2K or an
Iterated-Salted S2K.  The salt value will insure that the decryption key is not repeated even if the passphrase is reused.

5.4 One-Pass Signature Packets (Tag 4)

The One-Pass Signature packet precedes with two-octet length.) A subkey signature (type 0x18)
   then hashes the signed data subkey, using the same format as the main key. Key
   revocation signatures (types 0x20 and contains
enough information to allow 0x28) hash only the receiver to begin calculating any key being
   revoked.

   A certification signature (type 0x10 through 0x13) hashes needed the user
   id being bound to verify the signature.  It allows key into the Signature Packet
to be placed at hash context after the end above
   data. A V3 certification hashes the contents of the message, so that the signer can compute
the entire signed message in one pass. name packet,
   without any header. A One-Pass Signature does not interoperate V4 certification hashes the constant 0xd4
   (which is an old-style packet header with PGP 2.6.x or earlier.

The the length-of-length set
   to zero), a four-octet number giving the length of the username, and
   then the username data.

   Once the data body is hashed, then a trailer is hashed. A V3
   signature hashes five octets of this the packet consists of:
    - A one-octet version number. The current version body, starting from the
   signature type field. This data is 3.
    - the signature type, followed by
   the four-octet signature time. A one-octet V4 signature type. Signature types hashes the packet body
   starting from its first field, the version number, through the end
   of the hashed subpacket data. Thus, the fields hashed are described
          in section 5.2.3.
    - A one-octet number describing the hash algorithm used.
    - A one-octet number describing
   signature version, the signature type, the public key algorithm used.
    - An eight-octet number holding algorithm, the key ID of
   hash algorithm, the signing key.
    - A one-octet number holding hashed subpacket length, and the hashed
   subpacket body.

   V4 signatures also hash in a flag showing whether final trailer of six octets: the
   version of the signature
is nested.  A zero value indicates packet, i.e. 0x04; 0xFF; a four-octet,
   big-endian number that is the next length of the hashed data from the
   signature packet (note that this number does not include these final
   six octets.

   After all this has been hashed, the resulting hash field is
another One-Pass Signature packet which describes another used in
   the signature to be applied to algorithm, and placed at the same message data.

5.5 end of the signature
   packet.

5.3. Symmetric-Key Encrypted Session-Key Packets (Tag 3)

   The Symmetric-Key Encrypted Session Key Material Packet

A key material packet contains all holds the information about
   symmetric-key encryption of a public session key used to encrypt a message.
    Zero or
private key.  There are four variants of this packet type, and two
major versions.  Consequently, this section is complex.

5.5.1 Key Packet Variants

5.5.1.1 Public more Encrypted Session Key Packet (Tag 6)

A Public packets and/or Symmetric-Key
   Encrypted Session Key packet starts a series of packets may precede a Symmetrically Encrypted
   Data Packet that forms holds an OP encrypted message.  The message is
   encrypted with a session key, and the session key
(sometimes called an OP certificate).

5.5.1.2 Public Subkey Packet (Tag 14)

A Public Subkey is itself
   encrypted and stored in the Encrypted Session Key packet (tag 14) has exactly or the same format as a Public
   Symmetric-Key Encrypted Session Key packet, but denotes a subkey.  One packet.

   If the Symmetrically Encrypted Data Packet is preceded by one or
   more subkeys Symmetric-Key Encrypted Session Key packets, each specifies a
   passphrase which may be
associated with a top-level key.  By convention, the top-level key
provides signature services, and used to decrypt the subkeys provide encryption
services.

Note: in PGP 2.6.X, tag 14 was intended message.  This allows a
   message to be encrypted to indicate a comment packet.
This tag was selected for reuse because no previous version number of PGP ever
emitted comment packets but they did properly ignore them.  Public
Subkey packets are ignored by PGP 2.6.X public keys, and do not cause it also to fail,
providing a limited degree of backwards compatibility.

5.5.1.3 Secret Key Packet (Tag 5)

A Secret Key packet contains all the information that is found in a
Public Key packet, including the public key material, but also includes
the secret key material after all the public key fields.

5.5.1.4 Secret Subkey Packet (Tag 7)

A Secret Subkey one
   or more pass phrases. This packet (tag 7) type is the subkey analog of the Secret Key
packet, new, and has exactly the same format.

5.5.2 Public Key Packet Formats

There are two versions of key-material packets.  Version 3 packets were
first generated PGP 2.6.  Version 2 packets are identical in format to
Version 3 packets, but are is not generated
   by PGP 2.5 2.x or before.  PGP 5.0
introduces version 4 packets, with new fields and semantics. PGP 2.6.X
will not accept key-material packets with versions greater than 3.

OP implementations SHOULD create keys with version 4 format.  An
implementation MAY generate a V3 key to ensure interoperability with
old software; note, however, that V4 keys correct some security
deficiencies in V3 keys.  These deficiencies are described below.  An
implementation MUST NOT create a V3 key with a public key algorithm
other than RSA.

A version 3 public key or public subkey 5.0.

   The body of this packet contains: consists of:

     - A one-octet version number (3). number. The only currently defined version
       is 4.

     - A four-octet one-octet number denoting the time that describing the key was created. symmetric algorithm used.

     - A two-octet number denoting string-to-key (S2K) specifier, length as defined above.

     - Optionally, the time in days that this encrypted session key itself, which is
      valid. decrypted
       with the string-to-key object.

   If this number the encrypted session key is zero, then it does not expire.
    - A one-octet number denoting present (which can be detected
   on the public key algorithm of this key
    - A series basis of multi-precision integers comprising packet length and S2K specifier size), then the key
      material:
    - a multiprecision integer (MPI) of RSA public modulus n;
    - an MPI of RSA public encryption exponent e.

The fingerprint of S2K
   algorithm applied to the passphrase produces the session key is formed by hashing for
   decrypting the body (but not file, using the
two-octet length) of symmetric cipher algorithm from the MPIs that form
   Symmetric-Key Encrypted Session Key packet.

   If the encrypted session key material (public
modulus n, followed by exponent e) with MD5.

The eight-octet key ID of is present, the key consists result of applying the low 64 bits of
   S2K algorithm to the
public modulus of passphrase is used to decrypt just that
   encrypted session key field, using CFB mode with an RSA key.

Since the release IV of V3 keys, there have been a number all zeros.
    The decryption result consists of improvements
desired in a one-octet algorithm identifier
   that specifies the key format.  For example, if symmetric-key encryption algorithm used to
   encrypt the key ID is a function of following Symmetrically Encrypted Data Packet, followed
   by the public modulus, it session key octets themselves.

   Note: because an all-zero IV is easy used for this decryption, the S2K
   specifier MUST use a person to create salt value, either a key a Salted S2K or an
   Iterated-Salted S2K.  The salt value will insure that has the same decryption
   key ID as some existing key.  Similarly, MD5 is no longer the
preferred hash algorithm, and not hashing the length of an MPI with its
body increases repeated even if the chances of a fingerprint collision.

The version 4 format passphrase is similar reused.

5.4. One-Pass Signature Packets (Tag 4)

   The One-Pass Signature packet precedes the signed data and contains
   enough information to allow the version 3 format except for receiver to begin calculating any
   hashes needed to verify the
absence of a validity period.  This has been moved signature.  It allows the Signature
   Packet to be placed at the signature
packet.  In addition, fingerprints end of version 4 keys are calculated
differently from version 3 keys, as described the message, so that the signer
   can compute the entire signed message in section "Enhanced Key
Formats." one pass.

   A version 4 One-Pass Signature does not interoperate with PGP 2.6.x or
   earlier.

   The body of this packet contains: consists of:

     - A one-octet version number (4). number. The current version is 3.

     - A four-octet one-octet signature type. Signature types are described in
       section 5.2.3.

     - A one-octet number denoting the time that describing the key was created. hash algorithm used.

     - A one-octet number denoting describing the public key algorithm of this key used.

     - A series of multi-precision integers comprising An eight-octet number holding the key
      material.  This algorithm-specific portion is:

    Algorithm Specific Fields for RSA public keys:
    - multiprecision integer (MPI) of RSA public modulus n;
    - MPI of RSA public encryption exponent e.

    Algorithm Specific Fields for DSA public keys:
    - MPI ID of DSA prime p; the signing key.

     - MPI of DSA group order q (q is A one-octet number holding a prime divisor of p-1);
    - MPI of DSA group generator g;
    - MPI of DSA public key flag showing whether the signature
       is nested.  A zero value y (= g**x where x indicates that the next packet is secret).

    Algorithm Specific Fields for Elgamal
       another One-Pass Signature packet which describes another
       signature to be applied to the same message data.

5.5. Key Material Packet

   A key material packet contains all the information about a public keys:
    - MPI of Elgamal prime p;
    - MPI of Elgamal group generator g;
    - MPI or
   private key.  There are four variants of Elgamal public key value y (= g**x where x this packet type, and two
   major versions. Consequently, this section is secret).

5.5.3 Secret complex.

5.5.1. Key Packet Formats

The Secret Variants

5.5.1.1. Public Key and Secret Subkey packets contain all the data of the Packet (Tag 6)
   A Public Key and packet starts a series of packets that forms an OpenPGP
   key (sometimes called an OpenPGP certificate).

5.5.1.2. Public Subkey packets, with additional
algorithm-specific secret key data appended, in encrypted form.

The packet contains:
    - Packet (Tag 14)

   A Public Key or Public Subkey packet, packet (tag 14) has exactly the same format as described above
    - a
   Public Key packet, but denotes a subkey. One octet indicating string-to-key usage conventions.  0 indicates
      that or more subkeys may be
   associated with a top-level key.  By convention, the secret top-level key data is not encrypted.  255 indicates that a
      string-to-key specifier is being given.  Any other value
      is a conventional
   provides signature services, and the subkeys provide encryption algorithm specifier.
    - [Optional] If string-to-key usage octet
   services.

   Note: in PGP 2.6.x, tag 14 was 255, intended to indicate a one-octet
      conventional encryption algorithm.
    - [Optional] If string-to-key usage octet comment
   packet. This tag was 255, a string-to-key
      specifier.  The length selected for reuse because no previous version
   of the string-to-key specifier is implied
      by its type, as described above.
    - [Optional] If secret data is encrypted, eight-octet Initial Vector
      (IV).
    - Encrypted multi-precision integers comprising the secret key data.
      These algorithm-specific fields PGP ever emitted comment packets but they did properly ignore
   them.  Public Subkey packets are as described below.

    - Two-octet checksum of the plaintext of the algorithm-specific
      portion (sum of all octets, mod 65536).

    Algorithm Specific Fields for RSA secret keys:
    - multiprecision integer (MPI) of RSA secret exponent d.
    - MPI of RSA secret prime value p.
    - MPI of RSA secret prime value q (p < q).
    - MPI of u, the multiplicative inverse of p, mod q.

    Algorithm Specific Fields for DSA secret keys:
    - MPI of DSA secret exponent x.

    Algorithm Specific Fields for Elgamal secret keys:
    - MPI of Elgamal secret exponent x.

Secret MPI values can be encrypted using a passphrase.  If a
string-to-key specifier is given, that describes the algorithm for
converting the passphrase ignored by PGP 2.6.x and do not
   cause it to fail, providing a key, else a simple MD5 hash limited degree of the
passphrase is used.  Implementations SHOULD use a string-to-key
specifier; the simple hash is for backwards
   compatibility.  The cipher
for encrypting

5.5.1.3. Secret Key Packet (Tag 5)

   A Secret Key packet contains all the MPIs information that is specified found in a
   Public Key packet, including the secret public key packet.

Encryption/decryption of material, but also
   includes the secret data is done in CFB mode using key material after all the public key created from fields.

5.5.1.4. Secret Subkey Packet (Tag 7)

   A Secret Subkey packet (tag 7) is the passphrase and subkey analog of the Initial Vector from Secret
   Key packet, and has exactly the packet.
A different mode is used same format.

5.5.2. Public Key Packet Formats

   There are two versions of key-material packets. Version 3 packets
   were first generated by PGP 2.6. Version 2 packets are identical in
   format to Version 3 packets, but are generated by PGP 2.5 or before.
   V2 packets are deprecated and they MUST NOT be generated.

   PGP 5.0 introduced version 4 packets, with RSA keys new fields and semantics.
    PGP 2.6.x will not accept key-material packets with versions
   greater than 3.

   OpenPGP implementations SHOULD create keys with version 4 format. An
   implementation MAY generate a V3 key to ensure interoperability with
   old software; note, however, that V4 keys correct some security
   deficiencies in V3 keys. These deficiencies are described below. An
   implementation MUST NOT create a V3 key with a public key algorithm
   other than RSA.

   A version 3 public key formats.
With RSA keys, or public subkey packet contains:

     - A one-octet version number (3).

     - A four-octet number denoting the MPI bit count prefix (i.e., time that the first two octets) is
not encrypted.  Only key was created.

     - A two-octet number denoting the MPI non-prefix data time in days that this key is encrypted.
Furthermore, the CFB state
       valid. If this number is resynchronized at zero, then it does not expire.

     - A one-octet number denoting the beginning public key algorithm of each
new MPI value, so that the CFB block boundary is aligned with the start this key

     - A series of multi-precision integers comprising the MPI data.

With non-RSA keys, key
       material:

         - a simpler method is used.  All secret MPI values are
encrypted in CFB mode, including the multiprecision integer (MPI) of RSA public modulus n;

         - an MPI bitcount prefix.

The 16-bit checksum of RSA public encryption exponent e.

   V3 keys SHOULD only be used for backards compatibility because of
   three weaknesses in them. First, it is relatively easy to construct
   a V3 key that follows has the algorithm-specific portion same key ID as any other key because the key
   ID is simply the
algebraic sum, mod 65536, low 64 bits of the plaintext public modulus. Secondly,
   because the fingerprint of all a V3 key hashes the
algorithm-specific octets (including MPI prefix and data).  With RSA
keys, key material, but not
   its length, which increases the checksum is stored opportunity for fingerprint
   collisions. Third, there are minor weaknesses in the clear.  With non-RSA keys, the
checksum is encrypted like the algorithm-specific data.  This value is
used to check MD5 hash
   algorithm that the passphrase was correct.

5.6 Compressed Data Packet (Tag 8) make developers prefer other algorithms. See below
   for a fuller discussion of key IDs and fingerprints.

   The Compressed Data packet contains compressed data.  Typically, this
packet version 4 format is found as similar to the contents version 3 format except for
   the absence of an encrypted packet, or following a
Signature or One-Pass Signature packet, and contains literal data
packets.

The body of this packet consists of:
    - One octet that gives the algorithm used validity period.  This has been moved to compress the
   signature packet.
    - The remainder  In addition, fingerprints of the version 4 keys are
   calculated differently from version 3 keys, as described in section
   "Enhanced Key Formats."

   A version 4 packet is compressed data. contains:

     - A Compressed Data Packet's body contains an RFC1951 DEFLATE block that
compresses some set of packets.  See section "Packet Composition" for
details on how messages are formed.

5.7 Symmetrically Encrypted Data Packet (Tag 9)

The Symmetrically Encrypted Data packet contains data encrypted with a
conventional (symmetric-key) algorithm.  When it has been decrypted, it
will typically contain other packets (often literal data packets or
compressed data packets).

The body of this packet consists of: one-octet version number (4).

     - Encrypted data, the output of the selected conventional cipher
          operating in PGP's variant of Cipher Feedback (CFB) mode.

The conventional cipher used may be specified in an Encrypted Session
Key or Conventional Encrypted Session Key packet which precedes A four-octet number denoting the
Symmetrically Encrypted Data Packet.  In time that case, the cipher
algorithm octet is prepended to the session key before it is encrypted.
If no packets of these types precede the encrypted data, was created.

     - A one-octet number denoting the IDEA public key algorithm is used with the session of this key calculated as the MD5 hash

     - A series of multi-precision integers comprising the passphrase.

The data key
       material.  This algorithm-specific portion is:

       Algorithm Specific Fields for RSA public keys:

         - multiprecision integer (MPI) of RSA public modulus n;

         - MPI of RSA public encryption exponent e.

       Algorithm Specific Fields for DSA public keys:

         - MPI of DSA prime p;
         - MPI of DSA group order q (q is encrypted in CFB mode, with a CFB shift size equal to the
cipher's block size.  The Initial Vector (IV) is specified as all
zeros.  Instead prime divisor of using an IV, OP prefixes a 10 octet string to the
data before it is encrypted.  The first eight octets are random, p-1);

         - MPI of DSA group generator g;

         - MPI of DSA public key value y (= g**x where x is secret).

       Algorithm Specific Fields for Elgamal public keys:

         - MPI of Elgamal prime p;

         - MPI of Elgamal group generator g;

         - MPI of Elgamal public key value y (= g**x where x is
           secret).

5.5.3. Secret Key Packet Formats

   The Secret Key and Secret Subkey packets contain all the 9th and 10th octets are copies data of the 7th
   Public Key and 8th octets,
respectivelly. After encrypting the first 10 octets, Public Subkey packets, with additional
   algorithm-specific secret key data appended, in encrypted form.

   The packet contains:

     - A Public Key or Public Subkey packet, as described above

     - One octet indicating string-to-key usage conventions.  0
       indicates that the CFB state secret key data is
resynchronized if the cipher block size not encrypted.  255
       indicates that a string-to-key specifier is 8 octets or less. being given.  Any
       other value is a symmetric-key encryption algorithm specifier.

     - [Optional] If string-to-key usage octet was 255, a one-octet
       symmetric encryption algorithm.

     - [Optional] If string-to-key usage octet was 255, a string-to-key
       specifier.  The last
8 octets length of ciphertext are passed through the cipher and the block
boundary string-to-key specifier is reset.

The repetition of 16 bits in implied
       by its type, as described above.

     - [Optional] If secret data is encrypted, eight-octet Initial
       Vector (IV).

     - Encrypted multi-precision integers comprising the 80 bits secret key
       data. These algorithm-specific fields are as described below.

     - Two-octet checksum of random data prepended to the message allows plaintext of the receiver to immediately check whether the
session key is correct.

5.8 Marker Packet (Obsolete Literal Packet) (Tag 10)

An experimental version algorithm-specific
       portion (sum of PGP used this packet as all octets, mod 65536).

       Algorithm Specific Fields for RSA secret keys:

       - multiprecision integer (MPI) of RSA secret exponent d.

       - MPI of RSA secret prime value p.

       - MPI of RSA secret prime value q (p < q).

       - MPI of u, the Literal packet,
but no released version multiplicative inverse of PGP generated Literal packets with this tag.
With PGP 5.x, this packet has been re-assigned and is reserved p, mod q.

       Algorithm Specific Fields for use
as the Marker packet.

The body DSA secret keys:

       - MPI of this packet consists of: DSA secret exponent x.

       Algorithm Specific Fields for Elgamal secret keys:

       - The three octets 0x60, 0x47, 0x60 (which spell "PGP" in UTF-8).

Such a packet MUST be ignored when received.  It may be placed at the
beginning MPI of Elgamal secret exponent x.

   Secret MPI values can be encrypted using a message that uses features not available in PGP 2.6.X in
order to cause that version to report passphrase.  If a
   string-to-key specifier is given, that newer software necessary to
process describes the message.

5.9 Literal Data Packet (Tag 11)

A Literal Data packet contains algorithm for
   converting the body of a message; data that is not passphrase to be further interpreted.

The body a key, else a simple MD5 hash of this packet consists of:
    - A one-octet field that describes how the data is formatted.

If it
   passphrase is used.  Implementations SHOULD use a 'b' (0x62), then string-to-key
   specifier; the literal packet contains binary data. If
it simple hash is a 't' (0x74), then it contains text data, and thus may need line
ends converted to local form, or other text-mode changes.  RFC 1991
also defined a value of 'l' as a 'local' mode for machine-local
conversions.  This use backwards compatibility. The
   cipher for encrypting the MPIs is now deprecated.

    - File name as a string (one-octet length, followed by file name),
      if specified in the encrypted secret key
   packet.

   Encryption/decryption of the secret data should be saved as a file.

If is done in CFB mode using
   the special name "_CONSOLE" key created from the passphrase and the Initial Vector from the
   packet. A different mode is used, used with V3 keys (which are onlyRSA)
   than with other key formats. With V3 keys, the message MPI bit count prefix
   (i.e., the first two octets) is considered to be
"for your eyes only".  This advises that not encrypted.  Only the message MPI
   non-prefix data is unusually
sensitive, and the receiving program should process it more carefully,
perhaps avoiding storing encrypted.  Furthermore, the received data to disk, for example.

    - A four-octet number that indicates CFB state is
   resynchronized at the modification date beginning of each new MPI value, so that the
file, or
   CFB block boundary is aligned with the creation time start of the packet, or MPI data.

   With V4 keys, a zero that indicates simpler method is used.  All secret MPI values are
   encrypted in CFB mode, including the
present time.

    - MPI bitcount prefix.

   The remainder of 16-bit checksum that follows the packet is literal data.

Text data algorithm-specific portion is stored with <CR><LF> text endings (i.e. network-normal
line endings).  These should be converted
   the algebraic sum, mod 65536, of the plaintext of all the
   algorithm-specific octets (including MPI prefix and data).  With V3
   keys, the checksum is stored in the clear.  With V4 keys, the
   checksum is encrypted like the algorithm-specific data.  This value
   is used to native line endings by check that the
receiving software.

5.10 Trust passphrase was correct.

5.6. Compressed Data Packet (Tag 12) 8)

   The Trust Compressed Data packet contains compressed data. Typically, this
   packet is used only within keyrings found as the contents of an encrypted packet, or following
   a Signature or One-Pass Signature packet, and is not normally
exported.  Trust packets contain contains literal data
   packets.

   The body of this packet consists of:

     - One octet that record gives the user's
specifications algorithm used to compress the packet.

     - The remainder of which key holders are trustworthy introducers, along
with other information the packet is compressed data.

   A Compressed Data Packet's body contains an block that implementing software uses compresses
   some set of packets. See section "Packet Composition" for trust
information.

Trust details on
   how messages are formed.

   ZIP-compressed packets SHOULD NOT be emitted to output streams that are
transferred to other users, and they SHOULD compressed with raw RFC1951 DEFLATE
   blocks. Note that PGP V2.6 uses 13 bits of compression. If an
   implementation uses more bits of compression, it cannot be ignored on any input
other than local keyring files.

5.11 User ID
   decompressed by PGP V2.6

5.7. Symmetrically Encrypted Data Packet (Tag 13)

A User ID 9)

   The Symmetrically Encrypted Data packet consists of contains data which is intended to represent the
name and email address of the key holder.  By convention, encrypted with
   a symmetric-key algorithm. When it includes
an RFC822 mail name, but there are no restrictions on its content. has been decrypted, it will
   typically contain other packets (often literal data packets or
   compressed data packets).

   The body of this packet length in the header specifies consists of:

     - Encrypted data, the length output of the user name.  If
it is text, it is encoded in UTF-8.

6.  Radix-64 Conversions

As stated selected symmetric-key cipher
       operating in the introduction, OP's underlying native representation
for objects is a stream PGP's variant of arbitrary octets, and some systems desire
these objects to Cipher Feedback (CFB) mode.

   The symmetric cipher used may be immune to damage caused by character set
translation, data conversions, etc. specified in an Public-Key or
   Symmetric-Key Encrypted Session Key packet which precedes the
   Symmetrically Encrypted Data Packet.  In principle, any printable encoding scheme that met case, the requirements
of cipher
   algorithm octet is prefixed to the unsafe channel would suffice, since session key before it would not change the
underlying binary bit streams of the native OP data structures.  The OP
standard specifies one such printable encoding scheme to ensure
interoperability.

OP's Radix-64 encoding is composed of two parts: a base64 encoding
   encrypted.  If no packets of these types precede the binary encrypted data, and a checksum.  The base64 encoding
   the IDEA algorithm is identical to used with the MIME base64 content-transfer-encoding [RFC 2045, Section 6.8].  An
OP implementation MAY use ASCII Armor to protect session key calculated as the raw binary data.
   MD5 hash of the passphrase.

   The checksum data is encrypted in CFB mode, with a 24-bit CRC converted CFB shift size equal to four characters of radix-64
encoding by
   the same MIME base64 transformation, preceded by an equals
sign (=).  The CRC cipher's block size.  The Initial Vector (IV) is computed by specified as
   all zeros.  Instead of using the generator 0x864CFB and an
initialization of 0xB704CE.  The accumulation is done on IV, OpenPGP prefixes a 10 octet
   string to the data before it is converted to radix-64, rather than on encrypted.  The first eight octets
   are random, and the converted data.
A sample implementation 9th and 10th octets are copies of this algorithm is in the next section.

The checksum with its leading equal sign MAY appear on 7th and
   8th octets, respectivelly. After encrypting the first line
after 10 octets, the Base64 encoded data.

Rationale for CRC-24:  The
   CFB state is resynchronized if the cipher block size of 24 bits fits evenly into printable
base64. is 8 octets or
   less.  The nonzero initialization can detect more errors than a zero
initialization.

6.1 An Implementation last 8 octets of ciphertext are passed through the CRC-24 in "C"

#define CRC24_INIT 0xb704ce
#define CRC24_POLY 0x1864cfb

crc24 crc_bytes(unsigned char *bytes, size_t len)
{
    crc24 crc = CRC_INIT;
    int i;

    while (len--) {
        crc ^= *bytes++;
        for (i = 0; i < 8; i++) {
            crc <<= 1;
            if (crc & 0x1000000)
                crc ^= CRC24_POLY;
        }
    }
    return crc;
}

6.2 Forming ASCII Armor

When OP encodes data into ASCII Armor, it puts specific headers around
the data, so OP can reconstruct the data later.  OP informs cipher
   and the user
what kind of data block boundary is encoded reset.

   The repetition of 16 bits in the ASCII armor through the use 80 bits of random data prepended to
   the
headers.

Concatenating message allows the following data creates ASCII Armor:

        - An Armor Header Line, appropriate for receiver to immediately check whether the type of data
        - Armor Headers
        - A blank (zero-length, or containing only whitespace) line
        - The ASCII-Armored data
        - An Armor Checksum
        - The Armor Tail, which depends on the Armor Header Line.
   session key is incorrect.

5.8. Marker Packet (Obsolete Literal Packet) (Tag 10)

   An Armor Header Line consists experimental version of PGP used this packet as the appropriate header line text
surrounded by five (5) dashes ('-', 0x2D) on either side Literal
   packet, but no released version of PGP generated Literal packets
   with this tag. With PGP 5.x, this packet has been re-assigned and is
   reserved for use as the header
line text. Marker packet.

   The header line text body of this packet consists of:

     - The three octets 0x60, 0x47, 0x60 (which spell "PGP" in UTF-8).

   Such a packet MUST be ignored when received.  It may be placed at
   the beginning of a message that uses features not available in PGP
   2.6.x in order to cause that version to report that newer software
   is chosen based upon necessary to process the type message.

5.9. Literal Data Packet (Tag 11)

   A Literal Data packet contains the body of a message; data that is being encoded in Armor, and
   not to be further interpreted.

   The body of this packet consists of:

     - A one-octet field that describes how the data is formatted.

   If it is being encoded.  Header
line texts include a 'b' (0x62), then the following strings:

    BEGIN PGP MESSAGE               used for signed, encrypted, literal packet contains binary data.
   If it is a 't' (0x74), then it contains text data, and thus may need
   line ends converted to local form, or
                                    compressed files

    BEGIN PGP PUBLIC KEY BLOCK      used for armoring public keys

    BEGIN PGP PRIVATE KEY BLOCK     used for armoring private keys

    BEGIN PGP MESSAGE, PART X/Y     used other text-mode changes.  RFC
   1991 also defined a value of 'l' as a 'local' mode for multi-part messages, where machine-local
   conversions.  This use is now deprecated.

     - File name as a string (one-octet length, followed by file name),
       if the armor encrypted data should be saved as a file.

   If the special name "_CONSOLE" is split amongst Y parts,
                                    and this used, the message is considered to
   be "for your eyes only".  This advises that the Xth part out of Y.

    BEGIN PGP MESSAGE, PART X       used for multi-part messages, where
                                    this message data is
   unusually sensitive, and the Xth part of an
                                    unspecified number of parts.
                                    Requires receiving program should process it
   more carefully, perhaps avoiding storing the MESSAGE-ID Armor
                                    Header received data to be used.

    BEGIN PGP SIGNATURE             used disk,
   for detached signatures,
                                    OP/MIME signatures, and signatures
                                    following clearsigned messages

The Armor Headers are pairs of strings example.

     - A four-octet number that can give indicates the user or modification date of the
receiving OP message block some information about how to decode
       file, or use the message.  The Armor Headers are a part creation time of the armor, not packet, or a part zero that
       indicates the present time.

     - The remainder of the message, and hence are not protected by any signatures applied packet is literal data.

   Text data is stored with <CR><LF> text endings (i.e. network-normal
   line endings).  These should be converted to native line endings by
   the message. receiving software.

5.10. Trust Packet (Tag 12)

   The format of an Armor Header Trust packet is that of a key-value pair.  A colon
(':' 0x38) used only within keyrings and a single space (0x20) separate is not normally
   exported.  Trust packets contain data that record the key and value.  OP
should consider improperly formatted Armor Headers to be corruption user's
   specifications of
the ASCII Armor.  Unknown keys should which key holders are trustworthy introducers,
   along with other information that implementing software uses for
   trust information.

   Trust packets SHOULD NOT be reported emitted to the user, but OP
should continue output streams that are
   transferred to process the message.

Currently defined Armor Header Keys are:

    - "Version", other users, and they SHOULD be ignored on any input
   other than local keyring files.

5.11. User ID Packet (Tag 13)

   A User ID packet consists of data which states the OP Version used is intended to encode represent the
    message.

    - "Comment", a user-defined comment.

    - "MessageID", a 32-character string
   name and email address of printable characters.  The
    string must be the same for all parts of a multi-part message that
    uses key holder.  By convention, it
   includes an RFC822 mail name, but there are no restrictions on its
   content.  The packet length in the "PART X" Armor Header.  MessageID strings should be unique
    enough that header specifies the recipient length of
   the mail can associate all the parts
    of a message with each other.  A good checksum or cryptographic
    hash function user id. If it is sufficent.

    The MessageID should not appear unless text, it is encoded in a multi-part
    message. If it appears at all, it MUST be computed from the message UTF-8.

6. Radix-64 Conversions

   As stated in the introduction, OpenPGP's underlying native
   representation for objects is a deterministic fashion, rather than contain a purely random
    value.  This is stream of arbitrary octets, and some
   systems desire these objects to allow anyone be immune to determine damage caused by
   character set translation, data conversions, etc.

   In principle, any printable encoding scheme that met the MessageID
    cannot serve as a covert means
   requirements of leaking cryptographic key
    information. the unsafe channel would suffice, since it would not
   change the underlying binary bit streams of the native OpenPGP data
   structures.  The Armor Tail Line OpenPGP standard specifies one such printable
   encoding scheme to ensure interoperability.

   OpenPGP's Radix-64 encoding is composed in of two parts: a base64
   encoding of the same manner as binary data, and a checksum.  The base64 encoding is
   identical to the MIME base64 content-transfer-encoding [RFC 2045,
   Section 6.8]. An OpenPGP implementation MAY use ASCII Armor Header
Line, except to
   protect the string "BEGIN" raw binary data.

   The checksum is replaced a 24-bit CRC converted to four characters of
   radix-64 encoding by the string "END."

6.3 Encoding Binary in Radix-64 same MIME base64 transformation, preceded
   by an equals sign (=).  The encoding process represents 24-bit groups of input bits as output
strings of 4 encoded characters.  Proceeding from left to right, a
24-bit input group CRC is formed computed by concatenating three 8-bit input groups.
These 24 bits are then treated as four concatenated 6-bit groups, each using the generator
   0x864CFB and an initialization of which 0xB704CE.  The accumulation is translated into a single digit in the Radix-64 alphabet.
When encoding a bit stream with the Radix-64 encoding,
   done on the bit stream
must be presumed data before it is converted to be ordered with radix-64, rather than on
   the most-significant-bit first.
That is, the first bit converted data.  A sample implementation of this algorithm is in
   the stream will be the high-order bit in next section.

   The checksum with its leading equal sign MAY appear on the first 8-bit byte, and
   line after the eighth bit will be Base64 encoded data.

   Rationale for CRC-24: The size of 24 bits fits evenly into printable
   base64.  The nonzero initialization can detect more errors than a
   zero initialization.

6.1. An Implementation of the low-order bit CRC-24 in "C"

       #define CRC24_INIT 0xb704ce
       #define CRC24_POLY 0x1864cfb
       typedef long crc24;
       crc24 crc_octets(unsigned char *octets, size_t len)
       {
           crc24 crc = CRC24_INIT;
           int i;

           while (len--) {
               crc ^= *octets++;
               for (i = 0; i < 8; i++) {
                   crc <<= 1;
                   if (crc & 0x1000000)
                       crc ^= CRC24_POLY;
               }
           }
           return crc;
       }

6.2. Forming ASCII Armor

   When OpenPGP encodes data into ASCII Armor, it puts specific headers
   around the
first 8-bit byte, and data, so on.

         +--first octet--+-second octet--+--third octet--+
         |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
         +-----------+---+-------+-------+---+-----------+
         |5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|
         +--1.index--+--2.index--+--3.index--+--4.index--+

Each 6-bit group is used as an index into an array of 64 printable
characters from OpenPGP can reconstruct the table below.  The character referenced by data later. OpenPGP
   informs the index user what kind of data is placed encoded in the output string.

     Value Encoding  Value Encoding  Value Encoding  Value Encoding
         0 A            17 R            34 i            51 z
         1 B            18 S            35 j            52 0
         2 C            19 T            36 k            53 1
         3 D            20 U            37 l            54 2
         4 E            21 V            38 m            55 3
         5 F            22 W            39 n            56 4
         6 G            23 X            40 o            57 5
         7 H            24 Y            41 p            58 6
         8 I            25 Z            42 q            59 7
         9 J            26 a            43 r            60 8
        10 K            27 b            44 s            61 9
        11 L            28 c            45 t            62 +
        12 M            29 d            46 u            63 /
        13 N            30 e            47 v
        14 O            31 f            48 w         (pad) =
        15 P            32 g            49 x
        16 Q            33 h            50 y

The encoded output stream must be represented in lines of no more than
76 characters each.

Special processing is performed if fewer than 24 bits are available at ASCII armor
   through the end use of the headers.

   Concatenating the following data being encoded.  There are three possibilities: creates ASCII Armor:

     - The last An Armor Header Line, appropriate for the type of data group has 24 bits (3 octets).  No special processing is
needed.

     - The last data group has 16 bits (2 octets).  The first two 6-bit
groups are processed as above.  The third (incomplete) data group has
two zero-value bits added to it, and is processed as above. Armor Headers

     - A pad
character (=) is added to the output. blank (zero-length, or containing only whitespace) line

     - The last ASCII-Armored data group has 8 bits (1 octet).  The first 6-bit group is
processed as above.

     - An Armor Checksum

     - The second (incomplete) data group has four
zero-value bits added to it, and is processed as above.  Two pad
characters (=) are added to Armor Tail, which depends on the output.

6.4 Decoding Radix-64

Any characters outside Armor Header Line.

   An Armor Header Line consists of the base64 alphabet are ignored in Radix-64
data.  Decoding software must ignore all appropriate header line breaks or other
characters not found in the table above.

In Radix-64 data, characters other than those in text
   surrounded by five (5) dashes ('-', 0x2D) on either side of the table,
   header line
breaks, and other white space probably indicate a transmission error,
about which a warning message or even a message rejection might be
appropriate under some circumstances.

Because it text.  The header line text is used only for padding at chosen based upon the end
   type of data that is being encoded in Armor, and how it is being
   encoded. Header line texts include the data, following strings:

   BEGIN PGP MESSAGE
       Used for signed, encrypted, or compressed files

   BEGIN PGP PUBLIC KEY BLOCK
       Used for armoring public keys
   BEGIN PGP PRIVATE KEY BLOCK
       Used for armoring private keys

   BEGIN PGP MESSAGE, PART X/Y
       Used for multi-part messages, where the
occurrence of any "=" characters may be taken as evidence that armor is split amongst Y
       parts, and this is the end Xth part out of the data has been reached (without truncation in transit).  No such
assurance Y.

   BEGIN PGP MESSAGE, PART X
       Used for multi-part messages, where this is possible, however, when the number Xth part of octets transmitted
was a multiple an
       unspecified number of three and no "=" parts. Requires the MESSAGE-ID Armor
       Header to be used.

   BEGIN PGP SIGNATURE
       Used for detached signatures, OpenPGP/MIME signatures, and
       signatures following clearsigned messages

   The Armor Headers are pairs of strings that can give the user or the
   receiving OpenPGP implementation some information about how to
   decode or use the message.  The Armor Headers are a part of the
   armor, not a part of the message, and hence are not protected by any
   signatures applied to the message.

   The format of an Armor Header is that of a key-value pair.  A colon
   (':' 0x38) and a single space (0x20) separate the key and value.
   OpenPGP should consider improperly formatted Armor Headers to be
   corruption of the ASCII Armor.  Unknown keys should be reported to
   the user, but OpenPGP should continue to process the message.

   Currently defined Armor Header Keys are:

     - "Version", which states the OpenPGP Version used to encode the
       message.

     - "Comment", a user-defined comment.

     - "MessageID", a 32-character string of printable characters.  The
       string must be the same for all parts of a multi-part message
       that uses the "PART X" Armor Header.  MessageID strings should
       be unique enough that the recipient of the mail can associate
       all the parts of a message with each other. A good checksum or
       cryptographic hash function is sufficent.

       The MessageID SHOULD NOT appear unless it is in a multi-part
       message. If it appears at all, it MUST be computed from the
       finished (encrypted, signed, etc.) message in a deterministic
       fashion, rather than contain a purely random value.  This is to
       allow the legitimate recipient to determine that the MessageID
       cannot serve as a covert means of leaking cryptographic key
       information.

   The Armor Tail Line is composed in the same manner as the Armor
   Header Line, except the string "BEGIN" is replaced by the string
   "END."

6.3. Encoding Binary in Radix-64

   The encoding process represents 24-bit groups of input bits as
   output strings of 4 encoded characters. Proceeding from left to
   right, a 24-bit input group is formed by concatenating three 8-bit
   input groups. These 24 bits are then treated as four concatenated
   6-bit groups, each of which is translated into a single digit in the
   Radix-64 alphabet. When encoding a bit stream with the Radix-64
   encoding, the bit stream must be presumed to be ordered with the
   most-significant-bit first. That is, the first bit in the stream
   will be the high-order bit in the first 8-bit octet, and the eighth
   bit will be the low-order bit in the first 8-bit octet, and so on.

         +--first octet--+-second octet--+--third octet--+
         |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
         +-----------+---+-------+-------+---+-----------+
         |5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|
         +--1.index--+--2.index--+--3.index--+--4.index--+

   Each 6-bit group is used as an index into an array of 64 printable
   characters from the table below. The character referenced by the
   index is placed in the output string.

     Value Encoding  Value Encoding  Value Encoding  Value Encoding
         0 A            17 R            34 i            51 z
         1 B            18 S            35 j            52 0
         2 C            19 T            36 k            53 1
         3 D            20 U            37 l            54 2
         4 E            21 V            38 m            55 3
         5 F            22 W            39 n            56 4
         6 G            23 X            40 o            57 5
         7 H            24 Y            41 p            58 6
         8 I            25 Z            42 q            59 7
         9 J            26 a            43 r            60 8
        10 K            27 b            44 s            61 9
        11 L            28 c            45 t            62 +
        12 M            29 d            46 u            63 /
        13 N            30 e            47 v
        14 O            31 f            48 w         (pad) =
        15 P            32 g            49 x
        16 Q            33 h            50 y

   The encoded output stream must be represented in lines of no more
   than 76 characters each.

   Special processing is performed if fewer than 24 bits are available
   at the end of the data being encoded. There are three possibilities:

    1. The last data group has 24 bits (3 octets). No special
       processing is needed.

    2. The last data group has 16 bits (2 octets). The first two 6-bit
       groups are processed as above. The third (incomplete) data group
       has two zero-value bits added to it, and is processed as above.
       A pad character (=) is added to the output.

    3. The last data group has 8 bits (1 octet). The first 6-bit group
       is processed as above. The second (incomplete) data group has
       four zero-value bits added to it, and is processed as above. Two
       pad characters (=) are added to the output.

6.4. Decoding Radix-64

   Any characters outside of the base64 alphabet are ignored in
   Radix-64 data. Decoding software must ignore all line breaks or
   other characters not found in the table above.

   In Radix-64 data, characters other than those in the table, line
   breaks, and other white space probably indicate a transmission
   error, about which a warning message or even a message rejection
   might be appropriate under some circumstances.

   Because it is used only for padding at the end of the data, the
   occurrence of any "=" characters may be taken as evidence that the
   end of the data has been reached (without truncation in transit). No
   such assurance is possible, however, when the number of octets
   transmitted was a multiple of three and no "=" characters are
   present.

6.5. Examples of Radix-64

       Input data:  0x14fb9c03d97e
       Hex:     1   4    f   b    9   c     | 0   3    d   9    7   e
       8-bit:   00010100 11111011 10011100  | 00000011 11011001
       11111110
       6-bit:   000101 001111 101110 011100 | 000000 111101 100111
       111110
       Decimal: 5      15     46     28       0      61     37     62
       Output:  F      P      u      c        A      9      l      +

       Input data:  0x14fb9c03d9
       Hex:     1   4    f   b    9   c     | 0   3    d   9
       8-bit:   00010100 11111011 10011100  | 00000011 11011001
                                                       pad with 00
       6-bit:   000101 001111 101110 011100 | 000000 111101 100100
       Decimal: 5      15     46     28       0      61     36
                                                          pad with =
       Output:  F      P      u      c        A      9      k      =
       Input data:  0x14fb9c03
       Hex:     1   4    f   b    9   c     | 0   3
       8-bit:   00010100 11111011 10011100  | 00000011
                                              pad with 0000
       6-bit:   000101 001111 101110 011100 | 000000 110000
       Decimal: 5      15     46     28       0      48
                                                   pad with =      =
       Output:  F      P      u      c        A      w      =      =

6.6. Example of an ASCII Armored Message

  -----BEGIN PGP MESSAGE-----
  Version: OpenPGP 1.0

  yCoBc07MUy9RSMyrzM9LVchOTS1QSFQoTk0uSgUKFuWX5qUoZKQWpdpzAQA=
  =jYsF
  -----END PGP MESSAGE-----

   Note that this example is indented by two spaces.

7. Cleartext signature framework

   It is desirable to sign a textual octet stream without ASCII
   armoring the stream itself, so the signed text is still readable
   without special software. In order to bind a signature to such a
   cleartext, this framework is used.  (Note that RFC 2015 defines
   another way to clear sign messages for environments that support
   MIME.)

   The cleartext signed message consists of:

     - The cleartext header '-----BEGIN PGP SIGNED MESSAGE-----' on a
       single line,

     - Zero or more "Hash" Armor Headers,

     - Exactly one empty line not included into the message digest,

     - The dash-escaped cleartext that is included into the message
       digest,

     - The ASCII armored signature(s) including the Armor Header and
       Armor Tail Lines.

   If the "Hash" armor header is given, the specified message digest
   algorithm is used for the signature. If there are no such headers,
   SHA-1 is used. If more than one message digest is used in the
   signature, the "Hash" armor header contains a comma-delimited list
   of used message digests.

   Current message digest names are described below with the algorithm
   IDs.

7.1. Dash-Escaped Text

   The cleartext content of the message must also be dash-escaped.

   Dash escaped cleartext is the ordinary cleartext where every line
   starting with a dash '-' (0x2D) is prefixed by the sequence dash '-'
   (0x2D) and space ' ' (0x20). This prevents the parser from
   recognizing armor headers of the cleartext itself. The message
   digest is computed using the cleartext itself, not the dash escaped
   form.

   As with binary signatures on text documents, a cleartext signature
   is calculated on the text using canonical <CR><LF> line endings.
   The line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP
   SIGNATURE-----' line that terminates the signed text is not
   considered part of the signed text.

   Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of
   any line is ignored when the cleartext signature is calculated.

8. Regular Expressions

   A regular expression is zero or more branches, separated by '|'. It
   matches anything that matches one of the branches.

   A branch is zero or more pieces, concatenated. It matches a match
   for the first, followed by a match for the second, etc.

   A piece is an atom possibly followed by '*', '+', or '?'. An atom
   followed by '*' matches a sequence of 0 or more matches of the atom.
   An atom followed by '+' matches a sequence of 1 or more matches of
   the atom. An atom followed by '?' matches a match of the atom, or
   the null string.

   An atom is a regular expression in parentheses (matching a match for
   the regular expression), a range (see below), '.' (matching any
   single character), '^' (matching the null string at the beginning of
   the input string), '$' (matching the null string at the end of the
   input string), a '\' followed by a single character (matching that
   char- acter), or a single character with no other significance
   (matching that character).

   A range is a sequence of characters enclosed in '[]'. It normally
   matches any single character from the sequence. If the sequence
   begins with '^', it matches any single character not from the rest
   of the sequence. If two characters in the sequence are separated by
   '-', this is shorthand for the full list of ASCII characters between
   them (e.g. '[0-9]' matches any decimal digit). To include a literal
   ']' in the sequence, make it the first character (following a
   possible '^').  To include a literal '-', make it the first or last
   character.

9. Constants

   This section describes the constants used in OpenPGP.

   Note that these tables are not exhaustive lists; an implementation
   MAY implement an algorithm not on these lists.

   See the section "Notes on Algorithms" below for more discussion of
   the algorithms.

9.1. Public Key Algorithms

       ID           Algorithm
       --           ---------
       1          - RSA (Encrypt or Sign)
       2          - RSA Encrypt-Only
       3          - RSA Sign-Only
       16         - Elgamal (Encrypt-Only), see [ELGAMAL]
       17         - DSA (Digital Signature Standard)
       18         - Elliptic Curve
       19         - ECDSA
       20         - Elgamal (Encrypt or Sign)
       21         - Diffie-Hellman (X9.42)
       100 to 110 - Private/Experimental algorithm.

   Implementations MUST implement DSA for signatures, and Elgamal for
   encryption. Implementations SHOULD implement RSA keys.
   Implementations MAY implement any other algorithm.

9.2. Symmetric Key Algorithms

       ID           Algorithm
       --           ---------
       0          - Plaintext or unencrypted data
       1          - IDEA
       2          - Triple-DES (DES-EDE, as per spec -
                    168 bit key derived from 192)
       3          - CAST5 (128 bit key)
       4          - Blowfish (128 bit key, 16 rounds)
       5          - SAFER-SK128 (13 rounds)
       6          - DES/SK
       100 to 110 - Private/Experimental algorithm.

   Implementations MUST implement Triple-DES. Implementations SHOULD
   implement IDEA and CAST5.Implementations MAY implement any other
   algorithm.

9.3. Compression Algorithms

       ID           Algorithm
       --           ---------
       0          - Uncompressed
       1          - ZIP
       100 to 110 - Private/Experimental algorithm.

   Implementations MUST implement uncompressed data. Implementations
   SHOULD implement ZIP.

9.4. Hash Algorithms

       ID           Algorithm                  Text Name
       --           ---------                  ---- ----
       1          - MD5                        "MD5"
       2          - SHA-1                      "SHA1"
       3          - RIPE-MD/160                "RIPEMD160"
       4          - HAVAL (5 pass, 160-bit)    "HAVAL-5-160"
       5          - MD2                        "MD2"
       100 to 110 - Private/Experimental algorithm.

   Implementations MUST implement SHA-1. Implementations SHOULD
   implement MD5.

10. Packet Composition

   OpenPGP packets are assembled into sequences in order to create
   messages

   and to transfer keys.  Not all possible packet sequences are
   meaningful and correct.  This describes the rules for how packets
   should be placed into sequences.

10.1. Transferable Public Keys

   OpenPGP users may transfer public keys. The essential elements of a
   transferable public key are:

     - One Public Key packet

     - Zero or more revocation signatures

     - One or more User ID packets

     - After each User ID packet, zero or more Signature packets

     - Zero or more Subkey packets

     - After each Subkey packet, one or more Signature packets
   The Public Key packet occurs first.  Each of the following User ID
   packets provides the identity of the owner of this public key.  If
   there are present.

6.5 Examples multiple User ID packets, this corresponds to multiple
   means of identifying the same unique individual user; for example, a
   user may have more than one email address, and construct a User ID
   for each one.

   Immediately following each User ID packet, there are zero or more
   signature packets. Each signature packet is calculated on the
   immediately preceding User ID packet and the initial Public Key
   packet. The signature serves to certify the corresponding public key
   and user ID.  In effect, the signer is testifying to his or her
   belief that this public key belongs to the user identified by this
   user ID.

   After the User ID packets there may be one or more Subkey packets.
   In general, subkeys are provided in cases where the top-level public
   key is a signature-only key.  However, any V4 key may have subkeys,
   and the subkeys may be encryption-only keys, signature-only keys, or
   general-purpose keys.

   Each Subkey packet must be followed by at least one Signature
   packet, which should be of the subkey binding signature type, issued
   by the top level key.

   Subkey and Key packets may each be followed by a revocation
   Signature packet to indicate that the key is revoked.  Revocation
   signatures are only accepted if they are issued by the key itself,
   or by a key which is authorized to issue revocations via a
   revocation key subpacket in a self-signature by the top level key.

   Transferable public key packet sequences may be concatenated to
   allow transferring multiple public keys in one operation.

10.2. OpenPGP Messages

   An OpenPGP message is a packet or sequence of Radix-64

Input data:  0x14fb9c03d97e
Hex:     1   4    f   b    9   c     | 0   3    d   9    7   e
8-bit:   00010100 11111011 10011100  | 00000011 11011001 11111110
6-bit:   000101 001111 101110 011100 | 000000 111101 100111 111110
Decimal: 5      15     46     28       0      61     37     63
Output:  F      P      u      c        A      9      l      /

Input data:  0x14fb9c03d9
Hex:     1   4    f   b    9   c packets that
   corresponds to the following grammatical rules (comma represents
   sequential composition, and vertical bar separates alternatives):

   OpenPGP Message :- Encrypted Message | 0   3    d   9
8-bit:   00010100 11111011 10011100 Signed Message | 00000011 11011001
                                                pad with 00
6-bit:   000101 001111 101110 011100
                      Compressed Message | 000000 111101 100100
Decimal: 5      15     46     28       0      61     36
                                                   pad with =
Output:  F      P      u      c        A      9      k      =

Input data:  0x14fb9c03
Hex:     1   4    f   b    9   c Literal Message.

   Compressed Message :- Compressed Data Packet.

   Literal Message :- Literal Data Packet.

   ESK :- Pubic Key Encrypted Session Key Packet | 0   3
8-bit:   00010100 11111011 10011100
          Symmetric-Key Encrypted Session Key Packet.

   ESK Sequence :- ESK | 00000011
                                       pad with 0000
6-bit:   000101 001111 101110 011100 ESK Sequence, ESK.

   Encrypted Message :- Symmetrically Encrypted Data Packet | 000000 110000
Decimal: 5      15     46     28       0      48
                                            pad with =      =
Output:  F      P      u      c        A      w      =      =

6.6 Example
               ESK Sequence, Symmetrically Encrypted Data Packet.

   One-Pass Signed Message :- One-Pass Signature Packet,
               OpenPGP Message, Signature Packet.

   Signed Message :- Signature Packet, OpenPGP Message |
               One-Pass Signed Message.

   In addition, decrypting a Symmetrically Encrypted Data packet and

   decompressing a Compressed Data packet must yield a valid OpenPGP
   Message.

11. Enhanced Key Formats

11.1. Key Structures

   The format of an ASCII Armored Message

  -----BEGIN PGP MESSAGE-----
  Version: OP V0.0

  owFbx8DAYFTCWlySkpkHZDKEFCXmFedmFhdn5ucpZKdWFiv4hgaHKPj5hygUpSbn
  l6UWpabo8XIBAA==
  =3m1o
  -----END PGP MESSAGE-----

Note that this example OpenPGP V3 key is indented by two spaces.

7.  Cleartext as follows.  Entries in square
   brackets are optional and ellipses indicate repetition.

           RSA Public Key
              [Revocation Self Signature]
               User ID [Signature ...]
              [User ID [Signature ...] ...]

   Each signature framework

It is desirable to sign a textual octet stream without ASCII armoring certifies the stream itself, so RSA public key and the signed text is still readable without special
software.  In order to bind a signature to such a cleartext, this
framework preceding user
   ID. The RSA public key can have many user IDs and each user ID can
   have many signatures.

   The format of an OpenPGP V4 key that uses two public keys is used. (Note similar
   except that RFC 2015 defines another way the other keys are added to clear
sign messages for environments that support MIME.)

The cleartext signed message consists of:
  - The cleartext header '-----BEGIN PGP SIGNED MESSAGE-----' on a
    single line,
  - Zero or more "Hash" Armor Headers,
  - Exactly one empty line not included into the message digest,
  - The dash-escaped cleartext end as 'subkeys' of the
   primary key.

           Primary-Key
              [Revocation Self Signature]
              [Direct Key Self Signature...]
               User ID [Signature ...]
              [User ID [Signature ...] ...]
              [Subkey Primary-Key-Signature ...]

   A subkey always has a single signature after it that is included into the message digest,
  - The ASCII armored signature(s) including the Armor Header and Armor
    Tail Lines.

If issued using
   the "Hash" armor header is given, primary key to tie the specified message digest
algorithm is used for two keys together.  The new format can
   use either the signature.  If there are no such headers,
SHA-1 is used.  If more than one message digest is used in new signature packets or the
signature, old signature packets.

   In a key that has a main key and subkeys, the "Hash" armor header contains primary key MUST be a comma-delimited list
   key capable of
used message digests.

Current message digest names are:

    - "SHA1"
    - "MD5"
    - "RIPEMD160" signing. The cleartext content subkeys may be keys of the message must also any other type.
   There may be dash-escaped.

Dash escaped cleartext is the ordinary cleartext where every line
starting other constructions of V4 keys, too. For example, there
   may be a single-key RSA key in V4 format, a DSA primary key with an
   RSA encryption key, or RSA primary key with an Elgamal subkey, etc.

   It is also possible to have a dash '-' (0x2D) signature-only subkey. This permits a
   primary key that collects certifications (key signatures) but is prefixed by the sequence dash '-'
(0x2D)
   used only used for certifying subkeys that are used for encryption
   and space ' ' (0x20).  This prevents signatures.

11.2. Key IDs and Fingerprints

   For a V3 key, the parser from recognizing
armor headers eight-octet key ID consists of the low 64 bits of
   the cleartext itself. public modulus of the RSA key.

   The message digest fingerprint of a V3 key is computed
using formed by hashing the cleartext itself, body (but not
   the dash escaped form.

As two-octet length) of the MPIs that form the key material (public
   modulus n, followed by exponent e) with binary signatures on text documents, a cleartext signature MD5.

   A V4 fingerprint is
calculated on the text using canonical <CR><LF> line endings.  The line
ending (i.e. 160-bit SHA-1 hash of the <CR><LF>) before one-octet Packet
   Tag, followed by the '-----BEGIN PGP SIGNATURE-----'
line that terminates two-octet packet length, followed by the signed text is not considered part of entire
   Public Key packet starting with the
signed text.

Also, any trailing whitespace (spaces, and tabs, 0x09) at version field.  The key ID is
   either the end low order 64 bits of
any line is ignored when the cleartext signature is calculated.

8.  Regular Expressions

A regular expression is zero or more branches, separated by `|'.  It
matches anything that matches one fingerprint.  Here are the
   fields of the branches.

A branch is zero or more pieces, concatenated.  It matches a match for hash material, with the first, followed by example of a match DSA key:

  a.1) 0x99 (1 octet)

  a.2) high order length octet of (b)-(f) (1 octet)

  a.3) low order length octet of (b)-(f) (1 octet)

    b) version number = 4 (1 octet);

    c) time stamp of key creation (4 octets);

    d) algorithm (1 octet): 7 = DSA (example);

    e) Algorithm specific fields.

   Algorithm Specific Fields for the second, etc.

A piece is an atom possibly followed by `*', `+', or `?'. An atom
followed by `*' matches a sequence DSA keys (example):

  e.1) MPI of 0 or more matches DSA prime p;

  e.2) MPI of the atom.
An atom followed by `+' matches DSA group order q (q is a sequence prime divisor of 1 or more matches p-1);

  e.3) MPI of the
atom.  An atom fol- lowed by `?' matches a match DSA group generator g;

  e.4) MPI of the atom, or the
null string.

An atom DSA public key value y (= g**x where x is a regular expression in parentheses (matching a match secret).

   Note that it is possible for
the regular expression), a range (see below), `.' (matching any single
character), `^' (matching the null string at the beginning of the input
string), `$' (matching the null string at the end there to be collisions of the input string),
a `\' followed by a single character (matching that char- acter), or a
single character key IDs --
   two different keys with no other significance (matching the same key ID. Note that character).

A range there is a sequence of characters enclosed in `[]'.  It normally
matches any single character from the sequence. If much
   smaller, but still non-zero probability that two different keys have
   the sequence begins
with `^', it matches any single character not from same fingerprint.

   Also note that if V3 and V4 format keys share the rest same RSA key
   material, they will have different keyids as well as different
   fingerprints.

12. Notes on Algorithms

12.1. Symmetric Algorithm Preferences

   The symmetric algorithm preference is an ordered list of algorithms
   that the
sequence.  If two char- acters in the sequence are separated by `-',
this keyholder accepts. Since it is found on a self-signature,
   it is possible that a keyholder may have different preferences. For
   example, Alice may have TripleDES only specified for
   "alice@work.com" but CAST5, Blowfish, and TripleDES specified for
   "alice@home.org". Note that it is shorthand also possible for the full list of ASCII characters between them
(e.g. `[0-9]' matches any decimal digit).  To include a literal `]' preferences to
   be in a subkey's binding signature.

   Since TripleDES is the sequence, make MUST-implement algorithm, if it is not
   explicitly in the first character (following a possible `^').
To include a literal `-', make it the first or last character.

9.  Constants

This section describes list, it is tacitly at the constants used in OP. end. However, it is
   good form to place it there explicitly. Note also that these tables are not exhaustive lists; if an
   implementation MAY does not implement an the preference, then it is
   implicitly a TripleDES-only implementation.

   An implementation MUST not use a symmetric algorithm that is not on these lists.

9.1 Public Key Algorithms

1          - RSA (Encrypt or Sign)
2          - RSA Encrypt-Only
3          - RSA Sign-Only
16         - Elgamal, see [ELGAMAL]
17         - DSA (Digital Signature Standard)
18         - Elliptic Curve
19         - ECDSA
21         - Diffie-Hellman (X9.42)
100 to 110 - Private/Experimental algorithm.

Implementations MUST implement DSA for signatures, and Elgamal for
encryption.  Implementations SHOULD implement RSA encryption.
Implementations MAY implement any other algorithm.

9.2 Symmetric Key Algorithms

0          - Plaintext
1          - IDEA
2          - Triple-DES (DES-EDE, as per spec -
             168 bit key derived from 192)
3          - CAST5 (128 bit key)
4          - Blowfish (128 bit key, 16 rounds)
5          - ROT-N (128 bit N)
6          - SAFER-SK128
7          - DES/SK
100 in
   the recipent's preference list. When encrypting to 110 - Private/Experimental algorithm.

Implementations MUST implement Triple-DES. Implementations SHOULD
implement IDEA and CAST5.Implementations MAY implement more than one
   recipient, the implementation finds a suitable algorithm by taking
   the intersection of the preferences of the recipients. Note that the
   MUST-implement algorithm, TripleDES, ensures that the intersection
   is not null. The implementation may use any other
algorithm.

9.3 Compression Algorithms

0          - Uncompressed
1          - ZIP
100 mechanism to 110 - Private/Experimental algorithm.

Implementations MUST implement uncompressed data. Implementations pick an
   algorithm in the intersection.

   If an implementation can decrypt a message that a keyholder doesn't
   have in their preferences, the implementation SHOULD implement ZIP.

9.4 Hash Algorithms

1          - MD5
2          - SHA-1
3          - RIPE-MD/160
4          - HAVAL
100 to 110 - Private/Experimental algorithm.

Implementations decrypt the
   message anyway, but MUST implement SHA-1. Implementations SHOULD implement
MD5.

10.  Packet Composition

OP packets are assembled into sequences warn the keyholder than protocol has been
   violated. (For example, suppose that Alice, above, has software that
   implements all algorithms in order this specification. Nonetheless, she
   prefers subsets for work or home. If she is sent a message encrypted
   with IDEA, which is not in her preferences, the software warns her
   that someone sent her an IDEA-encrypted message, but it would
   ideally decrypt it anyway.)

   An implementation that is striving for backwards compatibility MAY
   consider a V3 key with a V3 self-signature to create messages be an implicit
   preference for IDEA, and no ability to transfer keys.  Not all possible packet sequences are meaningful and
correct. do TripleDES. This describes the rules for how packets should is
   technically non-compliant, so if an implementation is forming a
   message to be placed
into sequences.

10.1 Transferable Public Keys

OP users may transfer public keys.  The essential elements of read by a
transferable public key are:

    - One Public Key packet
    - Zero or more revocation signatures
    - One or more User ID packets
    - After each User ID packet, zero or more Signature packets
    - Zero or more Subkey packets
    - After each Subkey packet, one V3 keyholder and a V4 keyholder that does
   not speak IDEA, the implementation must somehow break this up into
   two messages (which is relatively easy to do for email), or more Signature packets

The Public Key packet occurs first.  Each of issue an
   error message when this is not possible.

12.2. Other Algorithm Preferences

   Other algorithm preferences work similarly to the following User ID
packets provides symmetric
   algorithm preference, in that they specify which algorithms the identity of
   keyholder accepts. There are two interesting cases that other
   comments need to be made about, though, the owner compression preferences
   and the hash preferences.

12.2.1. Compression Preferences

   Compression has been an integral part of PGP since its first days.
   OpenPGP and all previous versions of PGP have offered compression.
   And in this public key.  If
there are multiple User ID packets, this corresponds specification, the default is for messages to multiple means
of identifying be
   compressed, although an implementation is not required to do so.
   Consequently, the same unique individual user; compression preference gives a way for example, a user may
enjoy keyholder
   to request that messages not be compressed, presumably because they
   are using a minimal implementation that does not include
   compression.

12.2.2. Hash Algorithm Preferences

   Typically, the use choice of more a hash algorithm is something the signer
   does, rather than one e-mail address, and construct the verifier, because a User ID
packet for each one.

Immediately following each User ID packet, there are zero or more
signature packets.  Each signature packet signer does not typically
   know who is calculated on going to be verifying the signature. This preference,
   though, allows a protocol based upon digital signatures ease in
   negotiation.

   Thus, if Alice is authenticating herself to Bob with a signature, it
   makes sense for her to use a hash algorithm that Bob's software
   uses. This preference allows Bob to state in his key which
   algorithms Alice may use.

12.3. Plaintext

   Algorithm 0, "plaintext," may only be used to denote secret keys
   that are stored in the
immediately preceding User ID packet clear. Implementations must not use plaintext
   in Symmetrically Encrypted Data Packets; they must use Literal Data
   Packets to encode unencrypted or literal data.

12.4. RSA

   There are algorithm types for RSA-signature-only, and the initial Public Key packet.
   RSA-encrypt-only keys. These types are deprecated. The "key flags"
   subpacket in a signature serves is a much better way to certify express the corresponding public key same
   idea, and user
ID.  In effect, the signer generalizes it to all algorithms. An implementation SHOULD
   NOT create such a key, but MAY interpret it.

   An implementation SHOULD NOT implement RSA keys of size less than
   768 bits.

   It is testifying permissable for an implementation to his or her belief support RSA merely for
   backwards compatibility; for example, such an implementation would
   support V3 keys with IDEA symmetric cryptography. Note that this
public key belongs is
   an exception to the user identified by this user ID.

After the User ID packets there may be one or more Subkey packets. In
general, subkeys are provided other MUST-implement rules. An implementation
   that supports RSA in cases where V4 keys MUST implement the top-level public MUST-implement
   features.

12.5. Elgamal

   If an Elgamal key is a signature-only key.  However, any V4 key may have subkeys, and the
subkeys may to be encryption-only keys, signature-only keys, or
general-purpose keys.

Each Subkey packet used for both signing and encryption,
   extra care must be followed by at least one Signature packet,
which should be of the subkey binding signature type, issued by taken in creating the top
level key.

Subkey

   An ElGamal key consists of a generator g, a prime modulus p, a
   secret exponent x, and Key packets may each be followed by a revocation Signature
packet to indicate public value y = g^x mod p.

   The generator and prime must be chosen so that solving the key discrete
   log problem is revoked.  Revocation signatures are
only accepted if they are issued by intractable.  The group g should generate the key itself,
   multiplicative group mod p-1 or by a key which
is authorized to issue revocations via a revocation key subpacket in a
self-signature by large subgroup of it, and the top level key.

Transferable public key packet sequences may be concatenated to allow
transferring multiple public keys in
   order of g should have at least one operation.

10.2 OP Messages

An OP message large prime factor.  A good
   choice is to use a packet or sequence of packets "strong" Sophie-Germain prime in choosing p, so
   that corresponds to
the following grammatical rules (comma represents sequential
composition, both p and vertical bar separates alternatives):

   OP Message :- Encrypted Message | Signed Message | Compressed Message
                                   | Literal Message.

   Compressed Message :- Compressed Data Packet.

   Literal Message :- Literal Data Packet.

   ESK :- Pubic Key Encrypted Session Key Packet |
          Conventionally Encrypted Session Key Packet.

   ESK Sequence :- ESK | ESK Sequence, ESK.

   Encrypted Message :- Symmetrically Encrypted Data Packet |
               ESK Sequence, Symmetrically Encrypted Data Packet.

   One-Pass Signed Message :- One-Pass Signature Packet, OP Message,
               Signature Packet.

   Signed Message :- Signature Packet, OP Message |
               One-Pass Signed Message. (p-1)/2 are primes.

   In addition, decrypting a Symmetrically Encrypted Data packet and
decompressing a Compressed Data packet must yield a valid OP Message.

11.  Enhanced Key Formats

11.1 Key Structures

The format result of V3 OP key using RSA is as follows.  Entries in square
brackets are optional and ellipses indicate repetition.

    RSA Public Key
       [Revocation Self Signature]
        User ID [Signature ...]
       [User ID [Signature ...] ...]

Each signature certifies the RSA public key and Bleichenbacher [BLEICHENBACHER] shows that
   if the preceding user ID.
The RSA public key can have many user IDs generator g has only small prime factors, and each user ID if g divides
   the order of the group it generates, then signatures can have
many signatures.

The format be forged.
   In particular, choosing g=2 is a bad choice if the group order may
   be even. On the other hand, a generator of 2 is a fine choice for an OP V4 key
   encryption-only key, as this will make the encryption faster.

   While verifying Elgamal signatures, note that uses two public keys it is very similar
except important to
   test that r and s are less than p.  If this test is not done then
   signatures can be trivially forged by using large r values of
   approximately twice the second key length of p.  This attack is added to also discussed
   in the end as Bleichenbacher paper.

   Details on safe use of Elgamal signatures may be found in [MENEZES],
   which discusses all the weaknesses described above.

   If an implementation allows Elgamal signatures, then it MUST use the
   algorithm identifier 20.

   An implementation SHOULD NOT implement Elgamal keys of size less
   than 768 bits. For long-term security, Elgamal keys should be 1024
   bits or longer.

12.6. DSA

   An implementation SHOULD NOT implement DSA keys of size less than
   768 bits. Note that present DSA is limited to a maximum of 1024 bit
   keys, which are recommended for long-term use.

12.7. OpenPGP CFB mode

   OpenPGP does symmetric encryption using a 'subkey' variant of Cipher Feedback
   Mode (CFB mode). This section describes the
primary key.

    Primary-Key
       [Revocation Self Signature]
       [Direct Key Self Signature...]
        User ID [Signature ...]
       [User ID [Signature ...] ...]

[Subkey Primary-Key-Signature]

The subkey always has procedure it uses in
   detail.

   OpenPGP CFB mode uses an initialization vector (IV) of all zeros,
   and prefixes the plaintext with ten bytes of random data, such that
   bytes 9 and 10 match bytes 7 and 8.  It does a single signature CFB "resync" after it
   encrypting those ten bytes.

   Note that is issued using
the primary key to tie the two keys together.  The new format can use
either the new signature packets or the old signature packets.

In for an key algorithm that has a main key and subkeys, larger block size than 64
   bits, the primary key MUST equivalent function will be a
key capable of signing. done with that entire block.

   Step by step, here is the procedure:

   1.  The subkeys may be keys of any other type, and
either version 3 or 4 of feedback register (FR) is set to the signature packet can be used.  There may
be other types of V4 keys, too. For example, there may be a single-key
RSA key in V4 format, a DSA primary key with an RSA encryption key,
etc, or RSA primary key with an Elgamal subkey.

It IV, which is also possible all zeros.

   2.  FR is encrypted to have a signature-only subkey. produce FRE (FR Encrypted).  This permits a
primary key that collects certifications (key signatures) but is used
only used for certifying subkeys that are used for the
       encryption and
signatures.

11.2 V4 Key IDs and Fingerprints

A V4 fingerprint of an all-zero value.

   3.  FRE is xored with the 160-bit SHA-1 hash first 8 bytes of random data prefixed to
       the one-octet Packet Tag,
followed by the two-octet packet length, followed by plaintext to produce C1-C8, the entire Public
Key packet starting first 8 bytes of ciphertext.

   4.  FR is loaded with C1-C8.

   5.  FR is encrypted to produce FRE, the version field. encryption of the first 8
       bytes of ciphertext.

   6.  The key ID left two bytes of FRE get xored with the next two bytes of
       data which were prepended to the plaintext.  This produces
       C9-C10, the next two bytes of ciphertext.

   7.  (The resync step) FR is loaded with C3-C10.

   8.  FR is either encrypted to produce FRE.

   9.  FRE is xored with the
low order 32 bits or 64 bits first 8 bytes of the fingerprint.  Here are given plaintext, now
       that we have finished encrypting the fields 10 bytes of prepended data.
        This produces C11-C18, the hash material, next 8 bytes of ciphertext.

  10.  FR is loaded with C11-C18

  11.  FR is encrypted to produce FRE.

  12.  FRE is xored with the example of a DSA key:

    a.1) 0x99 (1 byte)
    a.2) high order length byte of (b)-(f) (1 byte)
    a.3) low order length byte of (b)-(f) (1 byte)
    b) version number = 4 (1 byte);
    c) time stamp of key creation (4 bytes);
    e) algorithm (1 byte):
         17 = DSA;
    f) Algorithm specific fields.

    Algorithm Specific Fields for DSA keys (example):
    f.1) MPI next 8 bytes of DSA prime p;
    f.2) MPI plaintext, to produce the
       next 8 bytes of DSA group order q (q ciphertext.  These are loaded into FR and the
       process is a prime divisor of p-1);
    f.3) MPI of DSA group generator g;
    f.4) MPI of DSA public key value y (= g**x where x repeated until the plaintext is secret).

12. used up.

13. Security Considerations

   As with any technology involving cryptography, you should check the
   current literature to determine if any algorithms used here have
   been found to be vulnerable to attack.

   This specification uses Public Key Cryptography technologies.
   Possession of the private key portion of a public-private key pair
   is assumed to be controlled by the proper party or parties.

   Certain operations in this specification involve the use of random
   numbers.  An appropriate entropy source should be used to generate
   these numbers.  See RFC 1750.

   The MD5 hash algorithm has been found to have weaknesses
   (pseudo-collisions in the compress function) that make some people
   deprecate its use.  They consider the SHA-1 algorithm better.

   The DSA algorithm will work with any 160-bit hash, but it is
   sensitive to the quality of the hash algorithm, if the hash
   algorithm is broken, it can leak the secret key. The Digital
   Signature Standard (DSS) specifies that DSA be used with SHA-1.
   RIPEMD-160 is considered by many cryptographers to be as strong. An
   implementation should take care which hash algorithms are used with
   DSA, as a weak hash can not only allow a signature to be forged, but
   could leak the secret key.

   If you are building an authentication system, the recipient may
   specify a preferred signing algorithm. However, the signer would be
   foolish to use a weak algorithm simply because the recipient
   requests it.

   Some of the encryption algorithms mentioned in this document have
   been analyzed less than others.  For example, although CAST5 is
   presently considered strong, it has been analyzed less than
   Triple-DES. Other algorithms may have other controversies
   surrounding them.

   Some technologies mentioned here may be subject to government
   control in some countries.

13.

14. Authors and Working Group Chair

   The working group can be contacted via the current chair:

       John W. Noerenberg, II
       Qualcomm, Inc
       6455 Lusk Blvd
       San Diego, CA 92131 USA
       Email: jwn2@qualcomm.com
       Tel: +1 619-658-3510

   The principal authors of this draft are (in alphabetical order): are:

       Jon Callas
       Network Associates, Inc.
       4200 Bohannon Drive
       Menlo Park, CA 94025, USA
       Email: jon@pgp.com
       Tel: +1-650-473-2860

       Lutz Donnerhacke
       IKS GmbH
       Wildenbruchstr. 15
       07745 Jena, Germany
       EMail: lutz@iks-jena.de
       Tel: +49-3641-675642

       Hal Finney
       Network Associates, Inc.
       4200 Bohannon Drive
       Menlo Park, CA 94025, USA
       Email: hal@pgp.com

       Rodney Thayer
       Sable Technology Corporation
       246 Walnut Street
       Newton, MA  02160 USA
       Email: rodney@sabletech.com
       Tel: +1-617-332-7292

   This draft also draws on much previous work from a number of other
   authors who include: Derek Atkins, Charles Breed, Dave Del Torto,
   Marc Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Raph
   Levine, Colin Plumb, Will Price, William Stallings, Mark Weaver, and
   Philip R. Zimmermann.

14.

15. References

   [BLEICHENBACHER] Bleichenbacher, Daniel, "Generating ElGamal
   signatures without knowing the secret key," Eurocrypt 96.  Note that
   the version in the proceedings has an error.  A revised version is
   available at the time of writing from
   <ftp://ftp.inf.ethz.ch/pub/publications/papers/ti/isc/ElGamal.ps>

   [DONNERHACKE] Donnerhacke, L., et. al, "PGP263in - an improved
   international version of PGP",
   ftp://ftp.iks-jena.de/mitarb/lutz/crypt/software/pgp/

   [ELGAMAL] T. ElGamal, "A Public-Key Cryptosystem and a Signature
   Scheme Based on Discrete Logarithms," IEEE Transactions on
   Information Theory, v. IT-31, n. 4, 1985, pp. 469-472.

   [ISO-10646]    ISO/IEC 10646-1:1993. International Standard --
   Information technology -- Universal Multiple-Octet Coded Character
   Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane.
   UTF-8 is described in Annex R, adopted but not yet published.
   UTF-16 is described in Annex Q, adopted but not yet published.

   [MENEZES] Alfred Menezes, Paul van Oorschot, and Scott Vanstone,
   "Handbook of Applied Cryptography," CRC Press, 1996.

   [PKCS1] RSA Laboratories, "PKCS #1: RSA Encryption Standard,"
   version 1.5, November 1993

   [RFC822] D. Crocker, "Standard for the format of ARPA Internet text
   messages", RFC 822, August 1982
   [RFC1423] D. Balenson, "Privacy Enhancement for Internet Electronic
   Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423,
   October 1993

   [RFC1641] Goldsmith, D., and M. Davis, "Using Unicode with MIME",
   RFC 1641, Taligent inc., July 1994.

   [RFC1750] Eastlake, Crocker, & Schiller., Randomness Recommendations
   for Security. December 1994.

   [RFC1951] Deutsch, P., DEFLATE Compressed Data Format Specification
   version 1.3. May 1996.

   [RFC1983] G. Malkin., Internet Users' Glossary. August 1996.

   [RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message
   Exchange Formats", RFC 1991, August 1996.

   [RFC2015] Elkins, M., "MIME Security with Pretty Good Privacy
   (PGP)", RFC 2015, October 1996.

   [RFC2044] F. Yergeau., UTF-8, a transformation format of Unicode and
   ISO 10646. October 1996.

   [RFC2045] Borenstein, N., and Freed, N., "Multipurpose Internet Mail
   Extensions (MIME) Part One: Format of Internet Message Bodies.",
   November 1996

   [RFC2119] Bradner, S., Key words for use in RFCs to Indicate
   Requirement Level. March 1997.

15.

16. Full Copyright Statement

   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.