--- 1/draft-ietf-openpgp-formats-05.txt 2006-02-05 00:55:19.000000000 +0100 +++ 2/draft-ietf-openpgp-formats-06.txt 2006-02-05 00:55:19.000000000 +0100 @@ -1,25 +1,25 @@ Network Working Group Jon Callas Category: INTERNET-DRAFT Network Associates -draft-ietf-openpgp-formats-05.txt -Expires Dec 1998 Lutz Donnerhacke -June 1998 IN-Root-CA Individual Network e.V. +draft-ietf-openpgp-formats-06.txt +Expires Jan 1999 Lutz Donnerhacke +July 1998 IN-Root-CA Individual Network e.V. Hal Finney Network Associates Rodney Thayer EIS Corporation OpenPGP Message Format - draft-ietf-openpgp-formats-05.txt + draft-ietf-openpgp-formats-06.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. @@ -65,147 +65,152 @@ 2.3. Compression 7 2.4. Conversion to Radix-64 7 3. Data Element Formats 7 3.1. Scalar numbers 7 3.2. Multi-Precision Integers 7 3.3. Key IDs 8 3.4. Text 8 3.5. Time fields 8 3.6. String-to-key (S2K) specifiers 8 3.6.1. String-to-key (S2k) specifier types 8 - 3.6.1.1. Simple S2K 8 + 3.6.1.1. Simple S2K 9 3.6.1.2. Salted S2K 9 3.6.1.3. Iterated and Salted S2K 9 3.6.2. String-to-key usage 10 3.6.2.1. Secret key encryption 10 3.6.2.2. Symmetric-key message encryption 11 4. Packet Syntax 11 4.1. Overview 11 4.2. Packet Headers 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.2.3. Packet Length Examples 14 4.3. Packet Tags 14 - 5. Packet Types 14 - 5.1. Public-Key Encrypted Session Key Packets (Tag 1) 14 + 5. Packet Types 15 + 5.1. Public-Key Encrypted Session Key Packets (Tag 1) 15 5.2. Signature Packet (Tag 2) 16 5.2.1. Signature Types 16 5.2.2. Version 3 Signature Packet Format 18 5.2.3. Version 4 Signature Packet Format 20 - 5.2.3.1. Signature Subpacket Specification 20 + 5.2.3.1. Signature Subpacket Specification 21 5.2.3.2. Signature Subpacket Types 22 - 5.2.3.3. Signature creation time 22 + 5.2.3.3. Signature creation time 23 5.2.3.4. Issuer 23 5.2.3.5. Key expiration time 23 5.2.3.6. Preferred symmetric algorithms 23 5.2.3.7. Preferred hash algorithms 23 - 5.2.3.8. Preferred compression algorithms 23 + 5.2.3.8. Preferred compression algorithms 24 5.2.3.9. Signature expiration time 24 - 5.2.3.10.Exportable 24 - 5.2.3.11.Revocable 24 - 5.2.3.12.Trust signature 24 - 5.2.3.13.Regular expression 24 + 5.2.3.10.Exportable Certification 24 + 5.2.3.11.Revocable 25 + 5.2.3.12.Trust signature 25 + 5.2.3.13.Regular expression 25 5.2.3.14.Revocation key 25 - 5.2.3.15.Notation Data 25 + 5.2.3.15.Notation Data 26 5.2.3.16.Key server preferences 26 5.2.3.17.Preferred key server 26 - 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.3.22.Reason for Revocation 27 - 5.2.4. Computing Signatures 28 + 5.2.3.18.Primary user id 27 + 5.2.3.19.Policy URL 27 + 5.2.3.20.Key Flags 27 + 5.2.3.21.Signer's User ID 28 + 5.2.3.22.Reason for Revocation 28 + 5.2.4. Computing Signatures 29 5.2.4.1. Subpacket Hints 29 - 5.3. Symmetric-Key Encrypted Session-Key Packets (Tag 3) 29 - 5.4. One-Pass Signature Packets (Tag 4) 30 + 5.3. Symmetric-Key Encrypted Session-Key Packets (Tag 3) 30 + 5.4. One-Pass Signature Packets (Tag 4) 31 5.5. Key Material Packet 31 - 5.5.1. Key Packet Variants 31 - 5.5.1.1. Public Key Packet (Tag 6) 31 - 5.5.1.2. Public Subkey Packet (Tag 14) 31 - 5.5.1.3. Secret Key Packet (Tag 5) 31 - 5.5.1.4. Secret Subkey Packet (Tag 7) 31 - 5.5.2. Public Key Packet Formats 31 - 5.5.3. Secret Key Packet Formats 33 + 5.5.1. Key Packet Variants 32 + 5.5.1.1. Public Key Packet (Tag 6) 32 + 5.5.1.2. Public Subkey Packet (Tag 14) 32 + 5.5.1.3. Secret Key Packet (Tag 5) 32 + 5.5.1.4. Secret Subkey Packet (Tag 7) 32 + 5.5.2. Public Key Packet Formats 32 + 5.5.3. Secret Key Packet Formats 34 5.6. Compressed Data Packet (Tag 8) 35 - 5.7. Symmetrically Encrypted Data Packet (Tag 9) 35 - 5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 36 - 5.9. Literal Data Packet (Tag 11) 36 - 5.10. Trust Packet (Tag 12) 37 - 5.11. User ID Packet (Tag 13) 37 - 6. Radix-64 Conversions 37 - 6.1. An Implementation of the CRC-24 in "C" 38 - 6.2. Forming ASCII Armor 38 - 6.3. Encoding Binary in Radix-64 40 - 6.4. Decoding Radix-64 41 + 5.7. Symmetrically Encrypted Data Packet (Tag 9) 36 + 5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 37 + 5.9. Literal Data Packet (Tag 11) 37 + 5.10. Trust Packet (Tag 12) 38 + 5.11. User ID Packet (Tag 13) 38 + 6. Radix-64 Conversions 38 + 6.1. An Implementation of the CRC-24 in "C" 39 + 6.2. Forming ASCII Armor 39 + 6.3. Encoding Binary in Radix-64 41 + 6.4. Decoding Radix-64 42 6.5. Examples of Radix-64 42 - 6.6. Example of an ASCII Armored Message 42 - 7. Cleartext signature framework 42 - 7.1. Dash-Escaped Text 43 + 6.6. Example of an ASCII Armored Message 43 + 7. Cleartext signature framework 43 + 7.1. Dash-Escaped Text 44 8. Regular Expressions 44 - 9. Constants 44 - 9.1. Public Key Algorithms 44 + 9. Constants 45 + 9.1. Public Key Algorithms 45 9.2. Symmetric Key Algorithms 45 - 9.3. Compression Algorithms 45 - 9.4. Hash Algorithms 45 + 9.3. Compression Algorithms 46 + 9.4. Hash Algorithms 46 10. Packet Composition 46 - 10.1. Transferable Public Keys 46 - 10.2. OpenPGP Messages 47 - 11. Enhanced Key Formats 47 - 11.1. Key Structures 47 - 11.2. Key IDs and Fingerprints 48 - 12. Notes on Algorithms 49 - 12.1. Symmetric Algorithm Preferences 49 - 12.2. Other Algorithm Preferences 50 - 12.2.1. Compression Preferences 50 + 10.1. Transferable Public Keys 47 + 10.2. OpenPGP Messages 48 + 11. Enhanced Key Formats 48 + 11.1. Key Structures 48 + 11.2. Key IDs and Fingerprints 49 + 12. Notes on Algorithms 50 + 12.1. Symmetric Algorithm Preferences 50 + 12.2. Other Algorithm Preferences 51 + 12.2.1. Compression Preferences 51 12.2.2. Hash Algorithm Preferences 51 - 12.3. Plaintext 51 - 12.4. RSA 51 - 12.5. Elgamal 51 - 12.6. DSA 52 - 12.7. OpenPGP CFB mode 52 - 13. Security Considerations 53 - 14. Implementation Nits 54 - 15. Authors and Working Group Chair 55 - 16. References 56 - 17. Full Copyright Statement 57 + 12.3. Plaintext 52 + 12.4. RSA 52 + 12.5. Elgamal 52 + 12.6. DSA 53 + 12.7. Reserved Algorithm Numbers 53 + 12.8. OpenPGP CFB mode 53 + 13. Security Considerations 54 + 14. Implementation Nits 55 + 15. Authors and Working Group Chair 56 + 16. References 57 + 17. Full Copyright Statement 58 1. Introduction This document provides information on the message-exchange packet formats used by OpenPGP to provide encryption, decryption, signing, and key management functions. It builds on the foundation provided in RFC 1991 "PGP Message Exchange Formats." 1.1. Terms * 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 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, MD5, and IDEA for its - cryptographic transforms. + cryptographic transforms. An informational RFC, RFC1991, was + written describing this version of PGP. * 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 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. + Network Associates, Inc. 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 @@ -573,23 +581,24 @@ 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. + indeterminate 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 = 1st_octet; 4.2.2.2. Two-Octet Lengths @@ -622,20 +631,23 @@ 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 -- one octet, two-octet, or partial) 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 + These examples show ways that new-format packets might encode the + packet lengths. + 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, 0x00, 0x01, 0x86, 0xA0. It might also be encoded in the following octet stream: 0xEF, first @@ -946,26 +958,30 @@ - One-octet version number (4). - One-octet signature type. - One-octet public key algorithm. - One-octet hash algorithm. - Two-octet scalar octet count for following hashed subpacket - data. + data. Note that this is the length in octets of all of the + hashed subpackets; a pointer incremented by this number will + skip over the hashed subpackets. - Hashed subpacket data. (zero or more subpackets) - Two-octet scalar octet count for following unhashed subpacket - data. + data. Note that this is the length in octets of all of the + unhashed subpackets; a pointer incremented by this number will + skip over the unhashed subpackets. - 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 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 (inclusive) is @@ -1010,21 +1026,21 @@ subpacketLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192 if the 1st octet = 255, then lengthOfLength = 5 subpacket length = [four-octet scalar starting at 2nd_octet] The value of the subpacket type octet may be: 2 = signature creation time 3 = signature expiration time - 4 = exportable + 4 = exportable certification 5 = trust signature 6 = regular expression 7 = revocable 9 = key expiration time 10 = placeholder for backward compatibility 11 = preferred symmetric algorithms 12 = revocation key 16 = issuer key ID 20 = notation data 21 = preferred hash algorithms @@ -1147,29 +1165,47 @@ on a self-signature. 5.2.3.9. Signature expiration time (4 octet time field) The validity period of the signature. This is the number of seconds after the signature creation time that the signature expires. If this is not present or has a value of zero, it never expires. -5.2.3.10. Exportable +5.2.3.10. Exportable Certification (1 octet of exportability, 0 for not, 1 for exportable) - Signature's exportability status. Packet body contains a boolean - flag indicating whether the signature is exportable. Signatures that - are not exportable are ignored during export and import operations. - If this packet is not present the signature is assumed to be - exportable. + This subpacket denotes whether a certification signature is + "exportable," to be used by other users than the signature's issuer. + The packet body contains a boolean flag indicating whether the + signature is exportable. If this packet is not present, the + certification is exportable; it is equvalent to a flag containing a + 1. + + Non-exportable, or "local," certifications are signatures made by a + user to mark a key as valid within that user's implementation only. + Thus, when an implementation prepare's a user's copy of a key for + transport to another user (this is the process of "exporting" the + key), any local certification signatures are deleted from the key. + + The receiver of a transported key "imports" it, and likewise trims + any local certifications. In normal operation, there won't be any, + assuming the import is performed on an exported key. However, there + are instances where this can reasonably happen. For example, if an + implementation allows keys to be imported from a key database in + addition to an exported key, then this situation can arise. + + Some implementations do not represent the interest of a single user + (for example, a key server). Such implementations always trim local + certifications from any key they handle. 5.2.3.11. 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 that are not revocable have any later revocation signatures ignored. They represent a commitment by the signer that he cannot revoke his signature for the life of his key. If this packet is not present, @@ -1475,41 +1511,41 @@ If the encrypted session key is present, the result of applying the S2K algorithm to the passphrase 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 the symmetric-key encryption algorithm used to encrypt the following Symmetrically Encrypted Data Packet, followed by the session key octets themselves. Note: because an all-zero IV is used for this decryption, the S2K - specifier MUST use a salt value, either a a Salted S2K or an + specifier MUST use a salt value, either 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 the signed data and contains enough information to allow the receiver to begin calculating any hashes needed to verify the signature. It allows the Signature Packet to be placed at the end of the message, so that the signer can compute the entire signed message in one pass. A One-Pass Signature does not interoperate with PGP 2.6.x or earlier. The body of this packet consists of: - A one-octet version number. The current version is 3. - A one-octet signature type. Signature types are described in - section 5.2.3. + section 5.2.1. - A one-octet number describing the hash algorithm used. - A one-octet number describing the public key algorithm used. - An eight-octet number holding the key ID of the signing key. - A one-octet number holding a flag showing whether the signature is nested. A zero value indicates that the next packet is another One-Pass Signature packet that describes another @@ -2214,70 +2251,74 @@ 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 + 18 - Elliptic Curve (reserved for) + 19 - ECDSA (reserved for) 20 - Elgamal (Encrypt or Sign) - 21 - Diffie-Hellman (X9.42) + 21 - Diffie-Hellman (X9.42, as defined for IETF-S/MIME) + (reserved for) 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) + 3 - CAST5 (128 bit key, as per RFC2144) 4 - Blowfish (128 bit key, 16 rounds) 5 - SAFER-SK128 (13 rounds) - 6 - DES/SK + 6 - DES/SK (reserved for) 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 (RFC1951) 2 - ZLIB (RFC1950) 100 to 110 - Private/Experimental algorithm. Implementations MUST implement uncompressed data. Implementations - SHOULD implement ZIP. + SHOULD implement ZIP. Implementations MAY implement ZLIB. 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" + 4 - Reserved for double-width + SHA (experimental) 5 - MD2 "MD2" - 6 - TIGER/192 "TIGER192" + 6 - TIGER/192 (reserved for) "TIGER192" + 7 - HAVAL (5 pass, 160-bit) "HAVAL-5-160" + (reserved for) 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 @@ -2392,21 +2433,21 @@ Primary-Key [Revocation Self Signature] [Direct Key Self Signature...] User ID [Signature ...] [User ID [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 V4 is prefered, of + signature may be in either V3 or V4 format, but V4 is preferred, of course. In the above diagram, if the binding signature of a subkey has been revoked, the revoked binding signature may be removed, leaving only one signature. In a key that has a main key and subkeys, the primary key MUST be a key capable of signing. 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 @@ -2422,34 +2463,33 @@ 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. A V4 fingerprint is the 160-bit SHA-1 hash of the one-octet Packet Tag, followed by the two-octet packet length, followed by the entire Public Key packet starting with the version field. The key ID is - either the low order 64 bits of the fingerprint. Here are the - fields of the hash material, with the example of a DSA key: + 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)-(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); + 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; @@ -2503,21 +2543,21 @@ An implementation that is striving for backward compatibility MAY consider a V3 key with a V3 self-signature to be an implicit preference for IDEA, and no ability to do TripleDES. This is technically non-compliant, but an implementation MAY violate the above rule in this case only and use IDEA to encrypt the message, provided that the message creator is warned. Ideally, though, the implementation would follow the rule by actually generating two messages, because it is possible that the OpenPGP user's implementation does not have IDEA, and thus could not read the - message. Consenquently, an implementation MAY, but SHOULD NOT use + message. Consequently, an implementation MAY, but SHOULD NOT use IDEA in an algorithm conflict with a V3 key. 12.2. 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 preferences. @@ -2528,21 +2568,21 @@ And 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 mot present, then they are assumed to be [ZIP(1), + are not present, then they are assumed to be [ZIP(1), UNCOMPRESSED(0)]. 12.2.2. Hash Algorithm Preferences Typically, the choice of a hash algorithm is something the signer does, rather than the verifier, because a signer does not typically know who is going to be verifying the signature. This preference, though, allows a protocol based upon digital signatures ease in negotiation. @@ -2613,69 +2653,92 @@ 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 +12.7. 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 implementor from actually implementing the + algorithm. These are marked in the Public Algorithms section 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. + + The reserved symmetric key algorithm, DES/SK (6), does not have + semantics defined. + + The reserved hash algorithms, TIGER192 (6), and HAVAL-5-160 (7), do + not have OIDs. The reserved algorithm number 4, reserved for a + double-width variant of SHA1, is not presently defined. + +12.8. 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, but described in those sections above. 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 CFB "resync" after - encrypting those ten bytes. + and prefixes the plaintext with ten octets of random data, such that + octets 9 and 10 match octets 7 and 8. It does a CFB "resync" after + encrypting those ten octets. Note that for an algorithm that has a larger block size than 64 bits, the equivalent function will be done with that entire block. + For example, a 16-octet block algorithm would operate on 16 octets, + and then produce two octets of check, and then work on 16-octet + blocks. 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 8 bytes of random data prefixed to - the plaintext to produce C1-C8, the first 8 bytes of ciphertext. + 3. FRE is xored with the first 8 octets of random data prefixed to + the plaintext to produce C1-C8, the first 8 octets of + ciphertext. 4. FR is loaded with C1-C8. 5. FR is encrypted to produce FRE, the encryption of the first 8 - bytes of ciphertext. + octets of ciphertext. - 6. The left two bytes of FRE get xored with the next two bytes of + 6. The left two octets of FRE get xored with the next two octets of data that were prefixed to the plaintext. This produces C9-C10, - the next two bytes of ciphertext. + the next two octets of ciphertext. 7. (The resync step) FR is loaded with C3-C10. 8. FR is encrypted to produce FRE. - 9. FRE is xored with the first 8 bytes of the given plaintext, now - that we have finished encrypting the 10 bytes of prefixed data. - This produces C11-C18, the next 8 bytes of ciphertext. + 9. FRE is xored with the first 8 octets of the given plaintext, now + that we have finished encrypting the 10 octets of prefixed data. + This produces C11-C18, the next 8 octets of ciphertext. 10. FR is loaded with C11-C18 11. FR is encrypted to produce FRE. - 12. FRE is xored with the next 8 bytes of plaintext, to produce the - next 8 bytes of ciphertext. These are loaded into FR and the + 12. FRE is xored with the next 8 octets of plaintext, to produce the + next 8 octets of ciphertext. These are loaded into FR and the process is repeated until the plaintext is 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 @@ -2729,22 +2792,22 @@ vexing than large differences. Thus, this list of potential problems and gotchas for a developer who is trying to be backward-compatible. * PGP 5.x does not accept V4 signatures for anything other than key material. * PGP 5.x does not recognize the "five-octet" lengths in new-format headers or in signature subpacket lengths. * PGP 5.0 rejects an encrypted session key if the keylength - differs from the the S2K symmetric algorithm. This is a bug in - its validation function. + differs from the S2K symmetric algorithm. This is a bug in its + validation function. * PGP 5.0 does not handle multiple one-pass signature headers and trailers. Signing one will compress the one-pass signed literal and prefix a V3 signature instead of doing a nested one-pass signature. * When exporting a private key, PGP 2.x generates the header "BEGIN PGP SECRET KEY BLOCK" instead of "BEGIN PGP PRIVATE KEY BLOCK". All previous versions ignore the implied data type, and look directly at the packet data type. @@ -2754,27 +2817,27 @@ a mismatch between the header and the actual agorithm used. The "standard" (i.e. Zimmermann/Finney/et al.) version of PGP 2.x rejects the "Hash:" header and assumes MD5. There are a number of enhanced variants of PGP 2.6.x that have been modified for SHA-1 signatures. * PGP 5.0 can read an RSA key in V4 format, but can only recognize it with a V3 keyid, and can properly use only a V3 format RSA key. - * There are many ways possible for 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. + * 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 implemtation is using zlib to interoperate with PGP 2.x, then the "windowBits" parameter should be set to -13. 15. Authors and Working Group Chair The working group can be contacted via the current chair: John W. Noerenberg, II Qualcomm, Inc @@ -2806,21 +2869,21 @@ Email: hal@pgp.com Rodney Thayer EIS Corporation Clearwater, FL 33767, USA Email: rodney@unitran.com 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 + Levien, Colin Plumb, Will Price, William Stallings, Mark Weaver, and Philip R. Zimmermann. 16. 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 @@ -2871,20 +2934,22 @@ [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. + [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", May 1997 + 17. 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