Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 4880


OpenPGP Message Format

Part 5 of 5, p. 70 to 90
Prev RFC Part


prevText      Top      Up      ToC       Page 70 
12.  Enhanced Key Formats

12.1.  Key Structures

   The format of an OpenPGP V3 key 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 the preceding User
   ID.  The RSA public key can have many User IDs and each User ID can
   have many signatures.  V3 keys are deprecated.  Implementations MUST
   NOT generate new V3 keys, but MAY continue to use existing ones.

   The format of an OpenPGP V4 key that uses multiple public keys is
   similar except that the other keys are added to the end as "subkeys"
   of the primary key.

Top      Up      ToC       Page 71 
              [Revocation Self Signature]
              [Direct Key Signature...]
               User ID [Signature ...]
              [User ID [Signature ...] ...]
              [User Attribute [Signature ...] ...]
              [[Subkey [Binding-Signature-Revocation]
                      Primary-Key-Binding-Signature] ...]

   A subkey always has a single signature after it that is issued using
   the primary key to tie the two keys together.  This binding signature
   may be in either V3 or V4 format, but SHOULD be V4.  Subkeys that can
   issue signatures MUST have a V4 binding signature due to the REQUIRED
   embedded primary key binding signature.

   In the above diagram, if the binding signature of a subkey has been
   revoked, the revoked key may be removed, leaving only one key.

   In a V4 key, the primary key MUST be a key capable of certification.
   The subkeys may be keys of any other type.  There may be 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 signature-only subkey.  This permits a
   primary key that collects certifications (key signatures), but is
   used only for certifying subkeys that are used for encryption and

12.2.  Key IDs and Fingerprints

   For a V3 key, the eight-octet Key ID consists of the low 64 bits of
   the public modulus of the RSA key.

   The fingerprint of a V3 key is formed by hashing the body (but not
   the two-octet length) of the MPIs that form the key material (public
   modulus n, followed by exponent e) with MD5.  Note that both V3 keys
   and MD5 are deprecated.

   A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99,
   followed by the two-octet packet length, followed by the entire
   Public-Key packet starting with the version field.  The Key ID is the
   low-order 64 bits of the fingerprint.  Here are the fields of the
   hash material, with the example of a DSA key:

   a.1) 0x99 (1 octet)

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

Top      Up      ToC       Page 72 
   a.3) low-order length octet of (b)-(e) (1 octet)

     b) version number = 4 (1 octet);

     c) timestamp of key creation (4 octets);

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

     e) Algorithm-specific fields.

   Algorithm-Specific Fields for DSA keys (example):

   e.1) MPI of DSA prime p;

   e.2) MPI of DSA group order q (q is a prime divisor of p-1);

   e.3) MPI of DSA group generator g;

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

   Note that it is possible for there to be collisions of Key IDs -- two
   different keys with the same Key ID.  Note that there is a much
   smaller, but still non-zero, probability that two different keys have
   the same fingerprint.

   Also note that if V3 and V4 format keys share the same RSA key
   material, they will have different Key IDs as well as different

   Finally, the Key ID and fingerprint of a subkey are calculated in the
   same way as for a primary key, including the 0x99 as the first octet
   (even though this is not a valid packet ID for a public subkey).

13.  Notes on Algorithms

13.1.  PKCS#1 Encoding in OpenPGP

   This standard makes use of the PKCS#1 functions EME-PKCS1-v1_5 and
   EMSA-PKCS1-v1_5.  However, the calling conventions of these functions
   has changed in the past.  To avoid potential confusion and
   interoperability problems, we are including local copies in this
   document, adapted from those in PKCS#1 v2.1 [RFC3447].  RFC 3447
   should be treated as the ultimate authority on PKCS#1 for OpenPGP.
   Nonetheless, we believe that there is value in having a self-
   contained document that avoids problems in the future with needed
   changes in the conventions.

Top      Up      ToC       Page 73 
13.1.1.  EME-PKCS1-v1_5-ENCODE


   k  = the length in octets of the key modulus

   M  = message to be encoded, an octet string of length mLen, where
        mLen <= k - 11


   EM = encoded message, an octet string of length k

   Error:   "message too long"

     1. Length checking: If mLen > k - 11, output "message too long" and

     2. Generate an octet string PS of length k - mLen - 3 consisting of
        pseudo-randomly generated nonzero octets.  The length of PS will
        be at least eight octets.

     3. Concatenate PS, the message M, and other padding to form an
        encoded message EM of length k octets as

        EM = 0x00 || 0x02 || PS || 0x00 || M.

     4. Output EM.

13.1.2.  EME-PKCS1-v1_5-DECODE


   EM = encoded message, an octet string


   M  = message, an octet string

   Error:   "decryption error"

   To decode an EME-PKCS1_v1_5 message, separate the encoded message EM
   into an octet string PS consisting of nonzero octets and a message M
   as follows

     EM = 0x00 || 0x02 || PS || 0x00 || M.

Top      Up      ToC       Page 74 
   If the first octet of EM does not have hexadecimal value 0x00, if the
   second octet of EM does not have hexadecimal value 0x02, if there is
   no octet with hexadecimal value 0x00 to separate PS from M, or if the
   length of PS is less than 8 octets, output "decryption error" and
   stop.  See also the security note in Section 14 regarding differences
   in reporting between a decryption error and a padding error.

13.1.3.  EMSA-PKCS1-v1_5

   This encoding method is deterministic and only has an encoding


   Hash - a hash function in which hLen denotes the length in octets of
         the hash function output


   M  = message to be encoded

   mL = intended length in octets of the encoded message, at least tLen
        + 11, where tLen is the octet length of the DER encoding T of a
        certain value computed during the encoding operation


   EM = encoded message, an octet string of length emLen

   Errors: "message too long"; "intended encoded message length too


     1. Apply the hash function to the message M to produce a hash value

        H = Hash(M).

        If the hash function outputs "message too long," output "message
        too long" and stop.

     2. Using the list in Section 5.2.2, produce an ASN.1 DER value for
        the hash function used.  Let T be the full hash prefix from
        Section 5.2.2, and let tLen be the length in octets of T.

     3. If emLen < tLen + 11, output "intended encoded message length
        too short" and stop.

Top      Up      ToC       Page 75 
     4. Generate an octet string PS consisting of emLen - tLen - 3
        octets with hexadecimal value 0xFF.  The length of PS will be at
        least 8 octets.

     5. Concatenate PS, the hash prefix T, and other padding to form the
        encoded message EM as

        EM = 0x00 || 0x01 || PS || 0x00 || T.

     6. Output EM.

13.2.  Symmetric Algorithm Preferences

   The symmetric algorithm preference is an ordered list of algorithms
   that the keyholder accepts.  Since it is found on a self-signature,
   it is possible that a keyholder may have multiple, different
   preferences.  For example, Alice may have TripleDES only specified
   for "" but CAST5, Blowfish, and TripleDES specified for
   "".  Note that it is also possible for preferences to
   be in a subkey's binding signature.

   Since TripleDES is the MUST-implement algorithm, if it is not
   explicitly in the list, it is tacitly at the end.  However, it is
   good form to place it there explicitly.  Note also that if an
   implementation does not implement the preference, then it is
   implicitly a TripleDES-only implementation.

   An implementation MUST NOT use a symmetric algorithm that is not in
   the recipient's preference list.  When encrypting to 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 mechanism to 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 decrypt the
   message anyway, but MUST warn the keyholder that the protocol has
   been violated.  For example, suppose that Alice, above, has software
   that implements all algorithms in 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.

Top      Up      ToC       Page 76 
13.3.  Other Algorithm Preferences

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

13.3.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.
   In this specification, the default is for messages to be compressed,
   although an implementation is not required to do so.  Consequently,
   the compression preference gives a way for a keyholder to request
   that messages not be compressed, presumably because they are using a
   minimal implementation that does not include compression.
   Additionally, this gives a keyholder a way to state that it can
   support alternate algorithms.

   Like the algorithm preferences, an implementation MUST NOT use an
   algorithm that is not in the preference vector.  If the preferences
   are not present, then they are assumed to be [ZIP(1),

   Additionally, an implementation MUST implement this preference to the
   degree of recognizing when to send an uncompressed message.  A robust
   implementation would satisfy this requirement by looking at the
   recipient's preference and acting accordingly.  A minimal
   implementation can satisfy this requirement by never generating a
   compressed message, since all implementations can handle messages
   that have not been compressed.

13.3.2.  Hash Algorithm Preferences

   Typically, the choice of a hash algorithm is something the signer
   does, rather than the verifier, because a signer rarely knows who is
   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.

   Since SHA1 is the MUST-implement hash algorithm, if it is not
   explicitly in the list, it is tacitly at the end.  However, it is
   good form to place it there explicitly.

Top      Up      ToC       Page 77 
13.4.  Plaintext

   Algorithm 0, "plaintext", may only be used to denote secret keys that
   are stored in the clear.  Implementations MUST NOT use plaintext in
   Symmetrically Encrypted Data packets; they must use Literal Data
   packets to encode unencrypted or literal data.

13.5.  RSA

   There are algorithm types for RSA Sign-Only, and RSA Encrypt-Only
   keys.  These types are deprecated.  The "key flags" subpacket in a
   signature is a much better way to express the same idea, and
   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
   1024 bits.

13.6.  DSA

   An implementation SHOULD NOT implement DSA keys of size less than
   1024 bits.  It MUST NOT implement a DSA key with a q size of less
   than 160 bits.  DSA keys MUST also be a multiple of 64 bits, and the
   q size MUST be a multiple of 8 bits.  The Digital Signature Standard
   (DSS) [FIPS186] specifies that DSA be used in one of the following

     * 1024-bit key, 160-bit q, SHA-1, SHA-224, SHA-256, SHA-384, or
       SHA-512 hash

     * 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384, or SHA-512

     * 2048-bit key, 256-bit q, SHA-256, SHA-384, or SHA-512 hash

     * 3072-bit key, 256-bit q, SHA-256, SHA-384, or SHA-512 hash

   The above key and q size pairs were chosen to best balance the
   strength of the key with the strength of the hash.  Implementations
   SHOULD use one of the above key and q size pairs when generating DSA
   keys.  If DSS compliance is desired, one of the specified SHA hashes
   must be used as well.  [FIPS186] is the ultimate authority on DSS,
   and should be consulted for all questions of DSS compliance.

   Note that earlier versions of this standard only allowed a 160-bit q
   with no truncation allowed, so earlier implementations may not be
   able to handle signatures with a different q size or a truncated

Top      Up      ToC       Page 78 
13.7.  Elgamal

   An implementation SHOULD NOT implement Elgamal keys of size less than
   1024 bits.

13.8.  Reserved Algorithm Numbers

   A number of algorithm IDs have been reserved for algorithms that
   would be useful to use in an OpenPGP implementation, yet there are
   issues that prevent an implementer from actually implementing the
   algorithm.  These are marked in Section 9.1, "Public-Key Algorithms",
   as "reserved for".

   The reserved public-key algorithms, Elliptic Curve (18), ECDSA (19),
   and X9.42 (21), do not have the necessary parameters, parameter
   order, or semantics defined.

   Previous versions of OpenPGP permitted Elgamal [ELGAMAL] signatures
   with a public-key identifier of 20.  These are no longer permitted.
   An implementation MUST NOT generate such keys.  An implementation
   MUST NOT generate Elgamal signatures.  See [BLEICHENBACHER].

13.9.  OpenPGP CFB Mode

   OpenPGP does symmetric encryption using a variant of Cipher Feedback
   mode (CFB mode).  This section describes the procedure it uses in
   detail.  This mode is what is used for Symmetrically Encrypted Data
   Packets; the mechanism used for encrypting secret-key material is
   similar, and is described in the sections above.

   In the description below, the value BS is the block size in octets of
   the cipher.  Most ciphers have a block size of 8 octets.  The AES and
   Twofish have a block size of 16 octets.  Also note that the
   description below assumes that the IV and CFB arrays start with an
   index of 1 (unlike the C language, which assumes arrays start with a
   zero index).

   OpenPGP CFB mode uses an initialization vector (IV) of all zeros, and
   prefixes the plaintext with BS+2 octets of random data, such that
   octets BS+1 and BS+2 match octets BS-1 and BS.  It does a CFB
   resynchronization after encrypting those BS+2 octets.

   Thus, for an algorithm that has a block size of 8 octets (64 bits),
   the IV is 10 octets long and octets 7 and 8 of the IV are the same as
   octets 9 and 10.  For an algorithm with a block size of 16 octets
   (128 bits), the IV is 18 octets long, and octets 17 and 18 replicate
   octets 15 and 16.  Those extra two octets are an easy check for a
   correct key.

Top      Up      ToC       Page 79 
   Step by step, here is the procedure:

   1.  The feedback register (FR) is set to the IV, which is all zeros.

   2.  FR is encrypted to produce FRE (FR Encrypted).  This is the
       encryption of an all-zero value.

   3.  FRE is xored with the first BS octets of random data prefixed to
       the plaintext to produce C[1] through C[BS], the first BS octets
       of ciphertext.

   4.  FR is loaded with C[1] through C[BS].

   5.  FR is encrypted to produce FRE, the encryption of the first BS
       octets of ciphertext.

   6.  The left two octets of FRE get xored with the next two octets of
       data that were prefixed to the plaintext.  This produces C[BS+1]
       and C[BS+2], the next two octets of ciphertext.

   7.  (The resynchronization step) FR is loaded with C[3] through

   8.  FR is encrypted to produce FRE.

   9.  FRE is xored with the first BS octets of the given plaintext, now
       that we have finished encrypting the BS+2 octets of prefixed
       data.  This produces C[BS+3] through C[BS+(BS+2)], the next BS
       octets of ciphertext.

   10. FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18 for
       an 8-octet block).

       11. FR is encrypted to produce FRE.

       12. FRE is xored with the next BS octets of plaintext, to produce
       the next BS octets of ciphertext.  These are loaded into FR, and
       the process is repeated until the plaintext is used up.

13.10.  Private or Experimental Parameters

   S2K specifiers, Signature subpacket types, user attribute types,
   image format types, and algorithms described in Section 9 all reserve
   the range 100 to 110 for private and experimental use.  Packet types
   reserve the range 60 to 63 for private and experimental use.  These
   are intentionally managed with the PRIVATE USE method, as described
   in [RFC2434].

Top      Up      ToC       Page 80 
   However, implementations need to be careful with these and promote
   them to full IANA-managed parameters when they grow beyond the
   original, limited system.

13.11.  Extension of the MDC System

   As described in the non-normative explanation in Section 5.13, the
   MDC system is uniquely unparameterized in OpenPGP.  This was an
   intentional decision to avoid cross-grade attacks.  If the MDC system
   is extended to a stronger hash function, care must be taken to avoid
   downgrade and cross-grade attacks.

   One simple way to do this is to create new packets for a new MDC.
   For example, instead of the MDC system using packets 18 and 19, a new
   MDC could use 20 and 21.  This has obvious drawbacks (it uses two
   packet numbers for each new hash function in a space that is limited
   to a maximum of 60).

   Another simple way to extend the MDC system is to create new versions
   of packet 18, and reflect this in packet 19.  For example, suppose
   that V2 of packet 18 implicitly used SHA-256.  This would require
   packet 19 to have a length of 32 octets.  The change in the version
   in packet 18 and the size of packet 19 prevent a downgrade attack.

   There are two drawbacks to this latter approach.  The first is that
   using the version number of a packet to carry algorithm information
   is not tidy from a protocol-design standpoint.  It is possible that
   there might be several versions of the MDC system in common use, but
   this untidiness would reflect untidiness in cryptographic consensus
   about hash function security.  The second is that different versions
   of packet 19 would have to have unique sizes.  If there were two
   versions each with 256-bit hashes, they could not both have 32-octet
   packet 19s without admitting the chance of a cross-grade attack.

   Yet another, complex approach to extend the MDC system would be a
   hybrid of the two above -- create a new pair of MDC packets that are
   fully parameterized, and yet protected from downgrade and cross-

   Any change to the MDC system MUST be done through the IETF CONSENSUS
   method, as described in [RFC2434].

13.12.  Meta-Considerations for Expansion

   If OpenPGP is extended in a way that is not backwards-compatible,
   meaning that old implementations will not gracefully handle their

Top      Up      ToC       Page 81 
   absence of a new feature, the extension proposal can be declared in
   the key holder's self-signature as part of the Features signature

   We cannot state definitively what extensions will not be upwards-
   compatible, but typically new algorithms are upwards-compatible,
   whereas new packets are not.

   If an extension proposal does not update the Features system, it
   SHOULD include an explanation of why this is unnecessary.  If the
   proposal contains neither an extension to the Features system nor an
   explanation of why such an extension is unnecessary, the proposal
   SHOULD be rejected.

14.  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.  It
     is assumed that the private key portion of a public-private key
     pair is controlled and secured 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 [RFC4086]).

   * The MD5 hash algorithm has been found to have weaknesses, with
     collisions found in a number of cases.  MD5 is deprecated for use
     in OpenPGP.  Implementations MUST NOT generate new signatures using
     MD5 as a hash function.  They MAY continue to consider old
     signatures that used MD5 as valid.

   * SHA-224 and SHA-384 require the same work as SHA-256 and SHA-512,
     respectively.  In general, there are few reasons to use them
     outside of DSS compatibility.  You need a situation where one needs
     more security than smaller hashes, but does not want to have the
     full 256-bit or 512-bit data length.

   * Many security protocol designers think that it is a bad idea to use
     a single key for both privacy (encryption) and integrity
     (signatures).  In fact, this was one of the motivating forces
     behind the V4 key format with separate signature and encryption
     keys.  If you as an implementer promote dual-use keys, you should
     at least be aware of this controversy.

Top      Up      ToC       Page 82 
   * The DSA algorithm will work with any hash, but is sensitive to the
     quality of the hash algorithm.  Verifiers should be aware that even
     if the signer used a strong hash, an attacker could have modified
     the signature to use a weak one.  Only signatures using acceptably
     strong hash algorithms should be accepted as valid.

   * As OpenPGP combines many different asymmetric, symmetric, and hash
     algorithms, each with different measures of strength, care should
     be taken that the weakest element of an OpenPGP message is still
     sufficiently strong for the purpose at hand.  While consensus about
     the strength of a given algorithm may evolve, NIST Special
     Publication 800-57 [SP800-57] recommends the following list of
     equivalent strengths:

           Asymmetric  |  Hash  |  Symmetric
            key size   |  size  |   key size
              1024        160         80
              2048        224        112
              3072        256        128
              7680        384        192
             15360        512        256

   * There is a somewhat-related potential security problem in
     signatures.  If an attacker can find a message that hashes to the
     same hash with a different algorithm, a bogus signature structure
     can be constructed that evaluates correctly.

     For example, suppose Alice DSA signs message M using hash algorithm
     H.  Suppose that Mallet finds a message M' that has the same hash
     value as M with H'.  Mallet can then construct a signature block
     that verifies as Alice's signature of M' with H'.  However, this
     would also constitute a weakness in either H or H' or both.  Should
     this ever occur, a revision will have to be made to this document
     to revise the allowed hash algorithms.

   * 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
     TripleDES.  Other algorithms may have other controversies
     surrounding them.

Top      Up      ToC       Page 83 
   * In late summer 2002, Jallad, Katz, and Schneier published an
     interesting attack on the OpenPGP protocol and some of its
     implementations [JKS02].  In this attack, the attacker modifies a
     message and sends it to a user who then returns the erroneously
     decrypted message to the attacker.  The attacker is thus using the
     user as a random oracle, and can often decrypt the message.

     Compressing data can ameliorate this attack.  The incorrectly
     decrypted data nearly always decompresses in ways that defeat the
     attack.  However, this is not a rigorous fix, and leaves open some
     small vulnerabilities.  For example, if an implementation does not
     compress a message before encryption (perhaps because it knows it
     was already compressed), then that message is vulnerable.  Because
     of this happenstance -- that modification attacks can be thwarted
     by decompression errors -- an implementation SHOULD treat a
     decompression error as a security problem, not merely a data

     This attack can be defeated by the use of Modification Detection,
     provided that the implementation does not let the user naively
     return the data to the attacker.  An implementation MUST treat an
     MDC failure as a security problem, not merely a data problem.

     In either case, the implementation MAY allow the user access to the
     erroneous data, but MUST warn the user as to potential security
     problems should that data be returned to the sender.

     While this attack is somewhat obscure, requiring a special set of
     circumstances to create it, it is nonetheless quite serious as it
     permits someone to trick a user to decrypt a message.
     Consequently, it is important that:

      1. Implementers treat MDC errors and decompression failures as
         security problems.

      2. Implementers implement Modification Detection with all due
         speed and encourage its spread.

      3. Users migrate to implementations that support Modification
         Detection with all due speed.

   * PKCS#1 has been found to be vulnerable to attacks in which a system
     that reports errors in padding differently from errors in
     decryption becomes a random oracle that can leak the private key in
     mere millions of queries.  Implementations must be aware of this
     attack and prevent it from happening.  The simplest solution is to
     report a single error code for all variants of decryption errors so
     as not to leak information to an attacker.

Top      Up      ToC       Page 84 
   * Some technologies mentioned here may be subject to government
     control in some countries.

   * In winter 2005, Serge Mister and Robert Zuccherato from Entrust
     released a paper describing a way that the "quick check" in OpenPGP
     CFB mode can be used with a random oracle to decrypt two octets of
     every cipher block [MZ05].  They recommend as prevention not using
     the quick check at all.

     Many implementers have taken this advice to heart for any data that
     is symmetrically encrypted and for which the session key is
     public-key encrypted.  In this case, the quick check is not needed
     as the public-key encryption of the session key should guarantee
     that it is the right session key.  In other cases, the
     implementation should use the quick check with care.

     On the one hand, there is a danger to using it if there is a random
     oracle that can leak information to an attacker.  In plainer
     language, there is a danger to using the quick check if timing
     information about the check can be exposed to an attacker,
     particularly via an automated service that allows rapidly repeated

     On the other hand, it is inconvenient to the user to be informed
     that they typed in the wrong passphrase only after a petabyte of
     data is decrypted.  There are many cases in cryptographic
     engineering where the implementer must use care and wisdom, and
     this is one.

15.  Implementation Nits

   This section is a collection of comments to help an implementer,
   particularly with an eye to backward compatibility.  Previous
   implementations of PGP are not OpenPGP compliant.  Often the
   differences are small, but small differences are frequently more
   vexing than large differences.  Thus, this is a non-comprehensive
   list of potential problems and gotchas for a developer who is trying
   to be backward-compatible.

     * The IDEA algorithm is patented, and yet it is required for PGP
       2.x interoperability.  It is also the de-facto preferred
       algorithm for a V3 key with a V3 self-signature (or no self-

     * When exporting a private key, PGP 2.x generates the header "BEGIN
       All previous versions ignore the implied data type, and look
       directly at the packet data type.

Top      Up      ToC       Page 85 
     * PGP 2.0 through 2.5 generated V2 Public-Key packets.  These are
       identical to the deprecated V3 keys except for the version
       number.  An implementation MUST NOT generate them and may accept
       or reject them as it sees fit.  Some older PGP versions generated
       V2 PKESK packets (Tag 1) as well.  An implementation may accept
       or reject V2 PKESK packets as it sees fit, and MUST NOT generate

     * PGP 2.6.x will not accept key-material packets with versions
       greater than 3.

     * There are many ways possible for two keys to have the same key
       material, but different fingerprints (and thus Key IDs).  Perhaps
       the most interesting is an RSA key that has been "upgraded" to V4
       format, but since a V4 fingerprint is constructed by hashing the
       key creation time along with other things, two V4 keys created at
       different times, yet with the same key material will have
       different fingerprints.

     * If an implementation is using zlib to interoperate with PGP 2.x,
       then the "windowBits" parameter should be set to -13.

     * The 0x19 back signatures were not required for signing subkeys
       until relatively recently.  Consequently, there may be keys in
       the wild that do not have these back signatures.  Implementing
       software may handle these keys as it sees fit.

     * OpenPGP does not put limits on the size of public keys.  However,
       larger keys are not necessarily better keys.  Larger keys take
       more computation time to use, and this can quickly become
       impractical.  Different OpenPGP implementations may also use
       different upper bounds for public key sizes, and so care should
       be taken when choosing sizes to maintain interoperability.  As of
       2007 most implementations have an upper bound of 4096 bits.

     * ASCII armor is an optional feature of OpenPGP.  The OpenPGP
       working group strives for a minimal set of mandatory-to-implement
       features, and since there could be useful implementations that
       only use binary object formats, this is not a "MUST" feature for
       an implementation.  For example, an implementation that is using
       OpenPGP as a mechanism for file signatures may find ASCII armor
       unnecessary. OpenPGP permits an implementation to declare what
       features it does and does not support, but ASCII armor is not one
       of these.  Since most implementations allow binary and armored
       objects to be used indiscriminately, an implementation that does
       not implement ASCII armor may find itself with compatibility
       issues with general-purpose implementations.  Moreover,
       implementations of OpenPGP-MIME [RFC3156] already have a

Top      Up      ToC       Page 86 
       requirement for ASCII armor so those implementations will
       necessarily have support.

16.  References

16.1.  Normative References

   [AES]            NIST, FIPS PUB 197, "Advanced Encryption Standard
                    (AES)," November 2001.

   [BLOWFISH]       Schneier, B. "Description of a New Variable-Length
                    Key, 64-Bit Block Cipher (Blowfish)" Fast Software
                    Encryption, Cambridge Security Workshop Proceedings
                    (December 1993), Springer-Verlag, 1994, pp191-204

   [BZ2]            J. Seward,, "The Bzip2 and libbzip2
                    home page" <>

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

   [FIPS180]        Secure Hash Signature Standard (SHS) (FIPS PUB 180-

   [FIPS186]        Digital Signature Standard (DSS) (FIPS PUB 186-2).
                     fips186-2-change1.pdf> FIPS 186-3 describes keys
                    greater than 1024 bits.  The latest draft is at:

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

   [IDEA]           Lai, X, "On the design and security of block
                    ciphers", ETH Series in Information Processing, J.L.
                    Massey (editor), Vol. 1, Hartung-Gorre Verlag
                    Knostanz, Technische Hochschule (Zurich), 1992

Top      Up      ToC       Page 87 
   [ISO10646]       ISO/IEC 10646-1:1993. International Standard --
                    Information technology -- Universal Multiple-Octet
                    Coded Character Set (UCS) -- Part 1: Architecture
                    and Basic Multilingual Plane.

   [JFIF]           JPEG File Interchange Format (Version 1.02).  Eric
                    Hamilton, C-Cube Microsystems, Milpitas, CA,
                    September 1, 1992.

   [RFC1950]        Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data
                    Format Specification version 3.3", RFC 1950, May

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

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

   [RFC2119]        Bradner, S., "Key words for use in RFCs to Indicate
                    Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2144]        Adams, C., "The CAST-128 Encryption Algorithm", RFC
                    2144, May 1997.

   [RFC2434]        Narten, T. and H. Alvestrand, "Guidelines for
                    Writing an IANA Considerations Section in RFCs", BCP
                    26, RFC 2434, October 1998.

   [RFC2822]        Resnick, P., "Internet Message Format", RFC 2822,
                    April 2001.

   [RFC3156]        Elkins, M., Del Torto, D., Levien, R., and T.
                    Roessler, "MIME Security with OpenPGP", RFC 3156,
                    August 2001.

   [RFC3447]        Jonsson, J. and B. Kaliski, "Public-Key Cryptography
                    Standards (PKCS) #1: RSA Cryptography Specifications
                    Version 2.1", RFC 3447, February 2003.

   [RFC3629]        Yergeau, F., "UTF-8, a transformation format of ISO
                    10646", STD 63, RFC 3629, November 2003.

   [RFC4086]        Eastlake, D., 3rd, Schiller, J., and S. Crocker,
                    "Randomness Requirements for Security", BCP 106, RFC
                    4086, June 2005.

Top      Up      ToC       Page 88 
   [SCHNEIER]      Schneier, B., "Applied Cryptography Second Edition:
                    protocols, algorithms, and source code in C", 1996.

   [TWOFISH]        B. Schneier, J. Kelsey, D. Whiting, D. Wagner, C.
                    Hall, and N. Ferguson, "The Twofish Encryption
                    Algorithm", John Wiley & Sons, 1999.

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

   [JKS02]          Kahil Jallad, Jonathan Katz, Bruce Schneier
                    "Implementation of Chosen-Ciphertext Attacks against
                    PGP and GnuPG"

   [MAURER]         Ueli Maurer, "Modelling a Public-Key
                    Infrastructure", Proc. 1996 European Symposium on
                    Research in Computer Security (ESORICS' 96), Lecture
                    Notes in Computer Science, Springer-Verlag, vol.
                    1146, pp. 325-350, Sep 1996.

   [MZ05]           Serge Mister, Robert Zuccherato, "An Attack on CFB
                    Mode Encryption As Used By OpenPGP," IACR ePrint
                    Archive: Report 2005/033, 8 Feb 2005

   [REGEX]          Jeffrey Friedl, "Mastering Regular Expressions,"
                    O'Reilly, ISBN 0-596-00289-0.

   [RFC1423]        Balenson, D., "Privacy Enhancement for Internet
                    Electronic Mail: Part III: Algorithms, Modes, and
                    Identifiers", RFC 1423, February 1993.

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

   [RFC2440]        Callas, J., Donnerhacke, L., Finney, H., and R.
                    Thayer, "OpenPGP Message Format", RFC 2440, November

Top      Up      ToC       Page 89 
   [SP800-57]       NIST Special Publication 800-57, Recommendation on
                    Key Management
                    < 800-
                    < 800-


   This memo also draws on much previous work from a number of other
   authors, including: Derek Atkins, Charles Breed, Dave Del Torto, Marc
   Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Ben Laurie,
   Raph Levien, Colin Plumb, Will Price, David Shaw, William Stallings,
   Mark Weaver, and Philip R. Zimmermann.

Authors' Addresses

   The working group can be contacted via the current chair:

      Derek Atkins
      IHTFP Consulting, Inc.
      4 Farragut Ave
      Somerville, MA  02144  USA

      Tel: +1 617 623 3745

   The principal authors of this document are as follows:

      Jon Callas

      Lutz Donnerhacke
      IKS GmbH
      Wildenbruchstr. 15
      07745 Jena, Germany

      Hal Finney

      David Shaw

      Rodney Thayer

Top      Up      ToC       Page 90 
Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at