Network Working Group J. Callas
Request for Comments: 2440 Network Associates
Category: Standards Track L. Donnerhacke
IN-Root-CA Individual Network e.V.
H. Finney
Network Associates
R. Thayer
EIS Corporation
November 1998
Network Working Group J. Callas
Request for Comments: 2440 Network Associates
Category: Standards Track L. Donnerhacke
IN-Root-CA Individual Network e.V.
H. Finney
Network Associates
R. Thayer
EIS Corporation
November 1998
OpenPGP Message Format
OpenPGP消息格式
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
IESG Note
IESG注释
This document defines many tag values, yet it doesn't describe a mechanism for adding new tags (for new features). Traditionally the Internet Assigned Numbers Authority (IANA) handles the allocation of new values for future expansion and RFCs usually define the procedure to be used by the IANA. However, there are subtle (and not so subtle) interactions that may occur in this protocol between new features and existing features which result in a significant reduction in over all security. Therefore, this document does not define an extension procedure. Instead requests to define new tag values (say for new encryption algorithms for example) should be forwarded to the IESG Security Area Directors for consideration or forwarding to the appropriate IETF Working Group for consideration.
本文档定义了许多标记值，但没有描述添加新标记（用于新功能）的机制。传统上，互联网分配号码管理局（IANA）处理未来扩展的新值分配，RFC通常定义IANA使用的程序。然而，在这个协议中，新特性和现有特性之间可能会发生微妙的（并非如此微妙的）交互，从而导致总体安全性的显著降低。因此，本文件未定义扩展程序。相反，定义新标签值的请求（例如新的加密算法）应转发给IESG安全区域主管以供考虑，或转发给相应的IETF工作组以供考虑。
Abstract
摘要
This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does,
维护本文档是为了发布开发基于OpenPGP格式的可互操作应用程序所需的所有必要信息。它不是编写应用程序的一本循序渐进的食谱。它仅描述读取、检查、生成和写入跨任何网络的一致性数据包所需的格式和方法。它不处理存储和实现问题。是的，
however, discuss implementation issues necessary to avoid security flaws.
但是，请讨论避免安全缺陷所必需的实现问题。
Open-PGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP.
OpenPGP软件结合使用强公钥和对称加密技术，为电子通信和数据存储提供安全服务。这些服务包括保密性、密钥管理、身份验证和数字签名。本文档指定了OpenPGP中使用的消息格式。
Table of Contents
目录
Status of this Memo 1 IESG Note 1 Abstract 1 Table of Contents 2 1. Introduction 4 1.1. Terms 5 2. General functions 5 2.1. Confidentiality via Encryption 5 2.2. Authentication via Digital signature 6 2.3. Compression 7 2.4. Conversion to Radix-64 7 2.5. Signature-Only Applications 7 3. Data Element Formats 7 3.1. Scalar numbers 8 3.2. Multi-Precision Integers 8 3.3. Key IDs 8 3.4. Text 8 3.5. Time fields 9 3.6. String-to-key (S2K) specifiers 9 3.6.1. String-to-key (S2k) specifier types 9 3.6.1.1. Simple S2K 9 3.6.1.2. Salted S2K 10 3.6.1.3. Iterated and Salted S2K 10 3.6.2. String-to-key usage 11 3.6.2.1. Secret key encryption 11 3.6.2.2. Symmetric-key message encryption 11 4. Packet Syntax 12 4.1. Overview 12 4.2. Packet Headers 12 4.2.1. Old-Format Packet Lengths 13 4.2.2. New-Format Packet Lengths 13 4.2.2.1. One-Octet Lengths 14 4.2.2.2. Two-Octet Lengths 14 4.2.2.3. Five-Octet Lengths 14 4.2.2.4. Partial Body Lengths 14 4.2.3. Packet Length Examples 14
本备忘录的状态1 IESG注释1摘要1目录2 1。导言4.1.1。条款5.2。一般职能5 2.1。通过加密5.2.2保密。通过数字签名进行身份验证6 2.3。压缩7.2.4。转换为基数64 7 2.5。只供签署的申请7 3。数据元素格式7 3.1。标量数字8 3.2。多精度整数8 3.3。密钥IDS8 3.4。案文8 3.5。时间域9 3.6。字符串到键（S2K）说明符9 3.6.1。字符串到键（S2k）说明符类型9 3.6.1.1。简单S2K 9 3.6.1.2。盐渍S2K 10 3.6.1.3。迭代和腌制S2K 10 3.6.2。字符串到键的用法11 3.6.2.1。密钥加密11 3.6.2.2。对称密钥消息加密11 4。数据包语法12 4.1。概览12 4.2。数据包头12 4.2.1。旧格式数据包长度13 4.2.2。新格式数据包长度13 4.2.2.1。一个八位组长度14 4.2.2.2。两个八位组长度14 4.2.2.3。五个八位组长度14 4.2.2.4。部分车身长度14 4.2.3。包长度示例14
4.3. Packet Tags 15 5. Packet Types 16 5.1. Public-Key Encrypted Session Key Packets (Tag 1) 16 5.2. Signature Packet (Tag 2) 17 5.2.1. Signature Types 17 5.2.2. Version 3 Signature Packet Format 19 5.2.3. Version 4 Signature Packet Format 21 5.2.3.1. Signature Subpacket Specification 22 5.2.3.2. Signature Subpacket Types 24 5.2.3.3. Signature creation time 25 5.2.3.4. Issuer 25 5.2.3.5. Key expiration time 25 5.2.3.6. Preferred symmetric algorithms 25 5.2.3.7. Preferred hash algorithms 25 5.2.3.8. Preferred compression algorithms 26 5.2.3.9. Signature expiration time 26 5.2.3.10.Exportable Certification 26 5.2.3.11.Revocable 27 5.2.3.12.Trust signature 27 5.2.3.13.Regular expression 27 5.2.3.14.Revocation key 27 5.2.3.15.Notation Data 28 5.2.3.16.Key server preferences 28 5.2.3.17.Preferred key server 29 5.2.3.18.Primary user id 29 5.2.3.19.Policy URL 29 5.2.3.20.Key Flags 29 5.2.3.21.Signer's User ID 30 5.2.3.22.Reason for Revocation 30 5.2.4. Computing Signatures 31 5.2.4.1. Subpacket Hints 32 5.3. Symmetric-Key Encrypted Session-Key Packets (Tag 3) 32 5.4. One-Pass Signature Packets (Tag 4) 33 5.5. Key Material Packet 34 5.5.1. Key Packet Variants 34 5.5.1.1. Public Key Packet (Tag 6) 34 5.5.1.2. Public Subkey Packet (Tag 14) 34 5.5.1.3. Secret Key Packet (Tag 5) 35 5.5.1.4. Secret Subkey Packet (Tag 7) 35 5.5.2. Public Key Packet Formats 35 5.5.3. Secret Key Packet Formats 37 5.6. Compressed Data Packet (Tag 8) 38 5.7. Symmetrically Encrypted Data Packet (Tag 9) 39 5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 39 5.9. Literal Data Packet (Tag 11) 40 5.10. Trust Packet (Tag 12) 40 5.11. User ID Packet (Tag 13) 41 6. Radix-64 Conversions 41
4.3. 包标签15 5。数据包类型16 5.1。公钥加密会话密钥包（标签1）16 5.2。签名包（标签2）17 5.2.1。签名类型17 5.2.2。版本3签名包格式19 5.2.3。版本4签名包格式21 5.2.3.1。签名子包规范22 5.2.3.2。签名子包类型24 5.2.3.3。签名创建时间25 5.2.3.4。发行人25.5.2.3.5。密钥过期时间25 5.2.3.6。首选对称算法25 5.2.3.7。首选哈希算法25 5.2.3.8。首选压缩算法26 5.2.3.9。签名过期时间26 5.2.3.10.可导出证书26 5.2.3.11.可撤销27 5.2.3.12.信任签名27 5.2.3.13.正则表达式27 5.2.3.14.撤销密钥27 5.2.3.15.注释数据28 5.2.3.16.密钥服务器首选项28 5.2.3.17.首选密钥服务器29 5.2.3.18.主用户id 29 5.2.3.19.策略URL 29 5.2.3.20.密钥标志295.2.3.21.签名人的用户ID 30 5.2.3.22.撤销原因30 5.2.4。计算签名31 5.2.4.1。子包提示32 5.3。对称密钥加密会话密钥包（标记3）32 5.4。一次性签名包（标签4）33 5.5。关键材料包34 5.5.1。密钥包变体34 5.5.1.1。公钥包（标签6）34 5.5.1.2。公开子密钥包（标签14）34 5.5.1.3。密钥包（标签5）35 5.5.1.4。秘密子密钥包（标签7）35 5.5.2。公钥数据包格式35 5.5.3。密钥包格式37 5.6。压缩数据包（标签8）38 5.7。对称加密数据包（标签9）39 5.8。标记包（废弃文字包）（标记10）395.9。文字数据包（标签11）40 5.10。信任包（标签12）40 5.11。用户ID数据包（标签13）416。基数-64转换41
6.1. An Implementation of the CRC-24 in "C" 42 6.2. Forming ASCII Armor 42 6.3. Encoding Binary in Radix-64 44 6.4. Decoding Radix-64 46 6.5. Examples of Radix-64 46 6.6. Example of an ASCII Armored Message 47 7. Cleartext signature framework 47 7.1. Dash-Escaped Text 47 8. Regular Expressions 48 9. Constants 49 9.1. Public Key Algorithms 49 9.2. Symmetric Key Algorithms 49 9.3. Compression Algorithms 50 9.4. Hash Algorithms 50 10. Packet Composition 50 10.1. Transferable Public Keys 50 10.2. OpenPGP Messages 52 10.3. Detached Signatures 52 11. Enhanced Key Formats 52 11.1. Key Structures 52 11.2. Key IDs and Fingerprints 53 12. Notes on Algorithms 54 12.1. Symmetric Algorithm Preferences 54 12.2. Other Algorithm Preferences 55 12.2.1. Compression Preferences 56 12.2.2. Hash Algorithm Preferences 56 12.3. Plaintext 56 12.4. RSA 56 12.5. Elgamal 57 12.6. DSA 58 12.7. Reserved Algorithm Numbers 58 12.8. OpenPGP CFB mode 58 13. Security Considerations 59 14. Implementation Nits 60 15. Authors and Working Group Chair 62 16. References 63 17. Full Copyright Statement 65
6.1. “C”42 6.2中CRC-24的实现。形成ASCII装甲42 6.3。以基数64 44 6.4对二进制进行编码。解码基数64 46 6.5。基数64 46 6.6的示例。ASCII铠装消息的示例47 7。明文签名框架477.1。破折号转义文本478。正则表达式48 9。常数49 9.1。公钥算法499.2。对称密钥算法499.3。压缩算法509.4。散列算法50 10。数据包组成50 10.1。可转让公钥50 10.2。OpenPGP消息52 10.3。签名52 11。增强型密钥格式52 11.1。关键结构52 11.2。密钥ID和指纹53 12。算法注释54 12.1。对称算法偏好5412.2。其他算法首选项55 12.2.1。压缩首选项56 12.2.2。哈希算法首选项56 12.3。明文56 12.4。RSA 56 12.5。埃尔加马尔57 12.6。DSA 58 12.7。保留算法编号58 12.8。OpenPGP循环流化床模式58 13。安全考虑59 14。实施Nits 60 15。作者和工作组主席62 16。参考文献63 17。完整版权声明65
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."
本文档提供有关OpenPGP用于提供加密、解密、签名和密钥管理功能的消息交换数据包格式的信息。它是建立在RFC 1991“PGP消息交换格式”的基础上的。
* OpenPGP - This is a definition for security software that uses PGP 5.x as a basis.
* OpenPGP-这是一个安全软件的定义，使用PGP5.x作为基础。
* PGP - Pretty Good Privacy. PGP is a family of software systems developed by Philip R. Zimmermann from which OpenPGP is based.
* PGP-相当好的隐私。PGP是由Philip R.Zimmermann开发的一系列软件系统，OpenPGP就是基于这些系统开发的。
* 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. An informational RFC, RFC 1991, was written describing this version of PGP.
* PGP2.6.x-此版本的PGP有许多变体，因此称为PGP2.6.x。它只使用RSA、MD5和IDEA进行加密转换。一份信息RFC，RFC1991，描述了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, RFC 1991. 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 5.x-该版本的PGP在社区中以前称为“PGP 3”，也是本文件的前身RFC 1991。它有新的格式，并纠正了PGP2.6.x设计中的一些问题。这里称之为PGP5.x，因为该软件是“PGP3”代码库的第一个版本。
"PGP", "Pretty Good", and "Pretty Good Privacy" are trademarks of Network Associates, Inc. and are used with permission.
“PGP”、“相当好”和“相当好的隐私”是Network Associates，Inc.的商标，在获得许可后使用。
This document uses the terms "MUST", "SHOULD", and "MAY" as defined in RFC 2119, along with the negated forms of those terms.
本文件使用RFC 2119中定义的术语“必须”、“应该”和“可以”，以及这些术语的否定形式。
OpenPGP provides data integrity services for messages and data files by using these core technologies:
OpenPGP使用以下核心技术为消息和数据文件提供数据完整性服务：
- digital signatures
- 数字签名
- encryption
- 加密
- compression
- 压缩
- radix-64 conversion
- 基数-64转换
In addition, OpenPGP provides key management and certificate services, but many of these are beyond the scope of this document.
此外，OpenPGP提供了密钥管理和证书服务，但其中许多服务超出了本文的范围。
OpenPGP uses two encryption methods to provide confidentiality: symmetric-key encryption and public key encryption. With public-key encryption, the object is encrypted using a symmetric encryption algorithm. Each symmetric key is used only once. A new "session key" is generated as a random number for each message. Since it is used
OpenPGP使用两种加密方法来提供机密性：对称密钥加密和公钥加密。使用公钥加密时，使用对称加密算法对对象进行加密。每个对称密钥只使用一次。为每条消息生成一个新的“会话密钥”，作为一个随机数。因为它被使用了
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.
1. 发送者创建一条消息。
2. The sending OpenPGP generates a random number to be used as a session key for this message only.
2. 发送OpenPGP生成一个随机数，仅用作此消息的会话密钥。
3. The session key is encrypted using each recipient's public key. These "encrypted session keys" start the message.
3. 会话密钥使用每个收件人的公钥加密。这些“加密会话密钥”启动消息。
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.
4. 发送OpenPGP使用会话密钥加密消息，会话密钥构成消息的其余部分。请注意，消息通常也是压缩的。
5. The receiving OpenPGP decrypts the session key using the recipient's private key.
5. 接收OpenPGP使用接收方的私钥解密会话密钥。
6. The receiving OpenPGP decrypts the message using the session key. If the message was compressed, it will be decompressed.
6. 接收OpenPGP使用会话密钥对消息进行解密。如果消息被压缩，它将被解压缩。
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.
数字签名和保密服务均可应用于同一电文。首先，为消息生成签名并附加到消息。然后，使用对称会话密钥对消息加签名进行加密。最后，使用公钥加密对会话密钥进行加密，并将其作为加密块的前缀。
The digital signature uses a hash code or message digest algorithm, and a public-key signature algorithm. The sequence is as follows:
数字签名使用散列码或消息摘要算法以及公钥签名算法。顺序如下：
1. The sender creates a message.
1. 发送者创建一条消息。
2. The sending software generates a hash code of the message.
2. 发送软件生成消息的哈希代码。
3. The sending software generates a signature from the hash code using the sender's private key.
3. 发送软件使用发送方的私钥从散列码生成签名。
4. The binary signature is attached to the message.
4. 二进制签名附加到消息。
5. The receiving software keeps a copy of the message signature.
5. 接收软件保留消息签名的副本。
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.
6. 接收软件为接收到的消息生成一个新的哈希代码，并使用消息的签名对其进行验证。如果验证成功，则消息将被视为真实消息。
OpenPGP implementations MAY compress the message after applying the signature but before encryption.
OpenPGP实现可以在应用签名后但在加密之前压缩消息。
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.
OpenPGP对加密消息、签名证书和密钥的底层本机表示是任意八位字节流。有些系统只允许使用由七位可打印文本组成的块。为了通过对原始二进制数据不安全的通道传输OpenPGP的原生原始二进制八位字节，需要对这些二进制八位字节进行可打印的编码。OpenPGP提供将原始8位二进制八位字节流转换为可打印ASCII字符流的服务，称为基数64编码或ASCII码。
Implementations SHOULD provide Radix-64 conversions.
实现应该提供基数-64转换。
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.
请注意，许多应用程序，特别是消息传递应用程序，将需要OpenPGP MIME文档RFC 2015中描述的更高级的功能。实现OpenPGP消息传递的应用程序应该实现OpenPGP MIME。
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.
OpenPGP是为同时使用加密和签名的应用程序而设计的，但是有许多问题可以通过只使用签名的实现来解决。尽管本规范要求加密和签名，但存在不一致的子集实现是合理的，因为它们省略了加密。
This section describes the data elements used by OpenPGP.
本节介绍OpenPGP使用的数据元素。
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]).
标量数是无符号的，并且始终以大端格式存储。使用n[k]表示被解释的第k个八位元，两个八位元标量的值为（（n[0]<<8）+n[1]）。四个八位组标量的值是（（n[0]<<24）+（n[1]<<16）+（n[2]<<8）+n[3]）。
Multi-Precision Integers (also called MPIs) are unsigned integers used to hold large integers such as the ones used in cryptographic calculations.
多精度整数（也称为MPI）是无符号整数，用于保存大整数，如加密计算中使用的整数。
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.
MPI由两部分组成：两个八位元标量，即MPI的长度（以位为单位），后跟一个包含实际整数的八位元字符串。
These octets form a big-endian number; a big-endian number can be made into an MPI by prefixing it with the appropriate length.
这些八位元组成一个大端数；大端数字可以通过在其前面加上适当长度的前缀而成为MPI。
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.
八位字节字符串[00 01 01]形成值为1的MPI。字符串[00 09 01 FF]形成一个值为511的MPI。
Additional rules:
其他规则：
The size of an MPI is ((MPI.length + 7) / 8) + 2 octets.
MPI的大小为（（MPI.length+7）/8）+2个八位字节。
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].
MPI的长度字段描述从其最高有效非零位开始的长度。因此，MPI[00 02 01]没有正确形成。它应该是[00 01]。
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.
密钥ID是标识密钥的八个八位字节标量。实现不应假定密钥ID是唯一的。下面的“增强型密钥格式”部分描述了密钥ID的形成方式。
The default character set for text is the UTF-8 [RFC2279] encoding of Unicode [ISO10646].
文本的默认字符集是Unicode[ISO10646]的UTF-8[RFC2279]编码。
A time field is an unsigned four-octet number containing the number of seconds elapsed since midnight, 1 January 1970 UTC.
时间字段是一个无符号的四个八位数字，包含自UTC 1970年1月1日午夜以来经过的秒数。
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.
字符串到密钥（S2K）说明符用于将密码短语字符串转换为对称密钥加密/解密密钥。它们目前用于两个地方：加密私钥环中私钥的秘密部分，以及将密码短语转换为对称加密消息的加密密钥。
There are three types of S2K specifiers currently supported, as follows:
目前支持三种类型的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
八位组0:0x00八位组1:哈希算法
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.
简单S2K对密码短语进行散列以生成会话密钥。执行此操作的方式取决于会话密钥的大小（取决于使用的密码）和哈希算法输出的大小。如果哈希大小大于或等于会话密钥大小，则哈希的高阶（最左侧）八位字节将用作密钥。
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).
如果哈希大小小于密钥大小，则会创建哈希上下文的多个实例——足以生成所需的密钥数据。这些实例预先加载了0、1、2、。。。八位字节的零（也就是说，第一个实例没有预加载，第二个实例预加载了一个八位字节的零，第三个实例预加载了两个八位字节的零，依此类推）。
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.
当数据被散列时，它被独立地提供给每个散列上下文。由于上下文的初始化方式不同，它们将各自生成不同的哈希输出。对密码短语进行散列后，将多个散列的输出数据连接起来，首先是最左边的散列，以生成密钥数据，并丢弃右边多余的八位字节。
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.
这包括S2K说明符中的一个“salt”值——一些任意数据——与密码短语字符串一起散列，以帮助防止字典攻击。
Octet 0: 0x01 Octet 1: hash algorithm Octets 2-9: 8-octet salt value
八位字节0:0x01八位字节1:哈希算法八位字节2-9:8-八位字节盐值
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.
salteds2k与简单的S2K完全相同，只是散列函数的输入由来自S2K说明符的8个八位组salt组成，后跟密码短语。
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.
这包括salt和octet计数。salt与密码短语组合，结果值反复散列。这进一步增加了攻击者尝试字典攻击的工作量。
Octet 0: 0x03 Octet 1: hash algorithm Octets 2-9: 8-octet salt value Octet 10: count, a one-octet, coded value
八位字节0:0x03八位字节1:哈希算法八位字节2-9:8-八位字节盐值八位字节10:计数，一个八位字节，编码值
The count is coded into a one-octet number using the following formula:
使用以下公式将计数编码为一个八位字节数：
#define EXPBIAS 6
count = ((Int32)16 + (c & 15)) << ((c >> 4) + EXPBIAS);
#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.
上面的公式是用C表示的，其中“Int32”是32位整数的类型，变量“C”是编码计数，八位组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.
迭代salteds2k多次散列密码短语和salt数据。要散列的八位字节总数在S2K说明符中的编码计数中指定。请注意，结果计数值是将散列多少个八位字节的八位字节计数，而不是迭代计数。
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.
最初，与其他S2K算法一样设置一个或多个哈希上下文，具体取决于需要多少个八位字节的关键数据。然后对salt和密码短语数据进行反复散列，直到对八位字节计数指定的八位字节数进行散列。一个例外是，如果八位字节数小于salt plus密码短语的大小，则将散列完整的salt plus密码短语，即使该值大于八位字节数。
After the hashing is done the data is unloaded from the hash context(s) as with the other S2K algorithms.
散列完成后，与其他S2K算法一样，从散列上下文卸载数据。
Implementations SHOULD use salted or iterated-and-salted S2K specifiers, as simple S2K specifiers are more vulnerable to dictionary attacks.
实现应该使用salted或迭代salted S2K说明符，因为简单的S2K说明符更容易受到字典攻击。
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.
可以在密钥环中存储S2K说明符，以指定如何将密码短语转换为解锁机密数据的密钥。较旧版本的PGP只在机密数据之前存储一个密码算法八位字节，或存储一个零以指示机密数据未加密。MD5哈希函数始终用于将密码短语转换为指定密码算法的密钥。
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.
为了兼容性，当使用S2K说明符时，将特殊值255存储在哈希算法八位组在旧数据结构中的位置。然后紧接着是一个八位字节算法标识符，然后是如上编码的S2K说明符。
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
0：秘密数据未加密（无密码短语）255：后跟算法八位组和S2K说明符密码alg：使用简单的S2K算法，使用MD5哈希
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.
最后一种可能性，即隐式使用MD5和IDEA的密码算法编号，用于向后兼容；它可以理解，但不应生成，因此不推荐使用。
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.
然后是一个8-octet初始向量，用于解密加密后的秘密值，然后是秘密密钥值本身。
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.
OpenPGP可以在消息前面创建对称密钥加密会话密钥（ESK）数据包。这用于允许S2K说明符用于密码短语转换或创建混合使用对称密钥ESK和公钥ESK的消息。这允许使用密码短语或公钥对消息进行解密。
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.
在使用对称算法加密消息时，PGP2.X始终使用IDEA进行简单的字符串到密钥转换。这已被弃用，但可用于向后兼容。
This section describes the packets used by OpenPGP.
本节介绍OpenPGP使用的数据包。
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).
OpenPGP消息由许多传统上称为数据包的记录构成。数据包是一块数据，它有一个指定其含义的标记。OpenPGP消息、密钥环、证书等由许多数据包组成。其中一些包可能包含其他OpenPGP包（例如，压缩数据包在未压缩时包含OpenPGP包）。
Each packet consists of a packet header, followed by the packet body. The packet header is of variable length.
每个数据包由数据包头和数据包体组成。数据包头的长度可变。
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.
请注意，最高有效位是最左边的位，称为位7。此位的掩码是十六进制的0x80。
+---------------+
PTag |7 6 5 4 3 2 1 0|
+---------------+
Bit 7 -- Always one
Bit 6 -- New packet format if set
+---------------+
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.
PGP2.6.x仅使用旧格式数据包。因此，与这些版本的PGP交互的软件必须只使用旧格式的数据包。如果互操作性不是问题，则可以使用任何一种格式。请注意，旧格式数据包有四位内容标签，而新格式数据包有六位内容标签；某些功能无法使用，并且仍然向后兼容。
Old format packets contain:
旧格式数据包包含：
Bits 5-2 -- content tag Bits 1-0 - length-type
位5-2——内容标签位1-0——长度类型
New format packets contain:
新格式数据包包含：
Bits 5-0 -- content tag
位5-0——内容标签
The meaning of the length-type in old-format packets is:
旧格式数据包中长度类型的含义为：
0 - The packet has a one-octet length. The header is 2 octets long.
0-数据包的长度为一个八位字节。报头有2个八位字节长。
1 - The packet has a two-octet length. The header is 3 octets long.
1-数据包有两个八位组长度。报头有3个八位字节长。
2 - The packet has a four-octet length. The header is 5 octets long.
2-数据包的长度为四个八位组。标题长度为5个八位字节。
3 - The packet is of indeterminate length. The header is 1 octet long, and the implementation must determine how long the packet is. If the packet is in a file, this means that the packet extends until the end of the file. In general, an implementation SHOULD NOT use indeterminate length packets except where the end of the data will be clear from the context, and even then it is better to use a definite length, or a new-format header. The new-format headers described below have a mechanism for precisely encoding data of indeterminate length.
3-数据包的长度不确定。报头长度为1个八位字节，实现必须确定数据包的长度。如果数据包在文件中，这意味着数据包将一直扩展到文件的末尾。一般来说，一个实现不应该使用不确定长度的数据包，除非数据的结尾可以从上下文中清除，甚至最好使用一个确定的长度或一个新的格式头。下面描述的新格式头具有精确编码不确定长度数据的机制。
New format packets have four possible ways of encoding length:
新格式数据包有四种可能的长度编码方式：
1. A one-octet Body Length header encodes packet lengths of up to 191 octets.
1. 一个八位字节体长的报头编码最多191个八位字节的数据包长度。
2. A two-octet Body Length header encodes packet lengths of 192 to 8383 octets.
2. 两个八位字节的正文长度报头编码192到8383个八位字节的数据包长度。
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.)
3. 五个八位字节的正文长度报头编码的数据包长度最多为4294967295（0xFFFFFF）个八位字节。（这实际上编码了一个四个八位组的标量数。）
4. When the length of the packet body is not known in advance by the issuer, Partial Body Length headers encode a packet of indeterminate length, effectively making it a stream.
4. 当发卡机构事先不知道包体的长度时，部分包体长度报头对长度不确定的包进行编码，有效地使其成为流。
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:
一个八位字节正文长度报头编码0到191个八位字节的长度。由于一个八位字节的值小于192，因此可以识别这种类型的长度标头。主体长度等于：
bodyLen = 1st_octet;
bodyLen=第一个八位组；
A two-octet Body Length header encodes a length of from 192 to 8383 octets. It is recognized because its first octet is in the range 192 to 223. The body length is equal to:
两个八位字节的正文长度报头编码192到8383个八位字节的长度。它被识别是因为它的第一个八位组在192到223之间。主体长度等于：
bodyLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192
bodyLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192
A five-octet Body Length header consists of a single octet holding the value 255, followed by a four-octet scalar. The body length is equal to:
五个八位字节的正文长度标头由一个包含值255的八位字节组成，后跟一个四个八位字节的标量。主体长度等于：
bodyLen = (2nd_octet << 24) | (3rd_octet << 16) |
(4th_octet << 8) | 5th_octet
bodyLen = (2nd_octet << 24) | (3rd_octet << 16) |
(4th_octet << 8) | 5th_octet
A Partial Body Length header is one octet long and encodes the length of only part of the data packet. This length is a power of 2, from 1 to 1,073,741,824 (2 to the 30th power). It is recognized by its one octet value that is greater than or equal to 224, and less than 255. The partial body length is equal to:
部分正文长度报头是一个八位字节长，只编码数据包的一部分长度。该长度是2的幂，从1到1073741824（2到30次方）。它通过大于或等于224且小于255的一个八位组值来识别。部分主体长度等于：
partialBodyLen = 1 << (1st_octet & 0x1f);
partialBodyLen = 1 << (1st_octet & 0x1f);
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.
每个部分正文长度报头后面跟着一部分包正文数据。“部分正文长度”标题指定此部分的长度。另一个长度头（三种类型之一——一个八位组、两个八位组或部分）位于该部分之后。数据包中的最后一个长度头不能是部分正文长度头。部分正文长度标头只能用于数据包的非最终部分。
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.
长度为100的数据包可以将其长度编码为一个八位字节：0x64。然后是100个八位字节的数据。
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.
长度为1723的数据包可以将其长度编码为两个八位字节：0xC5、0xFB。此标头后面是1723个八位字节的数据。
A packet with length 100000 may have its length encoded in five octets: 0xFF, 0x00, 0x01, 0x86, 0xA0.
长度为100000的数据包可以将其长度编码为五个八位字节：0xFF、0x00、0x01、0x86、0xA0。
It might also be encoded in the following octet stream: 0xEF, first 32768 octets of data; 0xE1, next two octets of data; 0xE0, next one octet of data; 0xF0, next 65536 octets of data; 0xC5, 0xDD, last 1693 octets of data. This is just one possible encoding, and many variations are possible on the size of the Partial Body Length headers, as long as a regular Body Length header encodes the last portion of the data. Note also that the last Body Length header can be a zero-length header.
它也可能被编码在以下八位字节流中：0xEF，数据的前32768个八位字节；0xE1，下两个八位字节的数据；0xE0，数据的下一个八位字节；0xF0，下一个65536个八位字节的数据；0xC5，0xDD，最后1693个八位字节的数据。这只是一种可能的编码，部分正文长度头的大小可能有许多变化，只要常规正文长度头编码数据的最后一部分。还请注意，最后一个正文长度标头可以是零长度标头。
An implementation MAY use Partial Body Lengths for data packets, be they literal, compressed, or encrypted. The first partial length MUST be at least 512 octets long. Partial Body Lengths MUST NOT be used for any other packet types.
一个实现可以对数据包使用部分正文长度，无论是文字、压缩还是加密。第一部分长度必须至少为512个八位字节。部分正文长度不得用于任何其他数据包类型。
Please note that in all of these explanations, the total length of the packet is the length of the header(s) plus the length of the body.
请注意，在所有这些解释中，数据包的总长度是报头的长度加上正文的长度。
The packet tag denotes what type of packet the body holds. Note that old format headers can only have tags less than 16, whereas new format headers can have tags as great as 63. The defined tags (in decimal) are:
packet标签表示主体持有的数据包类型。请注意，旧格式标头只能包含小于16的标记，而新格式标头可以包含多达63的标记。定义的标记（十进制）为：
0 -- Reserved - a packet tag must not have this value 1 -- Public-Key Encrypted Session Key Packet 2 -- Signature Packet 3 -- Symmetric-Key Encrypted Session Key Packet 4 -- One-Pass Signature Packet 5 -- Secret Key Packet 6 -- Public Key Packet 7 -- Secret Subkey Packet 8 -- Compressed Data Packet 9 -- Symmetrically Encrypted Data Packet 10 -- Marker Packet 11 -- Literal Data Packet 12 -- Trust Packet
0—保留—数据包标签不得具有此值1—公钥加密会话密钥数据包2—签名数据包3—对称密钥加密会话密钥数据包4—一次性签名数据包5—密钥数据包6—公钥数据包7—秘密子密钥数据包8—压缩数据包9—对称加密数据包10--标记包11——文字数据包12——信任包
13 -- User ID Packet 14 -- Public Subkey Packet 60 to 63 -- Private or Experimental Values
13——用户ID数据包14——公钥数据包60到63——私有值或实验值
A Public-Key Encrypted Session Key packet holds the session key used to encrypt a message. Zero or more Encrypted Session Key packets (either Public-Key or Symmetric-Key) may precede a Symmetrically Encrypted Data Packet, which holds an encrypted message. The message is encrypted with the session key, and the session key is itself encrypted and stored in the Encrypted Session Key packet(s). The Symmetrically Encrypted Data Packet is preceded by one Public-Key Encrypted Session Key packet for each OpenPGP key to which the message is encrypted. The recipient of the message finds a session key that is encrypted to their public key, decrypts the session key, and then uses the session key to decrypt the message.
公钥加密的会话密钥包包含用于加密消息的会话密钥。零个或多个加密的会话密钥包（公钥或对称密钥）可以位于对称加密的数据包之前，该数据包包含加密的消息。消息使用会话密钥加密，会话密钥本身加密并存储在加密的会话密钥包中。对称加密的数据包前面是一个公钥加密的会话密钥包，用于加密消息的每个OpenPGP密钥。消息的接收者找到一个会话密钥，该密钥加密为其公钥，解密会话密钥，然后使用会话密钥解密消息。
The body of this packet consists of:
本文件包正文包括：
- A one-octet number giving the version number of the packet type. The currently defined value for packet version is 3. An implementation should accept, but not generate a version of 2, which is equivalent to V3 in all other respects.
- 给出数据包类型版本号的一个八位字节数。数据包版本的当前定义值为3。一个实现应该接受，但不能生成2的版本，它在所有其他方面都等同于V3。
- An eight-octet number that gives the key ID of the public key that the session key is encrypted to.
- 一个八位字节的数字，给出会话密钥加密到的公钥的密钥ID。
- A one-octet number giving the public key algorithm used.
- 给出所用公钥算法的一个八位组数。
- A string of octets that is the encrypted session key. This string takes up the remainder of the packet, and its contents are dependent on the public key algorithm used.
- 作为加密会话密钥的八位字节字符串。此字符串占用数据包的其余部分，其内容取决于所使用的公钥算法。
Algorithm Specific Fields for RSA encryption
RSA加密的算法特定字段
- multiprecision integer (MPI) of RSA encrypted value m**e mod n.
- RSA加密值m**e mod n的多精度整数（MPI）。
Algorithm Specific Fields for Elgamal encryption:
Elgamal加密的算法特定字段：
- MPI of Elgamal (Diffie-Hellman) value g**k mod p.
- Elgamal（Diffie-Hellman）值g**k mod p的MPI。
- MPI of Elgamal (Diffie-Hellman) value m * y**k mod p.
- Elgamal（Diffie Hellman）值m*y**k mod p的MPI。
The value "m" in the above formulas is derived from the session key as follows. First the session key is prefixed with a one-octet algorithm identifier that specifies the symmetric encryption algorithm used to encrypt the following Symmetrically Encrypted Data Packet. Then a two-octet checksum is appended which is equal to the sum of the preceding session key octets, not including the algorithm identifier, modulo 65536. This value is then padded as described in PKCS-1 block type 02 [RFC2313] to form the "m" value used in the formulas above.
上述公式中的值“m”是从会话密钥中导出的，如下所示。首先，会话密钥以一个八位组算法标识符作为前缀，该标识符指定用于加密以下对称加密数据包的对称加密算法。然后附加两个八位组校验和，其等于前面会话密钥八位组的和，不包括算法标识符，模65536。然后按照PKCS-1块类型02[RFC2313]中的说明填充该值，以形成上述公式中使用的“m”值。
Note that when an implementation forms several PKESKs with one session key, forming a message that can be decrypted by several keys, the implementation MUST make new PKCS-1 padding for each key.
请注意，当一个实现使用一个会话密钥形成多个PKESK，形成可由多个密钥解密的消息时，该实现必须对每个密钥进行新的PKCS-1填充。
An implementation MAY accept or use a Key ID of zero as a "wild card" or "speculative" Key ID. In this case, the receiving implementation would try all available private keys, checking for a valid decrypted session key. This format helps reduce traffic analysis of messages.
实现可以接受或使用零的密钥ID作为“通配符”或“推测性”密钥ID。在这种情况下，接收实现将尝试所有可用的私钥，检查有效的解密会话密钥。这种格式有助于减少对消息的流量分析。
A signature packet describes a binding between some public key and some data. The most common signatures are a signature of a file or a block of text, and a signature that is a certification of a user ID.
签名包描述某些公钥和某些数据之间的绑定。最常见的签名是文件或文本块的签名，以及用户ID的认证签名。
Two versions of signature packets are defined. Version 3 provides basic signature information, while version 4 provides an expandable format with subpackets that can specify more information about the signature. PGP 2.6.x only accepts version 3 signatures.
定义了两个版本的签名包。版本3提供了基本的签名信息，而版本4提供了一种可扩展的格式，其子包可以指定有关签名的更多信息。PGP2.6.x仅接受版本3签名。
Implementations MUST accept V3 signatures. Implementations SHOULD generate V4 signatures. Implementations MAY generate a V3 signature that can be verified by PGP 2.6.x.
实现必须接受V3签名。实现应该生成V4签名。实现可能会生成一个V3签名，该签名可以通过PGP2.6.x进行验证。
Note that if an implementation is creating an encrypted and signed message that is encrypted to a V3 key, it is reasonable to create a V3 signature.
请注意，如果一个实现正在创建加密并签名为V3密钥的消息，那么创建V3签名是合理的。
There are a number of possible meanings for a signature, which are specified in a signature type octet in any given signature. These meanings are:
签名有许多可能的含义，这些含义在任何给定签名的签名类型八位字节中指定。这些含义是：
0x00: Signature of a binary document. Typically, this means the signer owns it, created it, or certifies that it has not been modified.
0x00：二进制文档的签名。通常，这意味着签名者拥有、创建或证明其未被修改。
0x01: Signature of a canonical text document. Typically, this means the signer owns it, created it, or certifies that it has not been modified. The signature is calculated over the text data with its line endings converted to <CR><LF> and trailing blanks removed.
0x01:规范文本文档的签名。通常，这意味着签名者拥有、创建或证明其未被修改。签名在文本数据上计算，其行尾转换为<CR><LF>，并删除尾随空格。
0x02: Standalone signature. This signature is a signature of only its own subpacket contents. It is calculated identically to a signature over a zero-length binary document. Note that it doesn't make sense to have a V3 standalone signature.
0x02：独立签名。此签名仅是其自身子包内容的签名。它的计算方法与零长度二进制文档上的签名相同。请注意，使用V3独立签名是没有意义的。
0x10: Generic certification of a User ID and Public Key packet. The issuer of this certification does not make any particular assertion as to how well the certifier has checked that the owner of the key is in fact the person described by the user ID. Note that all PGP "key signatures" are this type of certification.
0x10：用户ID和公钥数据包的通用认证。该认证的颁发者未就认证者检查密钥所有者实际上是用户ID所述的人的情况做出任何特定断言。请注意，所有PGP“密钥签名”均为此类认证。
0x11: Persona certification of a User ID and Public Key packet. The issuer of this certification has not done any verification of the claim that the owner of this key is the user ID specified.
0x11：用户ID和公钥数据包的角色认证。此证书的颁发者尚未对该密钥的所有者是指定用户ID的声明进行任何验证。
0x12: Casual certification of a User ID and Public Key packet. The issuer of this certification has done some casual verification of the claim of identity.
0x12：用户ID和公钥数据包的临时认证。本证书的颁发者对身份声明进行了一些偶然的验证。
0x13: Positive certification of a User ID and Public Key packet. The issuer of this certification has done substantial verification of the claim of identity.
0x13：用户ID和公钥数据包的肯定认证。本证书的颁发者已对身份声明进行了实质性验证。
Please note that the vagueness of these certification claims is not a flaw, but a feature of the system. Because PGP places final authority for validity upon the receiver of a certification, it may be that one authority's casual certification might be more rigorous than some other authority's positive certification. These classifications allow a certification authority to issue fine-grained claims.
请注意，这些认证声明的模糊性不是一个缺陷，而是系统的一个特征。由于PGP将有效性的最终授权放在认证的接收者身上，因此一个认证机构的临时认证可能比其他认证机构的肯定认证更严格。这些分类允许证书颁发机构发布细粒度声明。
0x18: Subkey Binding Signature This signature is a statement by the top-level signing key indicates that it owns the subkey. This signature is calculated directly on the subkey itself, not on any User ID or other packets.
0x18:子密钥绑定签名此签名是由顶级签名密钥表示其拥有子密钥的语句。此签名直接在子密钥本身上计算，而不是在任何用户ID或其他数据包上计算。
0x1F: Signature directly on a key This signature is calculated directly on a key. It binds the information in the signature subpackets to the key, and is appropriate to be used for subpackets that provide information about the key, such as the revocation key subpacket. It is also appropriate for statements that non-self certifiers want to make about the key itself, rather than the binding between a key and a name.
0x1F:直接在密钥上签名此签名直接在密钥上计算。它将签名子包中的信息绑定到密钥，并且适合用于提供密钥信息的子包，例如吊销密钥子包。它也适用于非自证明者希望对密钥本身而不是密钥和名称之间的绑定做出的声明。
0x20: Key revocation signature The signature is calculated directly on the key being revoked. A revoked key is not to be used. Only revocation signatures by the key being revoked, or by an authorized revocation key, should be considered valid revocation signatures.
0x20：密钥撤销签名签名直接在被撤销的密钥上计算签名。不能使用已吊销的密钥。只有被撤销密钥或授权撤销密钥的撤销签名才应被视为有效的撤销签名。
0x28: Subkey revocation signature The signature is calculated directly on the subkey being revoked. A revoked subkey is not to be used. Only revocation signatures by the top-level signature key that is bound to this subkey, or by an authorized revocation key, should be considered valid revocation signatures.
0x28：子密钥撤销签名签名直接在被撤销的子密钥上计算签名。不能使用已撤销的子项。只有由绑定到此子密钥的顶级签名密钥或由授权的吊销密钥生成的吊销签名才应被视为有效的吊销签名。
0x30: Certification revocation signature This signature revokes an earlier user ID certification signature (signature class 0x10 through 0x13). It should be issued by the same key that issued the revoked signature or an authorized revocation key The signature should have a later creation date than the signature it revokes.
0x30：证书撤销签名此签名撤销早期用户ID证书签名（签名类0x10到0x13）。它应该由发布已撤销签名的同一密钥或授权撤销密钥发布。签名的创建日期应该晚于其撤销的签名。
0x40: Timestamp signature. This signature is only meaningful for the timestamp contained in it.
0x40：时间戳签名。此签名仅对其中包含的时间戳有意义。
The body of a version 3 Signature Packet contains:
版本3签名包的正文包含：
- One-octet version number (3).
- 一个八位组版本号（3）。
- One-octet length of following hashed material. MUST be 5.
- 以下哈希材料的一个八位字节长度。必须是5岁。
- One-octet signature type.
- 一个八位组签名类型。
- Four-octet creation time.
- 四个八位组的创建时间。
- Eight-octet key ID of signer.
- 签名者的八个八位组密钥ID。
- One-octet public key algorithm.
- 一个八位组公钥算法。
- One-octet hash algorithm.
- 一个八位组哈希算法。
- Two-octet field holding left 16 bits of signed hash value.
- 两个八位字节字段，保存有符号哈希值的左16位。
- One or more multi-precision integers comprising the signature. This portion is algorithm specific, as described below.
- 包含签名的一个或多个多精度整数。这一部分是特定于算法的，如下所述。
The data being signed is hashed, and then the signature type and creation time from the signature packet are hashed (5 additional octets). The resulting hash value is used in the signature algorithm. The high 16 bits (first two octets) of the hash are included in the signature packet to provide a quick test to reject some invalid signatures.
对正在签名的数据进行散列，然后对签名包中的签名类型和创建时间进行散列（5个额外的八位字节）。生成的哈希值用于签名算法。哈希的高16位（前两个八位字节）包含在签名包中，以提供拒绝某些无效签名的快速测试。
Algorithm Specific Fields for RSA signatures:
RSA签名的算法特定字段：
- multiprecision integer (MPI) of RSA signature value m**d.
- RSA签名值m**d的多精度整数（MPI）。
Algorithm Specific Fields for DSA signatures:
DSA签名的算法特定字段：
- MPI of DSA value r.
- DSA值r的MPI。
- MPI of DSA value s.
- DSA值的MPI。
The signature calculation is based on a hash of the signed data, as described above. The details of the calculation are different for DSA signature than for RSA signatures.
如上所述，签名计算基于签名数据的散列。DSA签名的计算细节与RSA签名的计算细节不同。
With RSA signatures, the hash value is encoded as described in PKCS-1 section 10.1.2, "Data encoding", producing an ASN.1 value of type DigestInfo, and then padded using PKCS-1 block type 01 [RFC2313]. This requires inserting the hash value as an octet string into an ASN.1 structure. The object identifier for the type of hash being used is included in the structure. The hexadecimal representations for the currently defined hash algorithms are:
对于RSA签名，按照PKCS-1第10.1.2节“数据编码”中的说明对哈希值进行编码，生成DigestInfo类型的ASN.1值，然后使用PKCS-1块类型01[RFC2313]进行填充。这需要将哈希值作为八位字节字符串插入ASN.1结构中。正在使用的哈希类型的对象标识符包含在结构中。当前定义的哈希算法的十六进制表示为：
- MD2: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x02
- MD2:0x2A、0x86、0x48、0x86、0xF7、0x0D、0x02、0x02
- MD5: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05
- MD5:0x2A、0x86、0x48、0x86、0xF7、0x0D、0x02、0x05
- RIPEMD-160: 0x2B, 0x24, 0x03, 0x02, 0x01
- RIPEMD-160:0x2B、0x24、0x03、0x02、0x01
- SHA-1: 0x2B, 0x0E, 0x03, 0x02, 0x1A
- SHA-1:0x2B、0x0E、0x03、0x02、0x1A
The ASN.1 OIDs are:
ASN.1 OID包括：
- MD2: 1.2.840.113549.2.2
- MD2:1.2.840.113549.2.2
- MD5: 1.2.840.113549.2.5
- MD5:1.2.840.113549.2.5
- RIPEMD-160: 1.3.36.3.2.1
- RIPEMD-160:1.3.36.3.2.1
- SHA-1: 1.3.14.3.2.26
- SHA-1:1.3.14.3.2.26
The full hash prefixes for these are:
这些文件的完整哈希前缀为：
MD2: 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x02, 0x05, 0x00, 0x04, 0x10
MD2:0x30、0x20、0x30、0x0C、0x06、0x08、0x2A、0x86、0x48、0x86、0xF7、0x0D、0x02、0x02、0x05、0x00、0x04、0x10
MD5: 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, 0x05, 0x00, 0x04, 0x10
MD5:0x30、0x20、0x30、0x0C、0x06、0x08、0x2A、0x86、0x48、0x86、0xF7、0x0D、0x02、0x05、0x05、0x00、0x04、0x10
RIPEMD-160: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x24, 0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14
RIPEMD-160:0x30、0x21、0x30、0x09、0x06、0x05、0x2B、0x24、0x03、0x02、0x01、0x05、0x00、0x04、0x14
SHA-1: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0E, 0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14
SHA-1:0x30、0x21、0x30、0x09、0x06、0x05、0x2b、0x0E、0x03、0x02、0x1A、0x05、0x00、0x04、0x14
DSA signatures MUST use hashes with a size of 160 bits, to match q, the size of the group generated by the DSA key's generator value. The hash function result is treated as a 160 bit number and used directly in the DSA signature algorithm.
DSA签名必须使用大小为160位的散列，以匹配由DSA密钥的生成器值生成的组大小q。哈希函数结果被视为160位数字，并直接用于DSA签名算法。
The body of a version 4 Signature Packet contains:
版本4签名包的正文包含：
- One-octet version number (4).
- 一个八位组版本号（4）。
- One-octet signature type.
- 一个八位组签名类型。
- One-octet public key algorithm.
- 一个八位组公钥算法。
- One-octet hash algorithm.
- 一个八位组哈希算法。
- Two-octet scalar octet count for following hashed subpacket 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. 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.
- 两个八位字节字段，保存有符号哈希值的左16位。
- 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 hashed. The resulting hash value is what is signed. The left 16 bits of the hash are included in the signature packet to provide a quick test to reject some invalid signatures.
对正在签名的数据进行散列，然后对版本号中的签名数据通过散列子包数据（包括）进行散列。得到的哈希值是有符号的。散列的左16位包含在签名包中，以提供拒绝某些无效签名的快速测试。
There are two fields consisting of signature subpackets. The first field is hashed with the rest of the signature data, while the second is unhashed. The second set of subpackets is not cryptographically protected by the signature and should include only advisory information.
有两个字段由签名子包组成。第一个字段与其余签名数据进行散列，而第二个字段不进行散列。第二组子包不受签名的加密保护，只应包括咨询信息。
The algorithms for converting the hash function result to a signature are described in a section below.
将哈希函数结果转换为签名的算法在下面的一节中描述。
The subpacket fields consist of zero or more signature subpackets. Each set of subpackets is preceded by a two-octet scalar count of the length of the set of subpackets.
子包字段由零个或多个签名子包组成。每组子包之前都有一个两个八位组的子包长度标量计数。
Each subpacket consists of a subpacket header and a body. The header consists of:
每个子包由一个子包头和一个子包体组成。标题包括：
- the subpacket length (1, 2, or 5 octets)
- 子包长度（1、2或5个八位字节）
- the subpacket type (1 octet)
- 子包类型（1个八位字节）
and is followed by the subpacket specific data.
然后是子包特定的数据。
The length includes the type octet but not this length. Its format is similar to the "new" format packet header lengths, but cannot have partial body lengths. That is:
长度包括八位字节类型，但不包括此长度。其格式类似于“新”格式的数据包头长度，但不能有部分正文长度。即:
if the 1st octet < 192, then lengthOfLength = 1 subpacketLen = 1st_octet
如果第一个八位组<192，则LengthFlength=1子包长度=第一个八位组
if the 1st octet >= 192 and < 255, then
lengthOfLength = 2
subpacketLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192
if the 1st octet >= 192 and < 255, then
lengthOfLength = 2
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]
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 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 22 = preferred compression algorithms 23 = key server preferences 24 = preferred key server 25 = primary user id 26 = policy URL 27 = key flags 28 = signer's user id 29 = reason for revocation 100 to 110 = internal or user-defined
2=签名创建时间3=签名过期时间4=可导出证书5=信任签名6=正则表达式7=可撤销9=密钥过期时间10=向后兼容性占位符11=首选对称算法12=撤销密钥16=颁发者密钥ID 20=表示法数据21=首选哈希算法22=首选压缩算法23=密钥服务器首选项24=首选密钥服务器25=主要用户id 26=策略URL 27=密钥标志28=签名者的用户id 29=撤销原因100到110=内部或用户定义
An implementation SHOULD ignore any subpacket of a type that it does not recognize.
实现应该忽略它无法识别的任何类型的子包。
Bit 7 of the subpacket type is the "critical" bit. If set, it denotes that the subpacket is one that is critical for the evaluator of the signature to recognize. If a subpacket is encountered that is marked critical but is unknown to the evaluating software, the evaluator SHOULD consider the signature to be in error.
子包类型的第7位为“关键”位。如果设置，则表示子包对于签名的计算器识别至关重要。如果遇到一个被标记为关键但对评估软件未知的子分组，则评估者应考虑签名错误。
An evaluator may "recognize" a subpacket, but not implement it. The purpose of the critical bit is to allow the signer to tell an evaluator that it would prefer a new, unknown feature to generate an error than be ignored.
评估者可以“识别”子包，但不能实现它。关键位的目的是允许签名者告诉评估者，它更希望一个新的未知特征生成错误，而不是被忽略。
Implementations SHOULD implement "preferences".
实现应该实现“首选项”。
A number of subpackets are currently defined. Some subpackets apply to the signature itself and some are attributes of the key. Subpackets that are found on a self-signature are placed on a user id certification made by the key itself. Note that a key may have more than one user id, and thus may have more than one self-signature, and differing subpackets.
目前定义了许多子包。有些子包应用于签名本身，有些是密钥的属性。在自签名上找到的子包放在由密钥本身生成的用户id证书上。请注意，密钥可能有多个用户id，因此可能有多个自签名和不同的子包。
A self-signature is a binding signature made by the key the signature refers to. There are three types of self-signatures, the certification signatures (types 0x10-0x13), the direct-key signature (type 0x1f), and the subkey binding signature (type 0x18). For certification self-signatures, each user ID may have a self-signature, and thus different subpackets in those self-signatures. For subkey binding signatures, each subkey in fact has a self-signature. Subpackets that appear in a certification self-signature apply to the username, and subpackets that appear in the subkey self-signature apply to the subkey. Lastly, subpackets on the direct key signature apply to the entire key.
自签名是由签名所指的密钥生成的具有约束力的签名。有三种类型的自签名：证书签名（类型0x10-0x13）、直接密钥签名（类型0x1f）和子密钥绑定签名（类型0x18）。对于认证自签名，每个用户ID可能有一个自签名，因此这些自签名中有不同的子包。对于子密钥绑定签名，每个子密钥实际上都有一个自签名。出现在证书自签名中的子包应用于用户名，出现在子密钥自签名中的子包应用于子密钥。最后，直接密钥签名上的子包应用于整个密钥。
Implementing software should interpret a self-signature's preference subpackets as narrowly as possible. For example, suppose a key has two usernames, Alice and Bob. Suppose that Alice prefers the symmetric algorithm CAST5, and Bob prefers IDEA or Triple-DES. If the software locates this key via Alice's name, then the preferred algorithm is CAST5, if software locates the key via Bob's name, then the preferred algorithm is IDEA. If the key is located by key id, then algorithm of the default user id of the key provides the default symmetric algorithm.
实现软件应该尽可能狭隘地解释自签名的偏好子包。例如，假设一个键有两个用户名，Alice和Bob。假设Alice更喜欢对称算法CAST5，Bob更喜欢IDEA或Triple DES。如果软件通过Alice的名字定位该密钥，则首选算法为CAST5，如果软件通过Bob的名字定位密钥，则首选算法为IDEA。如果密钥是通过密钥id定位的，则密钥的默认用户id的算法提供默认对称算法。
A subpacket may be found either in the hashed or unhashed subpacket sections of a signature. If a subpacket is not hashed, then the information in it cannot be considered definitive because it is not part of the signature proper.
可以在签名的哈希或未哈希子包部分中找到子包。如果子包没有散列，那么其中的信息就不能被认为是确定的，因为它不是签名本身的一部分。
(4 octet time field)
（4八位字节时间域）
The time the signature was made.
签字的时间。
MUST be present in the hashed area.
必须存在于散列区域中。
(8 octet key ID)
（8个八位组密钥ID）
The OpenPGP key ID of the key issuing the signature.
发出签名的密钥的OpenPGP密钥ID。
(4 octet time field)
（4八位字节时间域）
The validity period of the key. This is the number of seconds after the key creation time that the key expires. If this is not present or has a value of zero, the key never expires. This is found only on a self-signature.
密钥的有效期。这是密钥创建时间后密钥过期的秒数。如果该键不存在或值为零，则该键永远不会过期。这只能在自签名上找到。
(sequence of one-octet values)
（一个八位组值的序列）
Symmetric algorithm numbers that indicate which algorithms the key holder prefers to use. The subpacket body is an ordered list of octets with the most preferred listed first. It is assumed that only algorithms listed are supported by the recipient's software. Algorithm numbers in section 9. This is only found on a self-signature.
对称算法编号，指示密钥持有者更喜欢使用哪些算法。子包正文是一个有序的八位字节列表，最优先的列在前面。假定收件人的软件只支持列出的算法。第9节中的算法编号。这只能在自我签名上找到。
(array of one-octet values)
（一个八位组值的数组）
Message digest algorithm numbers that indicate which algorithms the key holder prefers to receive. Like the preferred symmetric algorithms, the list is ordered. Algorithm numbers are in section 6. This is only found on a self-signature.
消息摘要算法编号，指示密钥持有者希望接收的算法。与首选的对称算法一样，列表也是有序的。算法编号见第6节。这只能在自我签名上找到。
(array of one-octet values)
（一个八位组值的数组）
Compression algorithm numbers that indicate which algorithms the key holder prefers to use. Like the preferred symmetric algorithms, the list is ordered. Algorithm numbers are in section 6. If this subpacket is not included, ZIP is preferred. A zero denotes that uncompressed data is preferred; the key holder's software might have no compression software in that implementation. This is only found on a self-signature.
压缩算法编号，指示密钥持有者更喜欢使用哪些算法。与首选的对称算法一样，列表也是有序的。算法编号见第6节。如果不包括此子包，则首选ZIP。零表示首选未压缩的数据；密钥持有者的软件在该实现中可能没有压缩软件。这只能在自我签名上找到。
(4 octet time field)
（4八位字节时间域）
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.
签名的有效期。这是签名创建时间后签名过期的秒数。如果不存在或其值为零，则它永远不会过期。
(1 octet of exportability, 0 for not, 1 for exportable)
（1个可导出八位字节，0表示不可导出，1表示可导出）
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 equivalent to a flag containing a 1.
此子包表示认证签名是否“可导出”，供签名颁发者以外的其他用户使用。包体包含一个布尔标志，指示签名是否可导出。如果此数据包不存在，则证书可导出；它相当于包含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 prepares 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.
有些实现并不代表单个用户的兴趣（例如，密钥服务器）。这种实现总是从它们处理的任何密钥中删除本地证书。
(1 octet of revocability, 0 for not, 1 for revocable)
（1个可撤销八位字节，0表示不可撤销，1表示可撤销）
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, the signature is revocable.
签名的可撤销性状态。包体包含一个布尔标志，指示签名是否可撤销。不可撤销的签名会忽略任何以后的撤销签名。它们代表了签名人的承诺，即在其密钥的生命周期内，他不能撤销其签名。如果此数据包不存在，则签名是可撤销的。
(1 octet "level" (depth), 1 octet of trust amount)
（1个八位字节的“级别”（深度），1个八位字节的信任金额）
Signer asserts that the key is not only valid, but also trustworthy, at the specified level. Level 0 has the same meaning as an ordinary validity signature. Level 1 means that the signed key is asserted to be a valid trusted introducer, with the 2nd octet of the body specifying the degree of trust. Level 2 means that the signed key is asserted to be trusted to issue level 1 trust signatures, i.e. that it is a "meta introducer". Generally, a level n trust signature asserts that a key is trusted to issue level n-1 trust signatures. The trust amount is in a range from 0-255, interpreted such that values less than 120 indicate partial trust and values of 120 or greater indicate complete trust. Implementations SHOULD emit values of 60 for partial trust and 120 for complete trust.
签名者声明密钥在指定级别上不仅有效，而且可信。级别0与普通有效性签名具有相同的含义。级别1表示签名密钥被断言为有效的受信任介绍人，正文的第二个八位组指定信任度。级别2表示签名密钥被断言为可信的，以发布级别1信任签名，即它是“元介绍人”。通常，n级信任签名声明密钥被信任以发布n-1级信任签名。信任金额在0-255之间，解释为小于120表示部分信任，大于等于120表示完全信任。实现应该为部分信任发出60的值，为完全信任发出120的值。
(null-terminated regular expression)
（以null结尾的正则表达式）
Used in conjunction with trust signature packets (of level > 0) to limit the scope of trust that is extended. Only signatures by the target key on user IDs that match the regular expression in the body of this packet have trust extended by the trust signature subpacket. The regular expression uses the same syntax as the Henry Spencer's "almost public domain" regular expression package. A description of the syntax is found in a section below.
与信任签名包（级别>0）结合使用，以限制扩展的信任范围。只有与此数据包主体中的正则表达式匹配的用户ID上的目标密钥的签名才具有由信任签名子数据包扩展的信任。正则表达式使用与Henry Spencer的“几乎公共域”正则表达式包相同的语法。下面的一节介绍了语法。
(1 octet of class, 1 octet of algid, 20 octets of fingerprint)
（类的1个八位字节，阿尔吉德的1个八位字节，指纹的20个八位字节）
Authorizes the specified key to issue revocation signatures for this key. Class octet must have bit 0x80 set. If the bit 0x40 is set, then this means that the revocation information is sensitive. Other bits are for future expansion to other kinds of authorizations. This
授权指定的密钥为此密钥颁发吊销签名。类八位字节必须设置位0x80。如果设置了位0x40，则表示吊销信息是敏感的。其他位用于将来扩展到其他类型的授权。这
is found on a self-signature.
在自我签名上找到。
If the "sensitive" flag is set, the keyholder feels this subpacket contains private trust information that describes a real-world sensitive relationship. If this flag is set, implementations SHOULD NOT export this signature to other users except in cases where the data needs to be available: when the signature is being sent to the designated revoker, or when it is accompanied by a revocation signature from that revoker. Note that it may be appropriate to isolate this subpacket within a separate signature so that it is not combined with other subpackets that need to be exported.
如果设置了“敏感”标志，则密钥持有者认为此子包包含描述真实敏感关系的私人信任信息。如果设置了此标志，则实现不应将此签名导出给其他用户，除非数据需要可用：当签名被发送到指定的撤销机时，或者当签名附带来自该撤销机的撤销签名时。请注意，在单独的签名中隔离此子包可能是合适的，这样它就不会与需要导出的其他子包组合。
(4 octets of flags, 2 octets of name length (M), 2 octets of value length (N), M octets of name data, N octets of value data)
（4个八位字节的标志，2个八位字节的名称长度（M），2个八位字节的值长度（N），M个八位字节的名称数据，N个八位字节的值数据）
This subpacket describes a "notation" on the signature that the issuer wishes to make. The notation has a name and a value, each of which are strings of octets. There may be more than one notation in a signature. Notations can be used for any extension the issuer of the signature cares to make. The "flags" field holds four octets of flags.
本子包描述了发行人希望在签名上做的“标记”。符号有一个名称和一个值，每个值都是八位字节的字符串。签名中可能有多个符号。标记可用于签名发行人希望进行的任何扩展。“flags”字段包含四个八位字节的标志。
All undefined flags MUST be zero. Defined flags are:
所有未定义的标志必须为零。定义的标志包括：
First octet: 0x80 = human-readable. This note is text, a note from one person to another, and has no meaning to software. Other octets: none.
第一个八位组：0x80=人类可读。此注释是文本，是从一个人到另一个人的注释，对软件没有任何意义。其他八位字节：无。
(N octets of flags)
（N个八位组的旗帜）
This is a list of flags that indicate preferences that the key holder has about how the key is handled on a key server. All undefined flags MUST be zero.
这是一个标志列表，指示密钥持有者对密钥服务器上如何处理密钥的首选项。所有未定义的标志必须为零。
First octet: 0x80 = No-modify the key holder requests that this key only be modified or updated by the key holder or an administrator of the key server.
第一个八位组：0x80=否修改密钥持有者请求仅由密钥持有者或密钥服务器管理员修改或更新此密钥。
This is found only on a self-signature.
这只能在自签名上找到。
(String)
（字符串）
This is a URL of a key server that the key holder prefers be used for updates. Note that keys with multiple user ids can have a preferred key server for each user id. Note also that since this is a URL, the key server can actually be a copy of the key retrieved by ftp, http, finger, etc.
这是密钥持有者希望用于更新的密钥服务器的URL。请注意，具有多个用户id的密钥可以为每个用户id指定一个首选密钥服务器。还请注意，由于这是一个URL，密钥服务器实际上可以是ftp、http、finger等检索到的密钥的副本。
(1 octet, boolean)
（1个八位字节，布尔值）
This is a flag in a user id's self signature that states whether this user id is the main user id for this key. It is reasonable for an implementation to resolve ambiguities in preferences, etc. by referring to the primary user id. If this flag is absent, its value is zero. If more than one user id in a key is marked as primary, the implementation may resolve the ambiguity in any way it sees fit.
这是用户id自签名中的一个标志，用于说明此用户id是否是此密钥的主用户id。实现通过引用主用户id来解决首选项等中的歧义是合理的。如果没有此标志，则其值为零。如果一个密钥中有多个用户标识被标记为主用户标识，则实现可以以其认为合适的任何方式解决歧义。
(String)
（字符串）
This subpacket contains a URL of a document that describes the policy that the signature was issued under.
此子包包含一个文档的URL，该文档描述了在其下发布签名的策略。
(Octet string)
（八进制字符串）
This subpacket contains a list of binary flags that hold information about a key. It is a string of octets, and an implementation MUST NOT assume a fixed size. This is so it can grow over time. If a list is shorter than an implementation expects, the unstated flags are considered to be zero. The defined flags are:
此子包包含一个二进制标志列表，其中包含有关密钥的信息。它是一个八位字节字符串，实现不能采用固定大小。这是因为它可以随时间增长。如果列表比实现预期的短，则未声明的标志将被视为零。定义的标志是：
First octet:
第一个八位组：
0x01 - This key may be used to certify other keys.
0x01-此密钥可用于验证其他密钥。
0x02 - This key may be used to sign data.
0x02-此密钥可用于对数据进行签名。
0x04 - This key may be used to encrypt communications.
0x04-此密钥可用于加密通信。
0x08 - This key may be used to encrypt storage.
0x08-此密钥可用于加密存储。
0x10 - The private component of this key may have been split by a secret-sharing mechanism.
0x10-此密钥的私有组件可能已被秘密共享机制拆分。
0x80 - The private component of this key may be in the possession of more than one person.
0x80-此密钥的私有组件可能由多人拥有。
Usage notes:
使用说明：
The flags in this packet may appear in self-signatures or in certification signatures. They mean different things depending on who is making the statement -- for example, a certification signature that has the "sign data" flag is stating that the certification is for that use. On the other hand, the "communications encryption" flag in a self-signature is stating a preference that a given key be used for communications. Note however, that it is a thorny issue to determine what is "communications" and what is "storage." This decision is left wholly up to the implementation; the authors of this document do not claim any special wisdom on the issue, and realize that accepted opinion may change.
此数据包中的标志可能出现在自签名或认证签名中。它们的含义不同，这取决于谁在做声明——例如，带有“sign data”标志的认证签名表示该认证用于该用途。另一方面，自签名中的“通信加密”标志表示将给定密钥用于通信的偏好。但是请注意，确定什么是“通信”和什么是“存储”是一个棘手的问题；本文件的作者并不声称在这个问题上有任何特殊的智慧，并且意识到公认的观点可能会改变。
The "split key" (0x10) and "group key" (0x80) flags are placed on a self-signature only; they are meaningless on a certification signature. They SHOULD be placed only on a direct-key signature (type 0x1f) or a subkey signature (type 0x18), one that refers to the key the flag applies to.
“分割密钥”（0x10）和“组密钥”（0x80）标志仅放置在自签名上；它们在认证签名上没有意义。它们只能放在直接密钥签名（类型0x1f）或子密钥签名（类型0x18）上，该签名指的是该标志适用的密钥。
This subpacket allows a keyholder to state which user id is responsible for the signing. Many keyholders use a single key for different purposes, such as business communications as well as personal communications. This subpacket allows such a keyholder to state which of their roles is making a signature.
此子包允许密钥持有者声明哪个用户id负责签名。许多钥匙持有者将一把钥匙用于不同的目的，如商业通信和个人通信。此子包允许此类密钥持有者声明他们的哪个角色正在进行签名。
(1 octet of revocation code, N octets of reason string)
（撤销代码的1个八位字节，原因字符串的N个八位字节）
This subpacket is used only in key revocation and certification revocation signatures. It describes the reason why the key or certificate was revoked.
此子包仅用于密钥吊销和证书吊销签名。它描述了密钥或证书被吊销的原因。
The first octet contains a machine-readable code that denotes the reason for the revocation:
第一个八位组包含一个机器可读代码，表示撤销的原因：
0x00 - No reason specified (key revocations or cert revocations) 0x01 - Key is superceded (key revocations) 0x02 - Key material has been compromised (key revocations) 0x03 - Key is no longer used (key revocations) 0x20 - User id information is no longer valid (cert revocations)
0x00-未指定原因（密钥撤销或证书撤销）0x01-密钥被替换（密钥撤销）0x02-密钥材料已泄露（密钥撤销）0x03-密钥不再使用（密钥撤销）0x20-用户id信息不再有效（证书撤销）
Following the revocation code is a string of octets which gives information about the reason for revocation in human-readable form (UTF-8). The string may be null, that is, of zero length. The length of the subpacket is the length of the reason string plus one.
撤销代码后面是一串八位字节，以人类可读的形式（UTF-8）给出撤销原因的信息。字符串可以为null，即长度为零。子包的长度是原因字符串的长度加上一。
All signatures are formed by producing a hash over the signature data, and then using the resulting hash in the signature algorithm.
所有签名都是通过在签名数据上生成哈希，然后在签名算法中使用生成的哈希来形成的。
The signature data is simple to compute for document signatures (types 0x00 and 0x01), for which the document itself is the data. For standalone signatures, this is a null string.
对于文档签名（类型0x00和0x01），签名数据的计算非常简单，文档本身就是这些签名的数据。对于独立签名，这是一个空字符串。
When a signature is made over a key, the hash data starts with the octet 0x99, followed by a two-octet length of the key, and then body of the key packet. (Note that this is an old-style packet header for a key packet with two-octet length.) A subkey signature (type 0x18) then hashes the subkey, using the same format as the main key. Key revocation signatures (types 0x20 and 0x28) hash only the key being revoked.
当对密钥进行签名时，哈希数据以八位字节0x99开始，后跟密钥的两个八位字节长度，然后是密钥包的正文。（请注意，这是两个八位字节长度的密钥数据包的旧式数据包头。）然后，子密钥签名（类型0x18）使用与主键相同的格式对子密钥进行散列。密钥撤销签名（类型0x20和0x28）仅哈希正在撤销的密钥。
A certification signature (type 0x10 through 0x13) hashes the user id being bound to the key into the hash context after the above data. A V3 certification hashes the contents of the name packet, without any header. A V4 certification hashes the constant 0xb4 (which is an old-style packet header with the length-of-length set to zero), a four-octet number giving the length of the username, and then the username data.
证书签名（类型0x10到0x13）将绑定到密钥的用户id散列到上述数据之后的散列上下文中。V3认证散列名称数据包的内容，不带任何头。V4认证散列常量0xb4（这是一个旧式的数据包头，长度设置为零），一个四个八位组的数字给出用户名的长度，然后是用户名数据。
Once the data body is hashed, then a trailer is hashed. A V3 signature hashes five octets of the packet body, starting from the signature type field. This data is the signature type, followed by the four-octet signature time. A V4 signature hashes the packet body starting from its first field, the version number, through the end of the hashed subpacket data. Thus, the fields hashed are the signature version, the signature type, the public key algorithm, the hash algorithm, the hashed subpacket length, and the hashed subpacket body.
对数据体进行散列后，将对尾部进行散列。V3签名从签名类型字段开始，散列数据包正文的五个八位字节。此数据是签名类型，后跟四个八位数字签名时间。V4签名从数据包的第一个字段（版本号）开始，直到散列子数据包数据的末尾，对数据包体进行散列。因此，散列的字段是签名版本、签名类型、公钥算法、散列算法、散列子包长度和散列子包体。
V4 signatures also hash in a final trailer of six octets: the version of the signature packet, i.e. 0x04; 0xFF; a four-octet, big-endian number that is the length of the hashed data from the signature packet (note that this number does not include these final six octets.
V4签名还散列在六个八位组的最后一个预告片中：签名包的版本，即0x04；0xFF；一个四个八位字节的大端数字，它是来自签名包的散列数据的长度（注意，这个数字不包括最后六个八位字节）。
After all this has been hashed, the resulting hash field is used in the signature algorithm, and placed at the end of the signature packet.
对所有这些内容进行散列后，生成的散列字段将用于签名算法，并放置在签名数据包的末尾。
An implementation SHOULD put the two mandatory subpackets, creation time and issuer, as the first subpackets in the subpacket list, simply to make it easier for the implementer to find them.
一个实现应该将两个必需的子包，创建时间和发布者，作为子包列表中的第一个子包，只是为了让实现者更容易找到它们。
It is certainly possible for a signature to contain conflicting information in subpackets. For example, a signature may contain multiple copies of a preference or multiple expiration times. In most cases, an implementation SHOULD use the last subpacket in the signature, but MAY use any conflict resolution scheme that makes more sense. Please note that we are intentionally leaving conflict resolution to the implementer; most conflicts are simply syntax errors, and the wishy-washy language here allows a receiver to be generous in what they accept, while putting pressure on a creator to be stingy in what they generate.
签名在子包中当然可能包含冲突信息。例如，签名可能包含首选项的多个副本或多个过期时间。在大多数情况下，实现应该使用签名中的最后一个子包，但可以使用任何更有意义的冲突解决方案。请注意，我们有意将冲突解决留给实施者；大多数冲突仅仅是语法错误，这里的含糊不清的语言允许接收者在他们接受的东西上慷慨大方，同时给创造者施加压力，要求他们在他们产生的东西上吝啬。
Some apparent conflicts may actually make sense -- for example, suppose a keyholder has an V3 key and a V4 key that share the same RSA key material. Either of these keys can verify a signature created by the other, and it may be reasonable for a signature to contain an issuer subpacket for each key, as a way of explicitly tying those keys to the signature.
一些明显的冲突实际上可能是有意义的——例如，假设一个密钥持有者有一个V3密钥和一个V4密钥，它们共享相同的RSA密钥材料。这些密钥中的任何一个都可以验证由另一个密钥创建的签名，并且签名包含每个密钥的颁发者子包可能是合理的，作为将这些密钥显式绑定到签名的一种方式。
The Symmetric-Key Encrypted Session Key packet holds the symmetric-key encryption of a session key used to encrypt a message. Zero or more Encrypted Session Key packets and/or Symmetric-Key Encrypted Session Key packets may precede a Symmetrically Encrypted Data Packet that holds an encrypted message. The message is encrypted with a session key, and the session key is itself encrypted and stored in the Encrypted Session Key packet or the Symmetric-Key Encrypted Session Key packet.
对称密钥加密会话密钥包保存用于加密消息的会话密钥的对称密钥加密。零个或多个加密会话密钥分组和/或对称密钥加密会话密钥分组可以位于持有加密消息的对称加密数据分组之前。消息用会话密钥加密，会话密钥本身被加密并存储在加密会话密钥分组或对称密钥加密会话密钥分组中。
If the Symmetrically Encrypted Data Packet is preceded by one or more Symmetric-Key Encrypted Session Key packets, each specifies a passphrase that may be used to decrypt the message. This allows a
如果对称加密的数据包前面有一个或多个对称密钥加密的会话密钥包，则每个会话密钥包指定可用于解密消息的密码短语。这允许
message to be encrypted to a number of public keys, and also to one or more pass phrases. This packet type is new, and is not generated by PGP 2.x or PGP 5.0.
要加密到多个公钥的消息，以及一个或多个密码短语。此数据包类型是新的，不是由PGP2.x或PGP5.0生成的。
The body of this packet consists of:
本文件包正文包括：
- A one-octet version number. The only currently defined version is 4.
- 一个八位字节的版本号。当前唯一定义的版本是4。
- A one-octet number describing the symmetric algorithm used.
- 描述所用对称算法的一个八位组数。
- A string-to-key (S2K) specifier, length as defined above.
- 字符串到键（S2K）说明符，长度如上所述。
- Optionally, the encrypted session key itself, which is decrypted with the string-to-key object.
- （可选）加密的会话密钥本身，使用字符串到密钥对象进行解密。
If the encrypted session key is not present (which can be detected on the basis of packet length and S2K specifier size), then the S2K algorithm applied to the passphrase produces the session key for decrypting the file, using the symmetric cipher algorithm from the Symmetric-Key Encrypted Session Key packet.
如果加密的会话密钥不存在（可根据分组长度和S2K说明符大小检测），则应用于密码短语的S2K算法使用对称密钥加密的会话密钥分组中的对称密码算法生成用于解密文件的会话密钥。
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.
如果存在加密会话密钥，则将S2K算法应用于密码短语的结果用于仅解密该加密会话密钥字段，使用带有IV全零的CFB模式。解密结果由一个八位组算法标识符组成，该标识符指定用于加密以下对称加密数据包的对称密钥加密算法，然后是会话密钥八位组本身。
Note: because an all-zero IV is used for this decryption, the S2K 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.
注意：由于此解密使用全零IV，S2K说明符必须使用salt值，salt S2K或迭代salt S2K。salt值将确保即使重新使用密码短语，解密密钥也不会重复。
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.
一次性签名不能与PGP 2.6.x或更早版本互操作。
The body of this packet consists of:
本文件包正文包括：
- A one-octet version number. The current version is 3.
- 一个八位字节的版本号。目前的版本是3。
- A one-octet signature type. Signature types are described in section 5.2.1.
- 一个八位组签名类型。第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.
- 保存签名密钥的密钥ID的八个八位组的数字。
- 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 signature to be applied to the same message data.
- 一个八位组的数字，带有一个标志，显示签名是否嵌套。零值表示下一个数据包是另一个单通道签名数据包，该数据包描述了应用于同一消息数据的另一个签名。
Note that if a message contains more than one one-pass signature, then the signature packets bracket the message; that is, the first signature packet after the message corresponds to the last one-pass packet and the final signature packet corresponds to the first one-pass packet.
请注意，如果一条消息包含多个一次性签名，那么签名包将包含该消息；即，消息之后的第一签名分组对应于最后一个一次通过分组，并且最终签名分组对应于第一个一次通过分组。
A key material packet contains all the information about a public or private key. There are four variants of this packet type, and two major versions. Consequently, this section is complex.
密钥材料包包含关于公钥或私钥的所有信息。此数据包类型有四种变体和两个主要版本。因此，这一部分很复杂。
A Public Key packet starts a series of packets that forms an OpenPGP key (sometimes called an OpenPGP certificate).
公钥数据包启动一系列数据包，形成OpenPGP密钥（有时称为OpenPGP证书）。
A Public Subkey packet (tag 14) has exactly the same format as a Public Key packet, but denotes a subkey. One or more subkeys may be associated with a top-level key. By convention, the top-level key provides signature services, and the subkeys provide encryption services.
公钥分组（标签14）具有与公钥分组完全相同的格式，但表示子密钥。一个或多个子键可能与顶级键关联。按照惯例，顶级密钥提供签名服务，子密钥提供加密服务。
Note: in PGP 2.6.x, tag 14 was intended to indicate a comment packet. This tag was selected for reuse because no previous version of PGP ever emitted comment packets but they did properly ignore them. Public Subkey packets are ignored by PGP 2.6.x and do not cause it to fail, providing a limited degree of backward compatibility.
注：在PGP2.6.x中，标记14用于表示注释包。选择此标记以供重用，因为以前版本的PGP从未发出注释数据包，但它们确实正确地忽略了它们。PGP2.6.x会忽略公钥数据包，不会导致其失败，从而提供有限程度的向后兼容性。
A Secret Key packet contains all the information that is found in a Public Key packet, including the public key material, but also includes the secret key material after all the public key fields.
密钥包包含在公钥包中找到的所有信息，包括公钥材料，但也包括在所有公钥字段之后的密钥材料。
A Secret Subkey packet (tag 7) is the subkey analog of the Secret Key packet, and has exactly the same format.
秘密子密钥分组（标签7）是秘密密钥分组的子密钥模拟，并且具有完全相同的格式。
There are two versions of key-material packets. Version 3 packets were first generated by PGP 2.6. Version 2 packets are identical in format to Version 3 packets, but are generated by PGP 2.5 or before. V2 packets are deprecated and they MUST NOT be generated. PGP 5.0 introduced version 4 packets, with new fields and semantics. PGP 2.6.x will not accept key-material packets with versions greater than 3.
关键材料包有两个版本。版本3数据包首先由PGP2.6生成。版本2数据包的格式与版本3数据包相同，但由PGP 2.5或更早版本生成。V2数据包已弃用，不得生成。PGP5.0引入了具有新字段和语义的版本4数据包。PGP 2.6.x不接受版本大于3的关键材料包。
OpenPGP implementations SHOULD create keys with version 4 format. An implementation MAY generate a V3 key to ensure interoperability with old software; note, however, that V4 keys correct some security deficiencies in V3 keys. These deficiencies are described below. An implementation MUST NOT create a V3 key with a public key algorithm other than RSA.
OpenPGP实现应该使用版本4格式创建密钥。实现可以生成V3密钥，以确保与旧软件的互操作性；但是，请注意，V4密钥纠正了V3密钥中的一些安全缺陷。这些缺陷描述如下。实现不能使用RSA以外的公钥算法创建V3密钥。
A version 3 public key or public subkey packet contains:
版本3公钥或公钥子密钥包包含：
- A one-octet version number (3).
- 一个八位组版本号（3）。
- A four-octet number denoting the time that the key was created.
- 表示密钥创建时间的四个八位组数字。
- A two-octet number denoting the time in days that this key is valid. If this number is zero, then it does not expire.
- 两个八位组的数字，表示此密钥有效的时间（以天为单位）。如果此数字为零，则不会过期。
- A one-octet number denoting the public key algorithm of this key
- 表示该密钥的公钥算法的一个八位组数
- A series of multi-precision integers comprising the key material:
- 包含关键材料的一系列多精度整数：
- a multiprecision integer (MPI) of RSA public modulus n;
- RSA公共模n的多精度整数（MPI）；
- an MPI of RSA public encryption exponent e.
- RSA公共加密指数e的MPI。
V3 keys SHOULD only be used for backward compatibility because of three weaknesses in them. First, it is relatively easy to construct a V3 key that has the same key ID as any other key because the key ID is simply the low 64 bits of the public modulus. Secondly, because the fingerprint of a V3 key hashes the key material, but not its length, which increases the opportunity for fingerprint collisions. Third, there are minor weaknesses in the MD5 hash algorithm that make developers prefer other algorithms. See below for a fuller discussion of key IDs and fingerprints.
V3密钥应该只用于向后兼容性，因为它们有三个弱点。首先，构造与任何其他密钥具有相同密钥ID的V3密钥相对容易，因为密钥ID只是公共模的低64位。第二，因为V3密钥的指纹会散列密钥材料，而不是其长度，这增加了指纹冲突的机会。第三，MD5哈希算法有一些小缺点，这使得开发人员更喜欢其他算法。有关密钥ID和指纹的详细讨论，请参见下文。
The version 4 format is similar to the version 3 format except for the absence of a validity period. This has been moved to the signature packet. In addition, fingerprints of version 4 keys are calculated differently from version 3 keys, as described in section "Enhanced Key Formats."
版本4格式与版本3格式类似，只是没有有效期。这已移动到签名包。此外，第4版密钥的指纹计算与第3版密钥不同，如“增强密钥格式”一节所述
A version 4 packet contains:
版本4数据包包含：
- A one-octet version number (4).
- 一个八位组版本号（4）。
- A four-octet number denoting the time that the key was created.
- 表示密钥创建时间的四个八位组数字。
- A one-octet number denoting the public key algorithm of this key
- 表示该密钥的公钥算法的一个八位组数
- A series of multi-precision integers comprising the key material. This algorithm-specific portion is:
- 包含关键材料的一系列多精度整数。该算法的特定部分是：
Algorithm Specific Fields for RSA public keys:
RSA公钥的算法特定字段：
- multiprecision integer (MPI) of RSA public modulus n;
- RSA公共模n的多精度整数（MPI）；
- MPI of RSA public encryption exponent e.
- RSA公共加密指数e的MPI。
Algorithm Specific Fields for DSA public keys:
DSA公钥的算法特定字段：
- MPI of DSA prime p;
- DSA素数p的MPI；
- MPI of DSA group order q (q is a prime divisor of p-1);
- DSA组阶q的MPI（q是p-1的素因子）；
- MPI of DSA group generator g;
- DSA组生成器g的MPI；
- MPI of DSA public key value y (= g**x where x is secret).
- DSA公钥值y的MPI（=g**x，其中x为机密）。
Algorithm Specific Fields for Elgamal public keys:
Elgamal公钥的算法特定字段：
- MPI of Elgamal prime p;
- Elgamal素数p的MPI；
- MPI of Elgamal group generator g;
- Elgamal群生成器g的MPI；
- MPI of Elgamal public key value y (= g**x where x is secret).
- Elgamal公钥值y的MPI（=g**x，其中x为机密）。
The Secret Key and Secret Subkey packets contain all the data of the Public Key and Public Subkey packets, with additional algorithm-specific secret key data appended, in encrypted form.
秘密密钥和秘密子密钥包包含公开密钥和公开子密钥包的所有数据，并以加密形式附加额外的特定于算法的秘密密钥数据。
The packet contains:
数据包包含：
- A Public Key or Public Subkey packet, as described above
- 公开密钥或公开子密钥包，如上所述
- One octet indicating string-to-key usage conventions. 0 indicates that the secret key data is not encrypted. 255 indicates that a string-to-key specifier is being given. Any other value is a symmetric-key encryption algorithm specifier.
- 一个八位字节，表示字符串到键的使用约定。0表示密钥数据未加密。255表示正在为键说明符指定字符串。任何其他值都是对称密钥加密算法说明符。
- [Optional] If string-to-key usage octet was 255, a one-octet symmetric encryption algorithm.
- [可选]如果字符串到密钥的使用八位字节为255，则使用一个八位字节的对称加密算法。
- [Optional] If string-to-key usage octet was 255, a string-to-key specifier. The length of the string-to-key specifier is implied by its type, as described above.
- [可选]如果字符串到键的使用八位字节为255，则为字符串到键说明符。字符串到键说明符的长度由其类型暗示，如上所述。
- [Optional] If secret data is encrypted, eight-octet Initial Vector (IV).
- [可选]如果加密了机密数据，则为八个八位字节的初始向量（IV）。
- Encrypted multi-precision integers comprising the secret key data. These algorithm-specific fields are as described below.
- 包含密钥数据的加密多精度整数。这些特定于算法的字段如下所述。
- Two-octet checksum of the plaintext of the algorithm-specific portion (sum of all octets, mod 65536).
- 算法特定部分的明文的两个八位校验和（所有八位校验和，mod 65536）。
Algorithm Specific Fields for RSA secret keys:
RSA密钥的算法特定字段：
- multiprecision integer (MPI) of RSA secret exponent d.
- RSA秘密指数d的多精度整数（MPI）。
- MPI of RSA secret prime value p.
- RSA秘密素数p的MPI。
- MPI of RSA secret prime value q (p < q).
- RSA秘密素数值q的MPI（p<q）。
- MPI of u, the multiplicative inverse of p, mod q.
- u的MPI，p的乘法逆，mod q。
Algorithm Specific Fields for DSA secret keys:
DSA密钥的算法特定字段：
- MPI of DSA secret exponent x.
- DSA秘密指数x的MPI。
Algorithm Specific Fields for Elgamal secret keys:
Elgamal密钥的算法特定字段：
- MPI of Elgamal secret exponent x.
- Elgamal秘密指数x的MPI。
Secret MPI values can be encrypted using a passphrase. If a string-to-key specifier is given, that describes the algorithm for converting the passphrase to a key, else a simple MD5 hash of the passphrase is used. Implementations SHOULD use a string-to-key specifier; the simple hash is for backward compatibility. The cipher for encrypting the MPIs is specified in the secret key packet.
可以使用密码短语对机密MPI值进行加密。如果给定了一个字符串到密钥说明符，该说明符描述了将密码短语转换为密钥的算法，否则将使用密码短语的简单MD5哈希。实现应该使用字符串作为键说明符；简单散列用于向后兼容。加密MPI的密码在密钥包中指定。
Encryption/decryption of the secret data is done in CFB mode using the key created from the passphrase and the Initial Vector from the packet. A different mode is used with V3 keys (which are only RSA) than with other key formats. With V3 keys, the MPI bit count prefix (i.e., the first two octets) is not encrypted. Only the MPI non-prefix data is encrypted. Furthermore, the CFB state is resynchronized at the beginning of each new MPI value, so that the CFB block boundary is aligned with the start of the MPI data.
机密数据的加密/解密在CFB模式下完成，使用从密码短语创建的密钥和来自数据包的初始向量。V3密钥（仅为RSA）使用的模式与其他密钥格式不同。对于V3密钥，MPI位计数前缀（即前两个八位字节）不加密。仅对MPI非前缀数据进行加密。此外，CFB状态在每个新MPI值的开始处重新同步，以便CFB块边界与MPI数据的开始处对齐。
With V4 keys, a simpler method is used. All secret MPI values are encrypted in CFB mode, including the MPI bitcount prefix.
对于V4键，使用了一种更简单的方法。所有机密MPI值都在CFB模式下加密，包括MPI位计数前缀。
The 16-bit checksum that follows the algorithm-specific portion is the algebraic sum, mod 65536, of the plaintext of all the algorithm-specific octets (including MPI prefix and data). With V3 keys, the checksum is stored in the clear. With V4 keys, the checksum is encrypted like the algorithm-specific data. This value is used to check that the passphrase was correct.
算法特定部分后面的16位校验和是所有算法特定八位字节（包括MPI前缀和数据）的明文的代数和mod 65536。对于V3键，校验和存储在clear中。对于V4密钥，校验和与特定算法的数据一样进行加密。此值用于检查密码短语是否正确。
The Compressed Data packet contains compressed data. Typically, this packet is found as the contents of an encrypted packet, or following a Signature or One-Pass Signature packet, and contains literal data packets.
压缩数据包包含压缩数据。通常，此数据包被发现为加密数据包的内容，或在签名或单次签名数据包之后，并包含文字数据包。
The body of this packet consists of:
本文件包正文包括：
- One octet that gives the algorithm used to compress the packet.
- 一个八位组，给出用于压缩数据包的算法。
- The remainder of the packet is compressed data.
- 数据包的其余部分是压缩数据。
A Compressed Data Packet's body contains an block that compresses some set of packets. See section "Packet Composition" for details on how messages are formed.
压缩数据包的主体包含一个块，该块压缩一组数据包。有关如何形成消息的详细信息，请参见“数据包组成”一节。
ZIP-compressed packets are compressed with raw RFC 1951 DEFLATE blocks. Note that PGP V2.6 uses 13 bits of compression. If an implementation uses more bits of compression, PGP V2.6 cannot decompress it.
ZIP压缩包使用原始RFC 1951 DEFLATE块进行压缩。请注意，PGPv2.6使用13位压缩。如果一个实现使用了更多的压缩位，PGP V2.6将无法对其进行解压缩。
ZLIB-compressed packets are compressed with RFC 1950 ZLIB-style blocks.
ZLIB压缩包使用RFC1950 ZLIB样式块进行压缩。
The Symmetrically Encrypted Data packet contains data encrypted with a symmetric-key algorithm. When it has been decrypted, it will typically contain other packets (often literal data packets or compressed data packets).
对称加密的数据包包含使用对称密钥算法加密的数据。解密后，它通常会包含其他数据包（通常是文字数据包或压缩数据包）。
The body of this packet consists of:
本文件包正文包括：
- Encrypted data, the output of the selected symmetric-key cipher operating in PGP's variant of Cipher Feedback (CFB) mode.
- 加密数据，在PGP的密码反馈变体（CFB）模式下运行的选定对称密钥密码的输出。
The symmetric cipher used may be specified in an Public-Key or Symmetric-Key Encrypted Session Key packet that precedes the Symmetrically Encrypted Data Packet. In that case, the cipher algorithm octet is prefixed to the session key before it is encrypted. If no packets of these types precede the encrypted data, the IDEA algorithm is used with the session key calculated as the MD5 hash of the passphrase.
可以在对称加密的数据分组之前的公钥或对称密钥加密的会话密钥分组中指定所使用的对称密码。在这种情况下，加密算法octet在会话密钥加密之前被加上前缀。如果加密数据之前没有这些类型的数据包，则使用IDEA算法将会话密钥计算为密码短语的MD5散列。
The data is encrypted in CFB mode, with a CFB shift size equal to the cipher's block size. The Initial Vector (IV) is specified as all zeros. Instead of using an IV, OpenPGP prefixes a 10-octet string to the data before it is encrypted. The first eight octets are random, and the 9th and 10th octets are copies of the 7th and 8th octets, respectively. After encrypting the first 10 octets, the CFB state is resynchronized if the cipher block size is 8 octets or less. The last 8 octets of ciphertext are passed through the cipher and the block boundary is reset.
数据在CFB模式下加密，CFB移位大小等于密码的块大小。初始向量（IV）指定为全零。OpenPGP没有使用IV，而是在数据加密之前在其前面加上10个八位字节的字符串。前八个八位元是随机的，第九个和第十个八位元分别是第七个和第八个八位元的副本。加密前10个八位字节后，如果密码块大小小于等于8个八位字节，则CFB状态将重新同步。密文的最后8个八位字节通过密码，并重置块边界。
The repetition of 16 bits in the 80 bits of random data prefixed to the message allows the receiver to immediately check whether the session key is incorrect.
在消息前缀的80位随机数据中重复16位允许接收器立即检查会话密钥是否不正确。
An experimental version of PGP used this packet as the Literal packet, but no released version of PGP generated Literal packets with this tag. With PGP 5.x, this packet has been re-assigned and is reserved for use as the Marker packet.
PGP的一个实验版本使用此数据包作为文本数据包，但没有发布版本的PGP生成带有此标记的文本数据包。对于PGP5.x，此数据包已被重新分配，并保留用作标记数据包。
The body of this packet consists of:
本文件包正文包括：
- The three octets 0x50, 0x47, 0x50 (which spell "PGP" in UTF-8).
- 三个八位字节0x50、0x47、0x50（在UTF-8中拼写为“PGP”）。
Such a packet MUST be ignored when received. It may be placed at the beginning of a message that uses features not available in PGP 2.6.x in order to cause that version to report that newer software is necessary to process the message.
接收到这样的数据包时必须忽略。它可以放在使用PGP 2.6.x中不可用功能的消息的开头，以使该版本报告需要更新的软件来处理该消息。
A Literal Data packet contains the body of a message; data that is not to be further interpreted.
文字数据包包含消息体；不需要进一步解释的数据。
The body of this packet consists of:
本文件包正文包括：
- A one-octet field that describes how the data is formatted.
- 描述数据格式化方式的一个八位字节字段。
If it is a 'b' (0x62), then the literal packet contains binary data. If it is a 't' (0x74), then it contains text data, and thus may need line ends converted to local form, or other text-mode changes. RFC 1991 also defined a value of 'l' as a 'local' mode for machine-local conversions. This use is now deprecated.
如果是“b”（0x62），则文字数据包包含二进制数据。如果是“t”（0x74），则它包含文本数据，因此可能需要将行尾转换为本地形式，或更改其他文本模式。RFC 1991还将“l”值定义为机器本地转换的“本地”模式。这种用法现在已被弃用。
- File name as a string (one-octet length, followed by file name), if the encrypted data should be saved as a file.
- 如果加密数据应保存为文件，则文件名为字符串（一个八位字节长度，后跟文件名）。
If the special name "_CONSOLE" is used, the message is considered to be "for your eyes only". This advises that the message data is unusually sensitive, and the receiving program should process it more carefully, perhaps avoiding storing the received data to disk, for example.
如果使用了特殊名称“_CONSOLE”，则消息将被视为“仅供您观看”。这表明消息数据异常敏感，接收程序应该更仔细地处理它，例如，可能避免将接收到的数据存储到磁盘。
- A four-octet number that indicates the modification date of the file, or the creation time of the packet, or a zero that indicates the present time.
- 表示文件修改日期或数据包创建时间的四个八位组数字，或表示当前时间的零。
- The remainder of the packet is literal data.
- 数据包的其余部分是文字数据。
Text data is stored with <CR><LF> text endings (i.e. network-normal line endings). These should be converted to native line endings by the receiving software.
文本数据以<CR><LF>文本结尾（即网络正常行结尾）存储。接收软件应将其转换为本机行结尾。
The Trust packet is used only within keyrings and is not normally exported. Trust packets contain data that record the user's specifications of which key holders are trustworthy introducers,
信任数据包仅在密钥环内使用，通常不会导出。信任数据包包含记录用户规格的数据，其中密钥持有者是值得信赖的介绍人，
along with other information that implementing software uses for trust information.
以及实现软件用于信任信息的其他信息。
Trust packets SHOULD NOT be emitted to output streams that are transferred to other users, and they SHOULD be ignored on any input other than local keyring files.
不应将信任数据包发送到传输给其他用户的输出流，并且应忽略本地密钥环文件以外的任何输入。
A User ID packet consists of data that is intended to represent the name and email address of the key holder. By convention, it includes an RFC 822 mail name, but there are no restrictions on its content. The packet length in the header specifies the length of the user id. If it is text, it is encoded in UTF-8.
用户ID数据包由用于表示密钥持有者的姓名和电子邮件地址的数据组成。按照惯例，它包括一个RFC 822邮件名，但对其内容没有限制。报头中的数据包长度指定用户id的长度。如果是文本，则以UTF-8编码。
As stated in the introduction, OpenPGP's underlying native representation for objects is a stream of arbitrary octets, and some systems desire these objects to be immune to damage caused by character set translation, data conversions, etc.
如引言中所述，OpenPGP对象的底层本机表示是任意八位字节流，一些系统希望这些对象不受字符集转换、数据转换等造成的损害。
In principle, any printable encoding scheme that met the requirements of the unsafe channel would suffice, since it would not change the underlying binary bit streams of the native OpenPGP data structures. The OpenPGP standard specifies one such printable encoding scheme to ensure interoperability.
原则上，任何满足不安全通道要求的可打印编码方案都已足够，因为它不会改变本机OpenPGP数据结构的底层二进制位流。OpenPGP标准指定了一种这样的可打印编码方案，以确保互操作性。
OpenPGP's Radix-64 encoding is composed of two parts: a base64 encoding of the binary data, and a checksum. The base64 encoding is identical to the MIME base64 content-transfer-encoding [RFC2231, Section 6.8]. An OpenPGP implementation MAY use ASCII Armor to protect the raw binary data.
OpenPGP的基数64编码由两部分组成：二进制数据的base64编码和校验和。base64编码与MIME base64内容传输编码相同[RFC2231，第6.8节]。OpenPGP实现可以使用ASCII保护来保护原始二进制数据。
The checksum is a 24-bit CRC converted to four characters of radix-64 encoding by the same MIME base64 transformation, preceded by an equals sign (=). The CRC is computed by using the generator 0x864CFB and an initialization of 0xB704CE. The accumulation is done on the data before it is converted to radix-64, rather than on the converted data. A sample implementation of this algorithm is in the next section.
校验和是一个24位CRC，通过相同的MIME base64转换转换为四个基数64编码字符，前面加一个等号（=）。CRC通过使用生成器0x864CFB和0xB704CE初始化来计算。在将数据转换为基数64之前，对数据进行累加，而不是对转换后的数据进行累加。下一节将介绍该算法的示例实现。
The checksum with its leading equal sign MAY appear on the first line after the Base64 encoded data.
带前导等号的校验和可能出现在Base64编码数据后的第一行。
Rationale for CRC-24: The size of 24 bits fits evenly into printable base64. The nonzero initialization can detect more errors than a zero initialization.
CRC-24的基本原理：24位的大小均匀地适合可打印的base64。非零初始化可以检测到比零初始化更多的错误。
#define CRC24_INIT 0xb704ceL #define CRC24_POLY 0x1864cfbL
#定义CRC24_INIT 0xb704ceL#定义CRC24_POLY 0x1864cfbL
typedef long crc24;
crc24 crc_octets(unsigned char *octets, size_t len)
{
crc24 crc = CRC24_INIT;
int i;
typedef long crc24;
crc24 crc_octets(unsigned char *octets, size_t len)
{
crc24 crc = CRC24_INIT;
int i;
while (len--) {
crc ^= (*octets++) << 16;
for (i = 0; i < 8; i++) {
crc <<= 1;
if (crc & 0x1000000)
crc ^= CRC24_POLY;
}
}
return crc & 0xffffffL;
}
while (len--) {
crc ^= (*octets++) << 16;
for (i = 0; i < 8; i++) {
crc <<= 1;
if (crc & 0x1000000)
crc ^= CRC24_POLY;
}
}
return crc & 0xffffffL;
}
When OpenPGP encodes data into ASCII Armor, it puts specific headers around the data, so OpenPGP can reconstruct the data later. OpenPGP informs the user what kind of data is encoded in the ASCII armor through the use of the headers.
当OpenPGP将数据编码为ASCII格式时，它会在数据周围放置特定的头，以便OpenPGP以后可以重构数据。OpenPGP通过使用头通知用户ASCII格式中编码的数据类型。
Concatenating the following data creates ASCII Armor:
连接以下数据将创建ASCII铠装：
- An Armor Header Line, appropriate for the type of data
- 适合于数据类型的标题行
- Armor Headers
- 装甲头
- A blank (zero-length, or containing only whitespace) line
- 空白行（长度为零，或仅包含空格）
- The ASCII-Armored data
- ASCII铠装数据
- An Armor Checksum
- 护甲校验和
- The Armor Tail, which depends on the Armor Header Line.
- 装甲尾部，取决于装甲头线。
An Armor Header Line consists of the appropriate header line text surrounded by five (5) dashes ('-', 0x2D) on either side of the header line text. The header line text is chosen based upon the type of data that is being encoded in Armor, and how it is being encoded. Header line texts include the following strings:
Armor标题行由相应的标题行文本组成，标题行文本两侧有五（5）个短划线（“-”，0x2D）环绕。标题行文本是根据Armor中编码的数据类型以及编码方式选择的。标题行文本包括以下字符串：
BEGIN PGP MESSAGE Used for signed, encrypted, or compressed files.
用于签名、加密或压缩文件的BEGIN PGP消息。
BEGIN PGP PUBLIC KEY BLOCK Used for armoring public keys
开始用于铠装公钥的PGP公钥块
BEGIN PGP PRIVATE KEY BLOCK Used for armoring private keys
BEGIN PGP私钥块用于私钥铠装
BEGIN PGP MESSAGE, PART X/Y Used for multi-part messages, where the armor is split amongst Y parts, and this is the Xth part out of Y.
开始PGP消息，用于多部分消息的X/Y部分，装甲在Y部分之间分割，这是Y中的第X部分。
BEGIN PGP MESSAGE, PART X Used for multi-part messages, where this is the Xth part of an unspecified number of parts. Requires the MESSAGE-ID Armor Header to be used.
BEGIN PGP MESSAGE，用于多部分消息的第X部分，其中这是未指定数量部分的第X部分。需要使用MESSAGE-ID Armor标头。
BEGIN PGP SIGNATURE Used for detached signatures, OpenPGP/MIME signatures, and natures following clearsigned messages. Note that PGP 2.x s BEGIN PGP MESSAGE for detached signatures.
BEGIN PGP SIGNATURE用于分离签名、OpenPGP/MIME签名和clearsigned消息后的性质。请注意，对于分离的签名，PGP2.x s开始PGP消息。
The Armor Headers are pairs of strings that can give the user or the receiving OpenPGP implementation some information about how to decode or use the message. The Armor Headers are a part of the armor, not a part of the message, and hence are not protected by any signatures applied to the message.
Armor头是一对字符串，可以为用户或接收OpenPGP实现提供有关如何解码或使用消息的一些信息。装甲头是装甲的一部分，而不是消息的一部分，因此不受应用于消息的任何签名的保护。
The format of an Armor Header is that of a key-value pair. A colon (':' 0x38) and a single space (0x20) separate the key and value. OpenPGP should consider improperly formatted Armor Headers to be corruption of the ASCII Armor. Unknown keys should be reported to the user, but OpenPGP should continue to process the message.
Armor头的格式是键值对的格式。冒号（“：”0x38）和单个空格（0x20）分隔键和值。OpenPGP应考虑不正确格式化的装甲标头是ASCII装甲的破坏。未知密钥应报告给用户，但OpenPGP应继续处理该消息。
Currently defined Armor Header Keys are:
当前定义的标题键为：
- "Version", that states the OpenPGP Version used to encode the message.
- “版本”，表示用于编码消息的OpenPGP版本。
- "Comment", a user-defined comment.
- “注释”，用户定义的注释。
- "MessageID", a 32-character string of printable characters. The string must be the same for all parts of a multi-part message that uses the "PART X" Armor Header. MessageID strings should be
- “MessageID”，一个32个字符的可打印字符字符串。对于使用“part X”标题的多部分消息的所有部分，字符串必须相同。MessageID字符串应为
unique enough that the recipient of the mail can associate all the parts of a message with each other. A good checksum or cryptographic hash function is sufficient.
具有足够的唯一性，邮件收件人可以将邮件的所有部分相互关联。一个好的校验和或加密哈希函数就足够了。
- "Hash", a comma-separated list of hash algorithms used in this message. This is used only in clear-signed messages.
- “Hash”，此消息中使用的哈希算法的逗号分隔列表。这仅用于清除签名的消息。
- "Charset", a description of the character set that the plaintext is in. Please note that OpenPGP defines text to be in UTF-8 by default. An implementation will get best results by translating into and out of UTF-8. However, there are many instances where this is easier said than done. Also, there are communities of users who have no need for UTF-8 because they are all happy with a character set like ISO Latin-5 or a Japanese character set. In such instances, an implementation MAY override the UTF-8 default by using this header key. An implementation MAY implement this key and any translations it cares to; an implementation MAY ignore it and assume all text is UTF-8.
- “字符集”，对明文所在字符集的描述。请注意，OpenPGP默认将文本定义为UTF-8格式。通过将UTF-8转换成UTF-8，实现将获得最佳结果。然而，在许多情况下，这说起来容易做起来难。此外，还有一些用户社区不需要UTF-8，因为他们都喜欢ISO拉丁语-5或日语字符集这样的字符集。在这种情况下，实现可以通过使用此头密钥覆盖UTF-8默认值。一个实现可以实现这个密钥和它关心的任何翻译；实现可能会忽略它，并假定所有文本都是UTF-8。
The MessageID SHOULD NOT appear unless it is in a multi-part message. If it appears at all, it MUST be computed from the finished (encrypted, signed, etc.) message in a deterministic fashion, rather than contain a purely random value. This is to allow the legitimate recipient to determine that the MessageID cannot serve as a covert means of leaking cryptographic key information.
MessageID不应出现，除非它位于多部分消息中。如果它出现了，则必须以确定的方式从完成的（加密、签名等）消息中计算出来，而不是包含一个纯粹的随机值。这是为了允许合法收件人确定MessageID不能作为泄露加密密钥信息的隐蔽手段。
The Armor Tail Line is composed in the same manner as the Armor Header Line, except the string "BEGIN" is replaced by the string "END."
装甲尾线的组成方式与装甲头线相同，只是字符串“BEGIN”替换为字符串“END”
The encoding process represents 24-bit groups of input bits as output strings of 4 encoded characters. Proceeding from left to right, a 24-bit input group is formed by concatenating three 8-bit input groups. These 24 bits are then treated as four concatenated 6-bit groups, each of which is translated into a single digit in the Radix-64 alphabet. When encoding a bit stream with the Radix-64 encoding, the bit stream must be presumed to be ordered with the most-significant-bit first. That is, the first bit in the stream will be the high-order bit in the first 8-bit octet, and the eighth bit will be the low-order bit in the first 8-bit octet, and so on.
编码过程将输入位的24位组表示为4个编码字符的输出字符串。从左到右，通过连接三个8位输入组形成24位输入组。然后将这24位视为四个串联的6位组，每个组被转换为基数为64的字母表中的一个数字。当使用基数-64编码对位流进行编码时，必须假定该位流以最高有效位优先排序。也就是说，流中的第一位将是第一个8位八位组中的高阶位，第八位将是第一个8位八位组中的低阶位，依此类推。
+--first octet--+-second octet--+--third octet--+
|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
+-----------+---+-------+-------+---+-----------+
|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|
+--1.index--+--2.index--+--3.index--+--4.index--+
+--first octet--+-second octet--+--third octet--+
|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
+-----------+---+-------+-------+---+-----------+
|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|
+--1.index--+--2.index--+--3.index--+--4.index--+
Each 6-bit group is used as an index into an array of 64 printable characters from the table below. The character referenced by the index is placed in the output string.
每个6位组用作下表中64个可打印字符数组的索引。索引引用的字符被放置在输出字符串中。
Value Encoding Value Encoding Value Encoding Value Encoding 0 A 17 R 34 i 51 z 1 B 18 S 35 j 52 0 2 C 19 T 36 k 53 1 3 D 20 U 37 l 54 2 4 E 21 V 38 m 55 3 5 F 22 W 39 n 56 4 6 G 23 X 40 o 57 5 7 H 24 Y 41 p 58 6 8 I 25 Z 42 q 59 7 9 J 26 a 43 r 60 8 10 K 27 b 44 s 61 9 11 L 28 c 45 t 62 + 12 M 29 d 46 u 63 / 13 N 30 e 47 v 14 O 31 f 48 w (pad) = 15 P 32 g 49 x 16 Q 33 h 50 y
数值编码数值编码数值编码数值编码数值编码0a17r34i51z1b18s35j520c19t36k531d20u37l542e21v21v21v38m5535f22w39n5646g23x40o577h24y41p5868i25z42q597j26a43r60810k27b6111l28t62+12m29d46u63/13n30e47v31f48w（pad）=15 P 32 g 49 x 16 Q 33 h 50 y
The encoded output stream must be represented in lines of no more than 76 characters each.
编码的输出流必须以不超过76个字符的行表示。
Special processing is performed if fewer than 24 bits are available at the end of the data being encoded. There are three possibilities:
如果在编码的数据末尾可用的位少于24位，则执行特殊处理。有三种可能性：
1. The last data group has 24 bits (3 octets). No special processing is needed.
1. 最后一个数据组有24位（3个八位字节）。无需特殊处理。
2. The last data group has 16 bits (2 octets). The first two 6-bit groups are processed as above. The third (incomplete) data group has two zero-value bits added to it, and is processed as above. A pad character (=) is added to the output.
2. 最后一个数据组有16位（2个八位字节）。前两个6位组的处理如上所述。第三个（不完整）数据组添加了两个零值位，并按上述方式进行处理。一个填充字符（=）被添加到输出中。
3. The last data group has 8 bits (1 octet). The first 6-bit group is processed as above. The second (incomplete) data group has four zero-value bits added to it, and is processed as above. Two pad characters (=) are added to the output.
3. 最后一个数据组有8位（1个八位字节）。第一个6位组的处理如上所述。第二个（不完整）数据组添加了四个零值位，并按上述方式进行处理。输出中添加了两个pad字符（=）。
Any characters outside of the base64 alphabet are ignored in Radix-64 data. Decoding software must ignore all line breaks or other characters not found in the table above.
在基数为64的数据中，将忽略base64字母表之外的任何字符。解码软件必须忽略上表中未找到的所有换行符或其他字符。
In Radix-64 data, characters other than those in the table, line breaks, and other white space probably indicate a transmission error, about which a warning message or even a message rejection might be appropriate under some circumstances.
在基数为64的数据中，表中字符以外的字符、换行符和其他空白可能表示传输错误，在某些情况下，可能需要发出警告消息，甚至拒绝消息。
Because it is used only for padding at the end of the data, the occurrence of any "=" characters may be taken as evidence that the end of the data has been reached (without truncation in transit). No such assurance is possible, however, when the number of octets transmitted was a multiple of three and no "=" characters are present.
由于它仅用于数据结尾处的填充，因此任何“=”字符的出现都可以作为已到达数据结尾的证据（在传输过程中没有截断）。然而，当传输的八位字节数是三的倍数且不存在“=”字符时，不可能有这样的保证。
Input data: 0x14fb9c03d97e Hex: 1 4 f b 9 c | 0 3 d 9 7 e 8-bit: 00010100 11111011 10011100 | 00000011 11011001 11111110 6-bit: 000101 001111 101110 011100 | 000000 111101 100111 111110 Decimal: 5 15 46 28 0 61 37 62 Output: F P u c A 9 l +
输入数据：0x14fb9c03d97e十六进制：1 4 f b 9 c | 0 3 d 9 7 e 8位：0000100 11111 011 10011100 | 000000 11 11011001 11111111 0 6位：000101111 101110 011100 | 000000 111101 100111 11111 0十进制：5 15 46 28 0 61 37 62输出：f P u c 9 l+
Input data: 0x14fb9c03d9 Hex: 1 4 f b 9 c | 0 3 d 9 8-bit: 00010100 11111011 10011100 | 00000011 11011001 pad with 00 6-bit: 000101 001111 101110 011100 | 000000 111101 100100 Decimal: 5 15 46 28 0 61 36 pad with = Output: F P u c A 9 k =
输入数据：0x14fb9c03d9十六进制：1 4 f b 9 c | 0 3 d 9 8位：0000100 11111 011 10011100 | 000000 11 11011001焊盘带00 6位：000101001111 101110 01100 | 000000 111101 100100十进制：5 15 46 28 0 61 36焊盘带=输出：f P u c 9 k=
Input data: 0x14fb9c03
Hex: 1 4 f b 9 c | 0 3
8-bit: 00010100 11111011 10011100 | 00000011
pad with 0000
6-bit: 000101 001111 101110 011100 | 000000 110000
Decimal: 5 15 46 28 0 48
pad with = =
Output: F P u c A w = =
Input data: 0x14fb9c03
Hex: 1 4 f b 9 c | 0 3
8-bit: 00010100 11111011 10011100 | 00000011
pad with 0000
6-bit: 000101 001111 101110 011100 | 000000 110000
Decimal: 5 15 46 28 0 48
pad with = =
Output: F P u c A w = =
-----BEGIN PGP MESSAGE-----
Version: OpenPrivacy 0.99
-----BEGIN PGP MESSAGE-----
Version: OpenPrivacy 0.99
yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS
vBSFjNSiVHsuAA==
=njUN
-----END PGP MESSAGE-----
yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS
vBSFjNSiVHsuAA==
=njUN
-----END PGP MESSAGE-----
Note that this example is indented by two spaces.
请注意，此示例缩进两个空格。
It is desirable to sign a textual octet stream without ASCII armoring the stream itself, so the signed text is still readable without special software. In order to bind a signature to such a cleartext, this framework is used. (Note that RFC 2015 defines another way to clear sign messages for environments that support MIME.)
希望在没有ASCII对流本身进行铠装的情况下对文本八位字节流进行签名，因此签名文本在没有特殊软件的情况下仍然可读。为了将签名绑定到这样的明文，使用了这个框架。（请注意，RFC 2015为支持MIME的环境定义了另一种清除签名消息的方法。）
The cleartext signed message consists of:
明文签名的消息包括：
- The cleartext header '-----BEGIN PGP SIGNED MESSAGE-----' on a single line,
- 明文标题“----开始PGP签名消息”--在一行上，
- One or more "Hash" Armor Headers,
- 一个或多个“散列”装甲头，
- Exactly one empty line not included into the message digest,
- 只有一行空行未包含在消息摘要中，
- The dash-escaped cleartext that is included into the message digest,
- 包含在消息摘要中的破折号转义明文，
- The ASCII armored signature(s) including the '-----BEGIN PGP SIGNATURE-----' Armor Header and Armor Tail Lines.
- ASCII装甲签名，包括“-----开始PGP签名---”装甲头线和装甲尾线。
If the "Hash" armor header is given, the specified message digest algorithm is used for the signature. If there are no such headers, MD5 is used, an implementation MAY omit them for V2.x compatibility. If more than one message digest is used in the signature, the "Hash" armor header contains a comma-delimited list of used message digests.
如果给出了“散列”标题，则签名将使用指定的消息摘要算法。如果没有这样的头，则使用MD5，实现可能会出于V2.x兼容性而忽略它们。如果签名中使用了多个消息摘要，“哈希”标题包含一个逗号分隔的已用消息摘要列表。
Current message digest names are described below with the algorithm IDs.
下面用算法ID描述了当前消息摘要名称。
The cleartext content of the message must also be dash-escaped.
消息的明文内容也必须进行破折号转义。
Dash escaped cleartext is the ordinary cleartext where every line starting with a dash '-' (0x2D) is prefixed by the sequence dash '-' (0x2D) and space ' ' (0x20). This prevents the parser from recognizing armor headers of the cleartext itself. The message digest is computed using the cleartext itself, not the dash escaped form.
破折号转义明文是普通明文，其中以破折号“-”（0x2D）开头的每一行都以破折号“-”（0x2D）和空格“”作为前缀。这会阻止解析器识别明文本身的标题。消息摘要是使用明文本身而不是破折号转义形式计算的。
As with binary signatures on text documents, a cleartext signature is
calculated on the text using canonical <CR><LF> line endings. The
line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP
SIGNATURE-----' line that terminates the signed text is not
considered part of the signed text.
As with binary signatures on text documents, a cleartext signature is
calculated on the text using canonical <CR><LF> line endings. The
line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP
SIGNATURE-----' line that terminates the signed text is not
considered part of the signed text.
Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of any line is ignored when the cleartext signature is calculated.
此外，在计算明文签名时，任何行末尾的任何尾随空格（空格和制表符，0x09）都将被忽略。
A regular expression is zero or more branches, separated by '|'. It matches anything that matches one of the branches.
正则表达式是零个或多个分支，由“|”分隔。它匹配与其中一个分支匹配的任何对象。
A branch is zero or more pieces, concatenated. It matches a match for the first, followed by a match for the second, etc.
分支是零个或多个连接的片段。它与第一个匹配，然后与第二个匹配，以此类推。
A piece is an atom possibly followed by '*', '+', or '?'. An atom followed by '*' matches a sequence of 0 or more matches of the atom. An atom followed by '+' matches a sequence of 1 or more matches of the atom. An atom followed by '?' matches a match of the atom, or the null string.
片段是一个原子，后面可能跟有“*”、“+”或“？”。后跟“*”的原子匹配该原子的0个或多个匹配项的序列。后跟“+”的原子匹配该原子的一个或多个匹配序列。后跟“？”的原子与该原子的匹配项或空字符串匹配。
An atom is a regular expression in parentheses (matching a match for the regular expression), a range (see below), '.' (matching any single character), '^' (matching the null string at the beginning of the input string), '$' (matching the null string at the end of the input string), a '\' followed by a single character (matching that character), or a single character with no other significance (matching that character).
原子是括号中的正则表达式（匹配正则表达式）、范围（见下文）、“.”（匹配任何单个字符）、“^”（匹配输入字符串开头的空字符串）、“$”（匹配输入字符串结尾的空字符串）、后跟单个字符的“\”（匹配该字符），或者一个没有其他意义的字符（匹配该字符）。
A range is a sequence of characters enclosed in '[]'. It normally matches any single character from the sequence. If the sequence begins with '^', it matches any single character not from the rest of the sequence. If two characters in the sequence are separated by '-', this is shorthand for the full list of ASCII characters between them (e.g. '[0-9]' matches any decimal digit). To include a literal ']' in the sequence, make it the first character (following a possible '^'). To include a literal '-', make it the first or last character.
范围是包含在“[]”中的字符序列。它通常匹配序列中的任何单个字符。如果序列以“^”开头，它将匹配序列其余部分以外的任何单个字符。如果序列中的两个字符以“-”分隔，则这是它们之间ASCII字符的完整列表的缩写（例如，“[0-9]”匹配任何十进制数字）。要在序列中包含文字']'，请将其作为第一个字符（可能的'^'后面）。要包含文字'-'，请将其作为第一个或最后一个字符。
This section describes the constants used in OpenPGP.
本节介绍OpenPGP中使用的常量。
Note that these tables are not exhaustive lists; an implementation MAY implement an algorithm not on these lists.
请注意，这些表格并非详尽无遗的列表；实现可以实现不在这些列表上的算法。
See the section "Notes on Algorithms" below for more discussion of the algorithms.
有关算法的更多讨论，请参见下面的“算法注释”部分。
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 - Reserved for Elliptic Curve
19 - Reserved for ECDSA
20 - Elgamal (Encrypt or Sign)
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 - Reserved for Elliptic Curve
19 - Reserved for ECDSA
20 - Elgamal (Encrypt or Sign)
21 - Reserved for Diffie-Hellman (X9.42, as defined for IETF-S/MIME) 100 to 110 - Private/Experimental algorithm.
21-保留给Diffie Hellman（X9.42，定义为IETF-S/MIME）100至110-专用/实验算法。
Implementations MUST implement DSA for signatures, and Elgamal for encryption. Implementations SHOULD implement RSA keys. Implementations MAY implement any other algorithm.
实现必须实现签名的DSA和加密的Elgamal。实现应该实现RSA密钥。实现可以实现任何其他算法。
ID Algorithm
-- ---------
0 - Plaintext or unencrypted data
1 - IDEA [IDEA]
2 - Triple-DES (DES-EDE, as per spec -
168 bit key derived from 192)
3 - CAST5 (128 bit key, as per RFC 2144)
4 - Blowfish (128 bit key, 16 rounds) [BLOWFISH]
5 - SAFER-SK128 (13 rounds) [SAFER]
6 - Reserved for DES/SK
7 - Reserved for AES with 128-bit key
ID Algorithm
-- ---------
0 - Plaintext or unencrypted data
1 - IDEA [IDEA]
2 - Triple-DES (DES-EDE, as per spec -
168 bit key derived from 192)
3 - CAST5 (128 bit key, as per RFC 2144)
4 - Blowfish (128 bit key, 16 rounds) [BLOWFISH]
5 - SAFER-SK128 (13 rounds) [SAFER]
6 - Reserved for DES/SK
7 - Reserved for AES with 128-bit key
8 - Reserved for AES with 192-bit key 9 - Reserved for AES with 256-bit key 100 to 110 - Private/Experimental algorithm.
8-保留用于192位密钥的AES 9-保留用于256位密钥为100到110的AES-专用/实验算法。
Implementations MUST implement Triple-DES. Implementations SHOULD implement IDEA and CAST5.Implementations MAY implement any other algorithm.
实现必须实现三重DES。实现应该实现IDEA和CAST5。实现可以实现任何其他算法。
ID Algorithm
-- ---------
0 - Uncompressed
1 - ZIP (RFC 1951)
2 - ZLIB (RFC 1950)
100 to 110 - Private/Experimental algorithm.
ID Algorithm
-- ---------
0 - Uncompressed
1 - ZIP (RFC 1951)
2 - ZLIB (RFC 1950)
100 to 110 - Private/Experimental algorithm.
Implementations MUST implement uncompressed data. Implementations SHOULD implement ZIP. Implementations MAY implement ZLIB.
实现必须实现未压缩的数据。实现应该实现ZIP。实现可以实现ZLIB。
ID Algorithm Text Name
-- --------- ---- ----
1 - MD5 "MD5"
2 - SHA-1 "SHA1"
3 - RIPE-MD/160 "RIPEMD160"
4 - Reserved for double-width SHA (experimental)
5 - MD2 "MD2"
6 - Reserved for TIGER/192 "TIGER192"
7 - Reserved for HAVAL (5 pass, 160-bit)
"HAVAL-5-160"
100 to 110 - Private/Experimental algorithm.
ID Algorithm Text Name
-- --------- ---- ----
1 - MD5 "MD5"
2 - SHA-1 "SHA1"
3 - RIPE-MD/160 "RIPEMD160"
4 - Reserved for double-width SHA (experimental)
5 - MD2 "MD2"
6 - Reserved for TIGER/192 "TIGER192"
7 - Reserved for HAVAL (5 pass, 160-bit)
"HAVAL-5-160"
100 to 110 - Private/Experimental algorithm.
Implementations MUST implement SHA-1. Implementations SHOULD implement MD5.
实现必须实现SHA-1。实现应该实现MD5。
OpenPGP packets are assembled into sequences in order to create messages and to transfer keys. Not all possible packet sequences are meaningful and correct. This describes the rules for how packets should be placed into sequences.
OpenPGP数据包被组装成序列，以便创建消息和传输密钥。并非所有可能的数据包序列都是有意义和正确的。这描述了如何将数据包放入序列中的规则。
OpenPGP users may transfer public keys. The essential elements of a transferable public key are:
OpenPGP用户可以传输公钥。可转让公钥的基本要素包括：
- One Public Key packet
- 一个公钥包
- Zero or more revocation signatures
- 零个或多个撤销签名
- One or more User ID packets
- 一个或多个用户ID数据包
- After each User ID packet, zero or more signature packets (certifications)
- 在每个用户ID数据包之后，零个或多个签名数据包（证书）
- Zero or more Subkey packets
- 零个或多个子密钥包
- After each Subkey packet, one signature packet, optionally a revocation.
- 在每个子密钥包之后，一个签名包，可选地一个撤销。
The Public Key packet occurs first. Each of the following User ID packets provides the identity of the owner of this public key. If there are multiple User ID packets, this corresponds to multiple means of identifying the same unique individual user; for example, a user may have more than one email address, and construct a User ID for each one.
公钥包首先出现。以下每个用户ID数据包都提供此公钥所有者的身份。如果存在多个用户ID分组，则这对应于识别相同唯一个人用户的多个方法；例如，用户可能有多个电子邮件地址，并为每个电子邮件地址构造一个用户ID。
Immediately following each User ID packet, there are zero or more signature packets. Each signature packet is calculated on the immediately preceding User ID packet and the initial Public Key packet. The signature serves to certify the corresponding public key and user ID. In effect, the signer is testifying to his or her belief that this public key belongs to the user identified by this user ID.
紧接着每个用户ID数据包，就有零个或多个签名数据包。每个签名包都是在紧接前一个用户ID包和初始公钥包上计算的。签名用于证明相应的公钥和用户ID。实际上，签名者证明他或她相信该公钥属于该用户ID标识的用户。
After the User ID packets there may be one or more Subkey packets. In general, subkeys are provided in cases where the top-level public key is a signature-only key. However, any V4 key may have subkeys, and the subkeys may be encryption-only keys, signature-only keys, or general-purpose keys.
在用户ID分组之后，可以有一个或多个子密钥分组。通常，在顶级公钥是仅签名密钥的情况下提供子密钥。然而，任何V4密钥都可以具有子密钥，并且子密钥可以是仅加密密钥、仅签名密钥或通用密钥。
Each Subkey packet must be followed by one Signature packet, which should be a subkey binding signature issued by the top level key.
每个子密钥包后面必须有一个签名包，该签名包应该是由顶级密钥发布的子密钥绑定签名。
Subkey and Key packets may each be followed by a revocation Signature packet to indicate that the key is revoked. Revocation signatures are only accepted if they are issued by the key itself, or by a key that is authorized to issue revocations via a revocation key subpacket in a self-signature by the top level key.
子密钥和密钥分组可各自后跟撤销签名分组，以指示密钥被撤销。只有当撤销签名是由密钥本身发出的，或者是由被授权通过顶级密钥自签名中的撤销密钥子包发出撤销的密钥发出的时，才接受撤销签名。
Transferable public key packet sequences may be concatenated to allow transferring multiple public keys in one operation.
可转移公钥分组序列可被串联以允许在一个操作中转移多个公钥。
An OpenPGP message is a packet or sequence of packets that corresponds to the following grammatical rules (comma represents sequential composition, and vertical bar separates alternatives):
OpenPGP消息是与以下语法规则相对应的数据包或数据包序列（逗号表示顺序组合，竖线分隔备选方案）：
OpenPGP Message :- Encrypted Message | Signed Message | Compressed Message | Literal Message.
OpenPGP消息：-加密消息|签名消息|压缩消息|文字消息。
Compressed Message :- Compressed Data Packet.
压缩消息：-压缩数据包。
Literal Message :- Literal Data Packet.
文字信息：-文字数据包。
ESK :- Public Key Encrypted Session Key Packet | Symmetric-Key Encrypted Session Key Packet.
ESK:-公钥加密会话密钥包|对称密钥加密会话密钥包。
ESK Sequence :- ESK | ESK Sequence, ESK.
ESK序列：ESK | ESK序列，ESK。
Encrypted Message :- Symmetrically Encrypted Data Packet | ESK Sequence, Symmetrically Encrypted Data Packet.
加密消息：-对称加密数据包| ESK序列，对称加密数据包。
One-Pass Signed Message :- One-Pass Signature Packet, OpenPGP Message, Corresponding Signature Packet.
一次签名报文：-一次签名报文，OpenPGP报文，对应的签名报文。
Signed Message :- Signature Packet, OpenPGP Message | One-Pass Signed Message.
签名消息：-签名包，OpenPGP消息|一次通过签名消息。
In addition, decrypting a Symmetrically Encrypted Data packet and
此外，解密对称加密的数据包和
decompressing a Compressed Data packet must yield a valid OpenPGP Message.
解压缩压缩数据包必须产生有效的OpenPGP消息。
Some OpenPGP applications use so-called "detached signatures." For example, a program bundle may contain a file, and with it a second file that is a detached signature of the first file. These detached signatures are simply a signature packet stored separately from the data that they are a signature of.
一些OpenPGP应用程序使用所谓的“分离签名”。例如，一个程序包可能包含一个文件，以及一个作为第一个文件分离签名的第二个文件。这些分离的签名只是一个签名包，它与作为签名的数据分开存储。
The format of an OpenPGP V3 key is as follows. Entries in square brackets are optional and ellipses indicate repetition.
OpenPGPV3密钥的格式如下所示。方括号中的条目是可选的，省略号表示重复。
RSA Public Key
[Revocation Self Signature]
User ID [Signature ...]
[User ID [Signature ...] ...]
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.
每个签名都证明RSA公钥和前面的用户ID。RSA公钥可以有多个用户ID，每个用户ID可以有多个签名。
The format of an OpenPGP V4 key that uses two public keys is similar except that the other keys are added to the end as 'subkeys' of the primary key.
使用两个公钥的OpenPGP V4密钥的格式类似，只是其他密钥作为主键的“子密钥”添加到末尾。
Primary-Key
[Revocation Self Signature]
[Direct Key Self Signature...]
User ID [Signature ...]
[User ID [Signature ...] ...]
[[Subkey [Binding-Signature-Revocation]
Primary-Key-Binding-Signature] ...]
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 preferred, of course.
子密钥之后始终有一个签名，该签名使用主键将两个密钥绑定在一起。此绑定签名可以是V3或V4格式，但V4当然是首选格式。
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 RSA encryption key, or RSA primary key with an Elgamal subkey, etc.
在具有主键和子键的密钥中，主键必须是能够签名的密钥。子键可以是任何其他类型的键。V4键也可能有其他构造。例如，可能有V4格式的单密钥RSA密钥、带有RSA加密密钥的DSA主密钥或带有Elgamal子密钥的RSA主密钥等。
It is also possible to have a signature-only subkey. This permits a primary key that collects certifications (key signatures) but is used only used for certifying subkeys that are used for encryption and signatures.
也可以具有仅签名的子密钥。这允许主密钥收集证书（密钥签名），但仅用于认证用于加密和签名的子密钥。
For a V3 key, the eight-octet key ID consists of the low 64 bits of the public modulus of the RSA key.
对于V3密钥，八个八位组密钥ID由RSA密钥的公共模的低64位组成。
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.
V3密钥的指纹是通过将构成密钥材料（公共模数n，后跟指数e）的MPI的主体（而不是两个八位组长度）散列到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 the low order 64 bits of the fingerprint. Here are the fields of the hash material, with the example of a DSA key:
V4指纹是一个八位字节数据包标签的160位SHA-1散列，后跟两个八位字节数据包长度，后跟从版本字段开始的整个公钥数据包。密钥ID是指纹的低阶64位。以下是哈希材料的字段，以DSA密钥为例：
a.1) 0x99 (1 octet)
a、 1）0x99（1个八位组）
a.2) high order length octet of (b)-(f) (1 octet)
a、 （b）-（f）（1个八位组）的高阶长度八位组
a.3) low order length octet of (b)-(f) (1 octet)
a、 （b）-（f）（1个八位组）的低阶长度八位组
b) version number = 4 (1 octet);
b) 版本号=4（1个八位组）；
c) time stamp of key creation (4 octets);
c) 密钥创建的时间戳（4个八位字节）；
d) algorithm (1 octet): 17 = DSA (example);
d) algorithm (1 octet): 17 = DSA (example);
e) Algorithm specific fields.
e) 算法特定字段。
Algorithm Specific Fields for DSA keys (example):
DSA密钥的算法特定字段（示例）：
e.1) MPI of DSA prime p;
e、 1）DSA素数p的MPI；
e.2) MPI of DSA group order q (q is a prime divisor of p-1);
e、 2）DSA组阶q的MPI（q是p-1的素因子）；
e.3) MPI of DSA group generator g;
e、 3）DSA组生成器g的MPI；
e.4) MPI of DSA public key value y (= g**x where x is secret).
e、 4）DSA公钥值y的MPI（=g**x，其中x为机密）。
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.
请注意，可能存在密钥ID冲突——两个具有相同密钥ID的不同密钥。请注意，两个不同密钥具有相同指纹的概率要小得多，但仍然不是零。
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 fingerprints.
还要注意，如果V3和V4格式密钥共享相同的RSA密钥材料，则它们将具有不同的密钥ID以及不同的指纹。
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 different preferences. For example, Alice may have TripleDES only specified for "alice@work.com" but CAST5, Blowfish, and TripleDES specified for "alice@home.org".
对称算法首选项是密钥持有者接受的算法的有序列表。因为它是在自签名上发现的，所以可能一个密钥持有者有不同的偏好。例如，Alice可能只为“指定了三个参数”alice@work.com但是CAST5、河豚和三倍体是为alice@home.org".
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.
由于TripleDES是必须实现的算法，如果它没有显式地出现在列表中，那么它将默认地出现在最后。然而，明确地将其放在那里是一种很好的形式。还要注意的是，如果一个实现没有实现首选项，那么它隐式地是一个只有三元组的实现。
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.
实现不能使用不在收件人首选项列表中的对称算法。当对多个收件人进行加密时，实现通过获取收件人偏好的交集来找到合适的算法。请注意，必须实现算法TripleDES，以确保交点不为空。该实现可以使用任何机制来选择交叉点中的算法。
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 than 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.)
如果一个实现可以解密密钥持有者首选项中没有的消息，那么该实现无论如何都应该解密该消息，但必须警告密钥持有者违反了协议。（例如，假设上面的Alice拥有实现本规范中所有算法的软件。尽管如此，她还是喜欢在工作或家庭中使用子集。如果向她发送了一条使用IDEA加密的消息（这不在她的首选项中），软件会警告她有人向她发送了IDEA加密的消息，但无论如何它都会对其进行理想的解密。）
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. Consequently, an implementation MAY, but SHOULD NOT use IDEA in an algorithm conflict with a V3 key.
一种追求向后兼容性的实现可以考虑V3密钥，其中V3自签名是对思想的隐式偏好，而不能够做三次。这在技术上是不符合的，但实现可能仅在这种情况下违反上述规则，并使用IDEA加密消息，前提是消息创建者受到警告。但是，理想情况下，实现将遵循规则，实际生成两条消息，因为OpenPGP用户的实现可能没有想法，因此无法读取消息。因此，一个实现可以，但不应该在算法与V3密钥冲突时使用IDEA。
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.
其他算法首选项的工作方式与对称算法首选项类似，因为它们指定了密钥持有者接受的算法。不过，有两个有趣的例子需要对压缩首选项和哈希首选项进行其他注释。
Compression has been an integral part of PGP since its first days. OpenPGP and all previous versions of PGP have offered compression. And in this 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.
自PGP诞生之日起，压缩就成为其不可或缺的一部分。OpenPGP和所有以前版本的PGP都提供了压缩。在本规范中，默认情况下是对消息进行压缩，尽管不需要实现。因此，压缩首选项为密钥持有者提供了一种请求消息不被压缩的方式，可能是因为它们使用的是不包括压缩的最小实现。此外，这为密钥持有者提供了一种声明它可以支持其他算法的方式。
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), UNCOMPRESSED(0)].
与算法首选项一样，实现不得使用不在首选项向量中的算法。如果首选项不存在，则假定它们为[ZIP（1），未压缩（0）]。
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.
通常，哈希算法的选择是签名者而不是验证者所做的，因为签名者通常不知道谁将要验证签名。然而，这种偏好使得基于数字签名的协议易于协商。
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.
因此，如果Alice使用签名向Bob验证自己，那么她使用Bob软件使用的哈希算法是有意义的。此首选项允许Bob在其密钥中声明Alice可能使用的算法。
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.
算法0“明文”只能用于表示明文中存储的密钥。实现不能在对称加密的数据包中使用明文；他们必须使用文字数据包对未加密或文字数据进行编码。
There are algorithm types for RSA-signature-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.
有仅用于RSA签名的算法类型和仅用于RSA加密密钥的算法类型。这些类型已弃用。签名中的“密钥标志”子包是表达相同想法的更好方法，并将其推广到所有算法。实现不应该创建这样一个键，但可以解释它。
An implementation SHOULD NOT implement RSA keys of size less than 768 bits.
实现不应实现大小小于768位的RSA密钥。
It is permissible for an implementation to support RSA merely for backward compatibility; for example, such an implementation would support V3 keys with IDEA symmetric cryptography. Note that this is an exception to the other MUST-implement rules. An implementation that supports RSA in V4 keys MUST implement the MUST-implement features.
允许实现仅为向后兼容而支持RSA；例如，这样的实现将支持使用IDEA对称加密技术的V3密钥。请注意，这是其他必须实现规则的例外。支持V4密钥中的RSA的实现必须实现必须实现的功能。
If an Elgamal key is to be used for both signing and encryption, extra care must be taken in creating the key.
如果Elgamal密钥同时用于签名和加密，则在创建密钥时必须格外小心。
An ElGamal key consists of a generator g, a prime modulus p, a secret exponent x, and a public value y = g^x mod p.
ElGamal密钥由生成器g、素数模p、秘密指数x和公共值y=g^x mod p组成。
The generator and prime must be chosen so that solving the discrete log problem is intractable. The group g should generate the multiplicative group mod p-1 or a large subgroup of it, and the order of g should have at least one large prime factor. A good choice is to use a "strong" Sophie-Germain prime in choosing p, so that both p and (p-1)/2 are primes. In fact, this choice is so good that implementors SHOULD do it, as it avoids a small subgroup attack.
必须选择生成器和素数，以解决离散对数问题。群g应该生成乘法群mod p-1或它的一个大子群，并且g的阶应该至少有一个大素因子。一个好的选择是使用“强”Sophie Germain素数来选择p，这样p和（p-1）/2都是素数。事实上，这个选择非常好，实现者应该这样做，因为它避免了一个小的子组攻击。
In addition, a result of Bleichenbacher [BLEICHENBACHER] shows that if the generator g has only small prime factors, and if g divides the order of the group it generates, then signatures can be forged. In particular, choosing g=2 is a bad choice if the group order may be even. On the other hand, a generator of 2 is a fine choice for an encryption-only key, as this will make the encryption faster.
此外，Bleichenbacher[Bleichenbacher]的一个结果表明，如果生成器g只有小的素因子，并且如果g划分它生成的组的顺序，则签名可以伪造。特别是，如果组顺序可能为偶数，则选择g=2是一个错误的选择。另一方面，对于仅加密密钥，2的生成器是一个不错的选择，因为这将加快加密速度。
While verifying Elgamal signatures, note that it is important to test that r and s are less than p. If this test is not done then signatures can be trivially forged by using large r values of approximately twice the length of p. This attack is also discussed in the Bleichenbacher paper.
在验证Elgamal签名时，请注意，测试r和s是否小于p是很重要的。如果不进行此测试，则可以通过使用约为p长度两倍的大r值来伪造签名。Bleichenbacher论文中也讨论了这种攻击。
Details on safe use of Elgamal signatures may be found in [MENEZES], which discusses all the weaknesses described above.
有关安全使用Elgamal签名的详细信息可在[MENEZES]中找到，其中讨论了上述所有弱点。
If an implementation allows Elgamal signatures, then it MUST use the algorithm identifier 20 for an Elgamal public key that can sign.
如果实现允许Elgamal签名，那么它必须将算法标识符20用于可以签名的Elgamal公钥。
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.
实现不应实现大小小于768位的Elgamal密钥。为了长期安全，Elgamal密钥应为1024位或更长。
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.
实现不应实现大小小于768位的DSA密钥。请注意，当前DSA限制为最多1024位密钥，建议长期使用。
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)".
许多算法ID都是为OpenPGP实现中使用的算法保留的，但也有一些问题妨碍了实现者实际实现该算法。这些在公共算法部分中标记为“（保留用于）”。
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.
保留公钥算法椭圆曲线（18）、ECDSA（19）和X9.42（21）没有定义必要的参数、参数顺序或语义。
The reserved symmetric key algorithm, DES/SK (6), does not have semantics defined.
保留对称密钥算法DES/SK（6）没有定义语义。
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.
保留哈希算法TIGER192（6）和HAVAL-5-160（7）没有OID。为SHA1的双倍宽度变体保留的保留算法编号4目前尚未定义。
We have reserver three algorithm IDs for the US NIST's Advanced Encryption Standard. This algorithm will work with (at least) 128, 192, and 256-bit keys. We expect that this algorithm will be selected from the candidate algorithms in the year 2000.
我们为美国NIST的高级加密标准保留了三个算法ID。此算法将使用（至少）128、192和256位密钥。我们预计该算法将在2000年从候选算法中选出。
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模式）的变体进行对称加密。本节详细介绍了它使用的过程。此模式用于对称加密的数据包；用于加密密钥材料的机制类似，但在上述章节中进行了描述。
OpenPGP CFB mode uses an initialization vector (IV) of all zeros, 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.
OpenPGP CFB模式使用全零的初始化向量（IV），并在明文前加上十个随机数据的八位字节，以便八位字节9和10匹配八位字节7和8。加密这十个八位组后，它会进行循环流化床“重新同步”。
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.
请注意，对于块大小大于64位的算法，将对整个块执行等效函数。例如，一个16个八位字节的块算法将在16个八位字节上运行，然后生成两个八位字节的校验，然后在16个八位字节块上运行。
Step by step, here is the procedure:
步骤如下：
1. The feedback register (FR) is set to the IV, which is all zeros.
1. 反馈寄存器（FR）设置为IV，该值为全零。
2. FR is encrypted to produce FRE (FR Encrypted). This is the encryption of an all-zero value.
2. FR被加密以产生FRE（FR加密）。这是一个全零值的加密。
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.
3. FRE与明文前8个八位字节的随机数据进行异或运算，生成C1-C8，即密文的前8个八位字节。
4. FR is loaded with C1-C8.
4. FR装有C1-C8。
5. FR is encrypted to produce FRE, the encryption of the first 8 octets of ciphertext.
5. FR被加密以产生FRE，即加密密文的前8个八位字节。
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 octets of ciphertext.
6. FRE的左两个八位字节与以明文为前缀的下两个八位字节数据进行异或。这将产生C9-C10，即密文的下两个八位字节。
7. (The resync step) FR is loaded with C3-C10.
7. （重新同步步骤）FR加载C3-C10。
8. FR is encrypted to produce FRE.
8. FR被加密以产生FRE。
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.
9. FRE与给定明文的前8个八位字节进行异或运算，现在我们已经完成了对前缀数据的10个八位字节的加密。这将产生C11-C18，即接下来的8个八位字节的密文。
10. FR is loaded with C11-C18
10. FR加载C11-C18
11. FR is encrypted to produce FRE.
11. FR被加密以产生FRE。
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.
12. FRE与接下来的8个八位字节的明文异或，以生成接下来的8个八位字节的密文。这些文件被加载到FR中，并重复该过程，直到明文用完为止。
As with any technology involving cryptography, you should check the current literature to determine if any algorithms used here have been found to be vulnerable to attack.
与任何涉及密码学的技术一样，您应该检查当前的文献，以确定此处使用的任何算法是否容易受到攻击。
This specification uses Public Key Cryptography technologies. Possession of the private key portion of a public-private key pair is assumed to be controlled by the proper party or parties.
本规范使用公钥加密技术。假定公私密钥对的私钥部分由适当的一方或多方控制。
Certain operations in this specification involve the use of random numbers. An appropriate entropy source should be used to generate these numbers. See RFC 1750.
本规范中的某些操作涉及使用随机数。应该使用适当的熵源来生成这些数字。见RFC 1750。
The MD5 hash algorithm has been found to have weaknesses (pseudo-collisions in the compress function) that make some people deprecate its use. They consider the SHA-1 algorithm better.
MD5哈希算法被发现有弱点（压缩函数中的伪冲突），这使得一些人不赞成使用它。他们认为SHA-1算法更好。
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 implementor promote dual-use keys, you should at least be aware of this controversy.
许多安全协议设计人员认为，对隐私（加密）和完整性（签名）使用单一密钥是个坏主意。事实上，这是V4密钥格式背后的推动力之一，该格式具有单独的签名和加密密钥。如果您作为一个实现者推广两用密钥，您至少应该意识到这一争议。
The DSA algorithm will work with any 160-bit hash, but it is sensitive to the quality of the hash algorithm, if the hash algorithm is broken, it can leak the secret key. The Digital Signature Standard (DSS) specifies that DSA be used with SHA-1. RIPEMD-160 is considered by many cryptographers to be as strong. An implementation should take care which hash algorithms are used with DSA, as a weak hash can not only allow a signature to be forged, but could leak the secret key. These same considerations about the quality of the hash algorithm apply to Elgamal signatures.
DSA算法可以处理任何160位哈希，但它对哈希算法的质量很敏感，如果哈希算法被破坏，它可能会泄漏密钥。数字签名标准（DSS）规定DSA与SHA-1一起使用。许多密码学家认为RIPEMD-160同样强大。实现应注意DSA使用哪些哈希算法，因为弱哈希不仅允许伪造签名，还可能泄漏密钥。这些关于哈希算法质量的考虑同样适用于Elgamal签名。
If you are building an authentication system, the recipient may specify a preferred signing algorithm. However, the signer would be foolish to use a weak algorithm simply because the recipient requests it.
如果您正在构建身份验证系统，则收件人可以指定首选的签名算法。然而，仅仅因为接收者请求，签名者使用弱算法是愚蠢的。
Some of the encryption algorithms mentioned in this document have been analyzed less than others. For example, although CAST5 is presently considered strong, it has been analyzed less than Triple-DES. Other algorithms may have other controversies surrounding them.
本文中提到的一些加密算法的分析较少。例如，虽然CAST5目前被认为是强的，但它的分析少于三倍DES。其他算法可能会有其他争议。
Some technologies mentioned here may be subject to government control in some countries.
这里提到的一些技术可能受到某些国家政府的控制。
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 list of potential problems and gotchas for a developer who is trying to be backward-compatible.
本节是帮助实现者的注释集合，特别是着眼于向后兼容性。以前的PGP实现不符合OpenPGP。通常差异很小，但小差异往往比大差异更令人烦恼。因此，对于试图向后兼容的开发人员来说，这是一个潜在问题和陷阱列表。
* PGP 5.x does not accept V4 signatures for anything other than key material.
* PGP5.x不接受除关键材料以外的任何内容的V4签名。
* PGP 5.x does not recognize the "five-octet" lengths in new-format headers or in signature subpacket lengths.
* PGP5.x不识别新格式头或签名子包长度中的“五个八位字节”长度。
* PGP 5.0 rejects an encrypted session key if the keylength differs from the S2K symmetric algorithm. This is a bug in its validation function.
* 如果密钥长度不同于S2K对称算法，PGP 5.0将拒绝加密的会话密钥。这是其验证功能中的一个错误。
* 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.
* PGP 5.0不处理多个一次通过签名头和尾。Signing one将压缩单次签名文本，并在V3签名前添加前缀，而不是执行嵌套的单次签名。
* 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.
* 导出私钥时，PGP 2.x生成标题“BEGIN PGP SECRET key BLOCK”，而不是“BEGIN PGP private key BLOCK”。所有以前的版本都会忽略隐含的数据类型，并直接查看数据包数据类型。
* In a clear-signed signature, PGP 5.0 will figure out the correct hash algorithm if there is no "Hash:" header, but it will reject a mismatch between the header and the actual algorithm 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.
* 在清晰签名签名中，如果没有“哈希：”头，PGP5.0将找出正确的哈希算法，但它将拒绝头与实际使用的算法之间的不匹配。PGP2.x的“标准”版本（即Zimmermann/Finney/et al.）拒绝使用“哈希：”头，并假定为MD5。有许多PGP 2.6.x的增强型变体已针对SHA-1签名进行了修改。
* 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.
* PGP 5.0可以读取V4格式的RSA密钥，但只能使用V3密钥ID识别该密钥，并且只能正确使用V3格式的RSA密钥。
* Neither PGP 5.x nor PGP 6.0 recognize Elgamal Encrypt and Sign keys. They only handle Elgamal Encrypt-only keys.
* PGP5.x和PGP6.0都无法识别Elgamal加密和签名密钥。它们只处理Elgamal仅加密密钥。
* 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.
* 有许多方法可以使两个密钥具有相同的密钥材料，但指纹不同（因此密钥ID也不同）。也许最有趣的是已“升级”为V4格式的RSA密钥，但由于V4指纹是通过哈希密钥创建时间和其他内容构建的，因此在不同时间创建的两个V4密钥（使用相同的密钥材料）将具有不同的指纹。
* If an implementation is using zlib to interoperate with PGP 2.x, then the "windowBits" parameter should be set to -13.
* 如果一个实现使用zlib与PGP2.x进行互操作，那么“windowBits”参数应该设置为-13。
The working group can be contacted via the current chair:
可通过现任主席联系工作组：
John W. Noerenberg, II Qualcomm, Inc 6455 Lusk Blvd San Diego, CA 92131 USA
美国加利福尼亚州圣地亚哥路斯克大道6455号高通公司，邮编92131
Phone: +1 619-658-3510
EMail: jwn2@qualcomm.com
Phone: +1 619-658-3510
EMail: jwn2@qualcomm.com
The principal authors of this memo are:
本备忘录的主要作者是：
Jon Callas Network Associates, Inc. 3965 Freedom Circle Santa Clara, CA 95054, USA
Jon Callas Network Associates，Inc.美国加利福尼亚州圣克拉拉自由圈3965号，邮编95054
Phone: +1 408-346-5860
EMail: jon@pgp.com, jcallas@nai.com
Phone: +1 408-346-5860
EMail: jon@pgp.com, jcallas@nai.com
Lutz Donnerhacke IKS GmbH Wildenbruchstr. 15 07745 Jena, Germany
卢茨·唐纳哈克IKS有限公司Wildenbruchstr。15 07745耶拿，德国
Phone: +49-3641-675642
EMail: lutz@iks-jena.de
Phone: +49-3641-675642
EMail: lutz@iks-jena.de
Hal Finney Network Associates, Inc. 3965 Freedom Circle Santa Clara, CA 95054, USA
Hal Finney Network Associates，Inc.美国加利福尼亚州圣克拉拉自由圈3965号，邮编95054
EMail: hal@pgp.com
EMail: hal@pgp.com
Rodney Thayer EIS Corporation Clearwater, FL 33767, USA
Rodney Thayer EIS Corporation Clearwater，美国佛罗里达州33767
EMail: rodney@unitran.com
EMail: rodney@unitran.com
This memo 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 Levien, Colin Plumb, Will Price, William Stallings, Mark Weaver, and Philip R. Zimmermann.
这份备忘录还借鉴了许多其他作者以前的作品，他们包括：德里克·阿特金斯、查尔斯·布里德、戴夫·德尔·托托、马克·戴克斯特豪斯、盖尔·哈斯珀特、吉恩·霍夫曼、保罗·霍夫曼、拉斐尔·莱文、科林·普拉姆、威尔·普莱斯、威廉·斯泰林斯、马克·韦弗和菲利普·齐默尔曼。
[BLEICHENBACHER] Bleichenbacher, Daniel, "Generating ElGamal
signatures without knowing the secret key,"
Eurocrypt 96. Note that the version in the
proceedings has an error. A revised version is
available at the time of writing from
<ftp://ftp.inf.ethz.ch/pub/publications/papers/ti/isc
/ElGamal.ps>
[BLEICHENBACHER] Bleichenbacher, Daniel, "Generating ElGamal
signatures without knowing the secret key,"
Eurocrypt 96. Note that the version in the
proceedings has an error. A revised version is
available at the time of writing from
<ftp://ftp.inf.ethz.ch/pub/publications/papers/ti/isc
/ElGamal.ps>
[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
[BLOWFISH]Schneier，B.“一种新的可变长度密钥的描述，64位分组密码（BLOWFISH）”，快速软件加密，剑桥安全研讨会论文集（1993年12月），Springer Verlag，1994年，第191-204页
<http://www.counterpane.com/bfsverlag.html>
<http://www.counterpane.com/bfsverlag.html>
[DONNERHACKE] Donnerhacke, L., et. al, "PGP263in - an improved
international version of PGP", ftp://ftp.iks-
jena.de/mitarb/lutz/crypt/software/pgp/
[DONNERHACKE] Donnerhacke, L., et. al, "PGP263in - an improved
international version of PGP", ftp://ftp.iks-
jena.de/mitarb/lutz/crypt/software/pgp/
[ELGAMAL] T. ElGamal, "A Public-Key Cryptosystem and a Signature Scheme Based on Discrete Logarithms," IEEE Transactions on Information Theory, v. IT-31, n. 4, 1985, pp. 469-472.
[ELGAMAL]T.ELGAMAL，“基于离散对数的公钥密码系统和签名方案”，IEEE信息论交易，v。IT-31，n。1985年4月，第469-472页。
[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
[IDEA]Lai，X，“关于分组密码的设计和安全”，信息处理ETH系列，J.L.Massey（编辑），第一卷，Hartung Gorre Verlag Knostanz，Technische Hochschule（苏黎世），1992年
[ISO-10646] ISO/IEC 10646-1:1993. International Standard -- Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. UTF-8 is described in Annex R, adopted but not yet published. UTF-16 is described in Annex Q, adopted but not yet published.
[ISO-10646]ISO/IEC 10646-1:1993。国际标准信息技术通用多八位编码字符集（UCS）第1部分：体系结构和基本多语言平面。附件R中描述了UTF-8，已采用但尚未发布。附件Q中描述了UTF-16，已采用但尚未发布。
[MENEZES] Alfred Menezes, Paul van Oorschot, and Scott Vanstone, "Handbook of Applied Cryptography," CRC Press, 1996.
[MENEZES]Alfred MENEZES、Paul van Oorschot和Scott Vanstone，《应用密码学手册》，华润出版社，1996年。
[RFC822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[RFC822]Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[RFC1423] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, October 1993.
[RFC1423]Balenson，D.，“互联网电子邮件的隐私增强：第三部分：算法、模式和标识符”，RFC 1423，1993年10月。
[RFC1641] Goldsmith, D. and M. Davis, "Using Unicode with MIME", RFC 1641, July 1994.
[RFC1641]Goldsmith，D.和M.Davis，“将Unicode与MIME结合使用”，RFC 16411994年7月。
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750]Eastlake，D.，Crocker，S.和J.Schiller，“安全性的随机性建议”，RFC 1750，1994年12月。
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3.", RFC 1951, May 1996.
[RFC1951]Deutsch，P.，“压缩数据格式规范1.3版的放气”，RFC1951，1996年5月。
[RFC1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC 1983, August 1996.
[RFC1983]Malkin，G.，“互联网用户词汇表”，第18财年，RFC 1983年，1996年8月。
[RFC1991] Atkins, D., Stallings, W. and P. Zimmermann, "PGP Message Exchange Formats", RFC 1991, August 1996.
[RFC1991]Atkins，D.，Stallings，W.和P.Zimmermann，“PGP消息交换格式”，RFC 1991，1996年8月。
[RFC2015] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996.
[RFC2015]Elkins，M.，“具有良好隐私的MIME安全性（PGP）”，RFC 2015，1996年10月。
[RFC2231] Borenstein, N. and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies.", RFC 2231, November 1996.
[RFC2231]Borenstein，N.和N.Freed，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文的格式”，RFC 22311996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, May 1997.
[RFC2144]Adams，C.，“CAST-128加密算法”，RFC2144，1997年5月。
[RFC2279] Yergeau., F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2279, January 1998.
[RFC2279]Yergeau.，F.，“UTF-8，Unicode和ISO10646的转换格式”，RFC2279，1998年1月。
[RFC2313] Kaliski, B., "PKCS #1: RSA Encryption Standard version 1.5", RFC 2313, March 1998.
[RFC2313]Kaliski，B.，“PKCS#1:RSA加密标准版本1.5”，RFC 2313，1998年3月。
[SAFER] Massey, J.L. "SAFER K-64: One Year Later", B. Preneel, editor, Fast Software Encryption, Second International Workshop (LNCS 1008) pp212-241, Springer-Verlag 1995
[安全]Massey，J.L.“安全K-64：一年后”，B.Preneel，快速软件加密编辑，第二届国际研讨会（LNCS 1008）pp212-241，Springer Verlag 1995
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。