draft-ietf-openpgp-rfc2440bis-07.txt

用C#开发实现SMTP相关技术,能接收到带附件的邮件服务功能.

       implementation that avoids all encumbered algorithms.
       Consequently, early versions of GPG did not include RSA public
       keys. GPG may or may not have (depending on version) support for
       IDEA or other encumbered algorithms.

   "PGP", "Pretty Good", and "Pretty Good Privacy" are trademarks of
   PGP Corporation and are used with permission.

   This document uses the terms "MUST", "SHOULD", and "MAY" as defined
   in RFC2119, along with the negated forms of those terms.

2. General functions

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

     - digital signatures

     - encryption 

     - compression




Callas, et al.         Expires September 3, 2003               [Page 6]
INTERNET-DRAFT          OpenPGP Message Format            March 3, 2003

     - radix-64 conversion

   In addition, OpenPGP provides key management and certificate
   services, but many of these are beyond the scope of this document.

2.1. Confidentiality via Encryption

   OpenPGP combines symmetric-key encryption and public key encryption
   to provide confidentiality. When made confidential, first the object
   is encrypted using a symmetric encryption algorithm.  Each symmetric
   key is used only once, for a single object. A new "session key" is
   generated as a random number for each object (sometimes referred to
   as a session). Since it is used only once, the 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 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 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 OpenPGP decrypts the session key using the
       recipient's private key.

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

   With symmetric-key encryption, an object may be encrypted with a
   symmetric key derived from a passphrase (or other shared secret), or
   a two-stage mechanism similar to the public-key method described
   above in which 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 symmetric session key. Finally, the session key is
   encrypted using public-key encryption and prefixed to the encrypted
   block.

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:

Callas, et al.         Expires September 3, 2003               [Page 7]
INTERNET-DRAFT          OpenPGP Message Format            March 3, 2003

   1.  The sender creates a message.

   2.  The sending software generates a hash code of the 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. Compression

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

   If an implementation does not implement compression, its authors
   should be aware that most PGP messages in the world are compressed.
   Thus, it may even be wise for a space-constrained implementation to
   implement decompression, but not compression.

   Furthermore, compression has the added side-effect that some types
   of attacks can be thwarted by the fact that slightly altered,
   compressed data rarely uncompresses without severe errors. This is
   hardly rigorous, but it is operationally useful. These attacks can
   be rigorously prevented by implementing and using Modification
   Detection Codes as described in sections following.

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.

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

Callas, et al.         Expires September 3, 2003               [Page 8]
INTERNET-DRAFT          OpenPGP Message Format            March 3, 2003

   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.

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

   Also note that when an MPI is encrypted, the length refers to the
   plaintext MPI. It may be ill-formed in its ciphertext.

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

Callas, et al.         Expires September 3, 2003               [Page 9]
INTERNET-DRAFT          OpenPGP Message Format            March 3, 2003

   formed.

3.4. Text

   Unless otherwise specified, the character set for text is the UTF-8
   [RFC2279] encoding of Unicode [ISO10646].

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

   A keyring is a collection of one or more keys in a file or database.
   Traditionally, a keyring is simply a sequential list of keys, but
   may be any suitable database. It is beyond the scope of this
   standard to discuss the details of keyrings or other databases.

3.7. 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.7.1. String-to-key (S2K) specifier types

   There are three types of S2K specifiers currently supported, and
   some reserved values:

       ID          S2K Type
       --          --- ----
       0           Simple S2K
       1           Salted S2K
       2           Illegal value
       3           Iterated and Salted S2K
       100 to 110  Private/Experimental S2K

   These are described as follows:

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




Callas, et al.         Expires September 3, 2003              [Page 10]
INTERNET-DRAFT          OpenPGP Message Format            March 3, 2003

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

3.7.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.7.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:




Callas, et al.         Expires September 3, 2003              [Page 11]
INTERNET-DRAFT          OpenPGP Message Format            March 3, 2003

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