rfc2440.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Callas, et. al.             Standards Track                     [Page 6]

RFC 2440                 OpenPGP Message Format            November 1998


   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. Compression

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

2.4. Conversion to Radix-64

   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 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.  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, RFC 2015. An application that implements OpenPGP for
   messaging SHOULD implement OpenPGP-MIME.

2.5. Signature-Only Applications

   OpenPGP is designed for applications that use both encryption and
   signatures, but there are a number of problems that are solved by a
   signature-only implementation. Although this specification requires
   both encryption and signatures, it is reasonable for there to be
   subset implementations that are non-comformant only in that they omit
   encryption.

3. Data Element Formats

   This section describes the data elements used by OpenPGP.








Callas, et. al.             Standards Track                     [Page 7]

RFC 2440                 OpenPGP Message Format            November 1998


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. 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 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. Key IDs

   A Key ID is an eight-octet 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. Text

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




Callas, et. al.             Standards Track                     [Page 8]

RFC 2440                 OpenPGP Message Format            November 1998


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. String-to-key (S2K) specifiers

   String-to-key (S2K) specifiers are used to convert passphrase strings
   into 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
   symmetrically encrypted messages.

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

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

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

   Simple S2K hashes the passphrase to produce the session key.  The
   manner in which this 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 high-order (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, 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.





Callas, et. al.             Standards Track                     [Page 9]

RFC 2440                 OpenPGP Message Format            November 1998


3.6.1.2. Salted S2K

   This includes a "salt" value in the 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
       Octets 2-9:     8-octet salt value

   Salted S2K 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.1.3. Iterated and Salted S2K

   This includes both a salt and an octet count.  The salt is combined
   with the passphrase and the resulting value is hashed repeatedly.
   This further increases the amount of work an attacker must do to try
   dictionary attacks.

       Octet  0:        0x03
       Octet  1:        hash algorithm
       Octets 2-9:      8-octet salt value
       Octet  10:       count, a one-octet, coded value

   The count is coded into a one-octet number using the following
   formula:

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

   The above formula is in C, where "Int32" is a type for a 32-bit
   integer, and the variable "c" is the 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
   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.



Callas, et. al.             Standards Track                    [Page 10]

RFC 2440                 OpenPGP Message Format            November 1998


   After the hashing is done the data is unloaded from the hash
   context(s) as with the other S2K algorithms.

3.6.2. String-to-key usage

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

3.6.2.1. Secret key encryption

   An S2K specifier can be stored in the secret keyring to specify how
   to convert the passphrase to a key that unlocks the secret data.
   Older versions of PGP just stored a cipher algorithm octet preceding
   the secret data or a zero to indicate that the secret data was
   unencrypted. The 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 used, the special value
   255 is stored in the position where the hash algorithm octet would
   have been in the old data structure.  This is then followed
   immediately by a one-octet algorithm identifier, and then by the S2K
   specifier as encoded above.

   Therefore, preceding the 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 cipher algorithm number with an implicit
   use of MD5 and IDEA, is provided for 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 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 a message.  This is used to allow S2K specifiers to
   be used for the passphrase conversion or to create messages with a
   mix of symmetric-key ESKs and public-key ESKs. This allows a message
   to be decrypted either with a passphrase or a public key.





Callas, et. al.             Standards Track                    [Page 11]

RFC 2440                 OpenPGP Message Format            November 1998


   PGP 2.X always used IDEA with Simple string-to-key conversion when
   encrypting a message with a symmetric algorithm. This is deprecated,
   but MAY be used for backward-compatibility.

4. Packet Syntax

   This section describes the packets used by OpenPGP.

4.1. Overview

   An OpenPGP message is constructed from a number of records that are
   traditionally called packets. A packet is a chunk of data that has a
   tag specifying its meaning. An OpenPGP message, keyring, certificate,
   and so forth consists of a number of packets. Some of those packets
   may contain other OpenPGP packets (for example, a compressed data
   packet, when uncompressed, contains OpenPGP packets).

   Each packet consists of a packet header, followed by the packet body.
   The packet header is of variable length.

4.2. Packet Headers

   The first octet of the packet header is called the "Packet Tag." It
   determines the format of the header and denotes the packet contents.
   The remainder of the packet header is the length of the packet.

   Note that the 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 and
   still be backward-compatible.

   Old format packets contain:

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