Internet Engineering Task Force (IETF) P. Zimmermann
Request for Comments: 6189 Zfone Project
Category: Informational A. Johnston, Ed.
ISSN: 2070-1721 Avaya
J. Callas
Apple, Inc.
April 2011
Internet Engineering Task Force (IETF) P. Zimmermann
Request for Comments: 6189 Zfone Project
Category: Informational A. Johnston, Ed.
ISSN: 2070-1721 Avaya
J. Callas
Apple, Inc.
April 2011
ZRTP: Media Path Key Agreement for Unicast Secure RTP
ZRTP：单播安全RTP的媒体路径密钥协议
Abstract
摘要
This document defines ZRTP, a protocol for media path Diffie-Hellman exchange to agree on a session key and parameters for establishing unicast Secure Real-time Transport Protocol (SRTP) sessions for Voice over IP (VoIP) applications. The ZRTP protocol is media path keying because it is multiplexed on the same port as RTP and does not require support in the signaling protocol. ZRTP does not assume a Public Key Infrastructure (PKI) or require the complexity of certificates in end devices. For the media session, ZRTP provides confidentiality, protection against man-in-the-middle (MiTM) attacks, and, in cases where the signaling protocol provides end-to-end integrity protection, authentication. ZRTP can utilize a Session Description Protocol (SDP) attribute to provide discovery and authentication through the signaling channel. To provide best effort SRTP, ZRTP utilizes normal RTP/AVP (Audio-Visual Profile) profiles. ZRTP secures media sessions that include a voice media stream and can also secure media sessions that do not include voice by using an optional digital signature.
本文档定义了ZRTP，这是一种媒体路径Diffie-Hellman exchange协议，用于商定会话密钥和参数，以便为IP语音（VoIP）应用程序建立单播安全实时传输协议（SRTP）会话。ZRTP协议是媒体路径键控，因为它与RTP在同一端口上多路复用，不需要信令协议中的支持。ZRTP不采用公钥基础设施（PKI），也不需要终端设备中证书的复杂性。对于媒体会话，ZRTP提供机密性，防止中间人（MiTM）攻击，并且在信令协议提供端到端完整性保护的情况下，提供身份验证。ZRTP可以利用会话描述协议（SDP）属性通过信令信道提供发现和身份验证。为了提供尽力而为的SRTP，ZRTP利用了正常的RTP/AVP（视听配置文件）配置文件。ZRTP保护包括语音媒体流的媒体会话，还可以使用可选数字签名保护不包括语音的媒体会话。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6189.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6189.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
2. Terminology .....................................................5
3. Overview ........................................................6
3.1. Key Agreement Modes ........................................7
3.1.1. Diffie-Hellman Mode Overview ........................7
3.1.2. Preshared Mode Overview .............................9
3.1.3. Multistream Mode Overview ...........................9
4. Protocol Description ...........................................10
4.1. Discovery .................................................10
4.1.1. Protocol Version Negotiation .......................11
4.1.2. Algorithm Negotiation ..............................13
4.2. Commit Contention .........................................14
4.3. Matching Shared Secret Determination ......................15
4.3.1. Calculation and Comparison of Hashes of
Shared Secrets .....................................17
4.3.2. Handling a Shared Secret Cache Mismatch ............18
4.4. DH and Non-DH Key Agreements ..............................19
4.4.1. Diffie-Hellman Mode ................................19
4.4.1.1. Hash Commitment in Diffie-Hellman Mode ....20
4.4.1.2. Responder Behavior in
Diffie-Hellman Mode .......................21
4.4.1.3. Initiator Behavior in
Diffie-Hellman Mode .......................22
4.4.1.4. Shared Secret Calculation for DH Mode .....22
4.4.2. Preshared Mode .....................................25
4.4.2.1. Commitment in Preshared Mode ..............25
4.4.2.2. Initiator Behavior in Preshared Mode ......26
4.4.2.3. Responder Behavior in Preshared Mode ......26
4.4.2.4. Shared Secret Calculation for
Preshared Mode ............................27
1. Introduction ....................................................4
2. Terminology .....................................................5
3. Overview ........................................................6
3.1. Key Agreement Modes ........................................7
3.1.1. Diffie-Hellman Mode Overview ........................7
3.1.2. Preshared Mode Overview .............................9
3.1.3. Multistream Mode Overview ...........................9
4. Protocol Description ...........................................10
4.1. Discovery .................................................10
4.1.1. Protocol Version Negotiation .......................11
4.1.2. Algorithm Negotiation ..............................13
4.2. Commit Contention .........................................14
4.3. Matching Shared Secret Determination ......................15
4.3.1. Calculation and Comparison of Hashes of
Shared Secrets .....................................17
4.3.2. Handling a Shared Secret Cache Mismatch ............18
4.4. DH and Non-DH Key Agreements ..............................19
4.4.1. Diffie-Hellman Mode ................................19
4.4.1.1. Hash Commitment in Diffie-Hellman Mode ....20
4.4.1.2. Responder Behavior in
Diffie-Hellman Mode .......................21
4.4.1.3. Initiator Behavior in
Diffie-Hellman Mode .......................22
4.4.1.4. Shared Secret Calculation for DH Mode .....22
4.4.2. Preshared Mode .....................................25
4.4.2.1. Commitment in Preshared Mode ..............25
4.4.2.2. Initiator Behavior in Preshared Mode ......26
4.4.2.3. Responder Behavior in Preshared Mode ......26
4.4.2.4. Shared Secret Calculation for
Preshared Mode ............................27
4.4.3. Multistream Mode ...................................28
4.4.3.1. Commitment in Multistream Mode ............29
4.4.3.2. Shared Secret Calculation for
Multistream Mode ..........................29
4.5. Key Derivations ...........................................31
4.5.1. The ZRTP Key Derivation Function ...................31
4.5.2. Deriving ZRTPSess Key and SAS in DH or
Preshared Modes ....................................32
4.5.3. Deriving the Rest of the Keys from s0 ..............33
4.6. Confirmation ..............................................35
4.6.1. Updating the Cache of Shared Secrets ...............35
4.6.1.1. Cache Update Following a Cache Mismatch ...36
4.7. Termination ...............................................37
4.7.1. Termination via Error Message ......................37
4.7.2. Termination via GoClear Message ....................37
4.7.2.1. Key Destruction for GoClear Message .......39
4.7.3. Key Destruction at Termination .....................40
4.8. Random Number Generation ..................................40
4.9. ZID and Cache Operation ...................................41
4.9.1. Cacheless Implementations ..........................42
5. ZRTP Messages ..................................................42
5.1. ZRTP Message Formats ......................................44
5.1.1. Message Type Block .................................44
5.1.2. Hash Type Block ....................................45
5.1.2.1. Negotiated Hash and MAC Algorithm .........46
5.1.2.2. Implicit Hash and MAC Algorithm ...........47
5.1.3. Cipher Type Block ..................................47
5.1.4. Auth Tag Type Block ................................48
5.1.5. Key Agreement Type Block ...........................49
5.1.6. SAS Type Block .....................................51
5.1.7. Signature Type Block ...............................52
5.2. Hello Message .............................................53
5.3. HelloACK Message ..........................................56
5.4. Commit Message ............................................56
5.5. DHPart1 Message ...........................................60
5.6. DHPart2 Message ...........................................62
5.7. Confirm1 and Confirm2 Messages ............................63
5.8. Conf2ACK Message ..........................................66
5.9. Error Message .............................................66
5.10. ErrorACK Message .........................................68
5.11. GoClear Message ..........................................68
5.12. ClearACK Message .........................................69
5.13. SASrelay Message .........................................69
5.14. RelayACK Message .........................................72
5.15. Ping Message .............................................72
5.16. PingACK Message ..........................................73
6. Retransmissions ................................................74
4.4.3. Multistream Mode ...................................28
4.4.3.1. Commitment in Multistream Mode ............29
4.4.3.2. Shared Secret Calculation for
Multistream Mode ..........................29
4.5. Key Derivations ...........................................31
4.5.1. The ZRTP Key Derivation Function ...................31
4.5.2. Deriving ZRTPSess Key and SAS in DH or
Preshared Modes ....................................32
4.5.3. Deriving the Rest of the Keys from s0 ..............33
4.6. Confirmation ..............................................35
4.6.1. Updating the Cache of Shared Secrets ...............35
4.6.1.1. Cache Update Following a Cache Mismatch ...36
4.7. Termination ...............................................37
4.7.1. Termination via Error Message ......................37
4.7.2. Termination via GoClear Message ....................37
4.7.2.1. Key Destruction for GoClear Message .......39
4.7.3. Key Destruction at Termination .....................40
4.8. Random Number Generation ..................................40
4.9. ZID and Cache Operation ...................................41
4.9.1. Cacheless Implementations ..........................42
5. ZRTP Messages ..................................................42
5.1. ZRTP Message Formats ......................................44
5.1.1. Message Type Block .................................44
5.1.2. Hash Type Block ....................................45
5.1.2.1. Negotiated Hash and MAC Algorithm .........46
5.1.2.2. Implicit Hash and MAC Algorithm ...........47
5.1.3. Cipher Type Block ..................................47
5.1.4. Auth Tag Type Block ................................48
5.1.5. Key Agreement Type Block ...........................49
5.1.6. SAS Type Block .....................................51
5.1.7. Signature Type Block ...............................52
5.2. Hello Message .............................................53
5.3. HelloACK Message ..........................................56
5.4. Commit Message ............................................56
5.5. DHPart1 Message ...........................................60
5.6. DHPart2 Message ...........................................62
5.7. Confirm1 and Confirm2 Messages ............................63
5.8. Conf2ACK Message ..........................................66
5.9. Error Message .............................................66
5.10. ErrorACK Message .........................................68
5.11. GoClear Message ..........................................68
5.12. ClearACK Message .........................................69
5.13. SASrelay Message .........................................69
5.14. RelayACK Message .........................................72
5.15. Ping Message .............................................72
5.16. PingACK Message ..........................................73
6. Retransmissions ................................................74
7. Short Authentication String ....................................77
7.1. SAS Verified Flag .........................................78
7.2. Signing the SAS ...........................................79
7.2.1. OpenPGP Signatures .................................81
7.2.2. ECDSA Signatures with X.509v3 Certs ................82
7.2.3. Signing the SAS without a PKI ......................83
7.3. Relaying the SAS through a PBX ............................84
7.3.1. PBX Enrollment and the PBX Enrollment Flag .........87
8. Signaling Interactions .........................................89
8.1. Binding the Media Stream to the Signaling Layer
via the Hello Hash ........................................90
8.1.1. Integrity-Protected Signaling Enables
Integrity-Protected DH Exchange ....................92
8.2. Deriving the SRTP Secret (srtps) from the
Signaling Layer ...........................................93
8.3. Codec Selection for Secure Media ..........................94
9. False ZRTP Packet Rejection ....................................95
10. Intermediary ZRTP Devices .....................................97
11. The ZRTP Disclosure Flag ......................................98
11.1. Guidelines on Proper Implementation of the
Disclosure Flag .........................................100
12. Mapping between ZID and AOR (SIP URI) ........................100
13. IANA Considerations ..........................................102
14. Media Security Requirements ..................................102
15. Security Considerations ......................................104
15.1. Self-Healing Key Continuity Feature .....................107
16. Acknowledgments ..............................................108
17. References ...................................................109
17.1. Normative References ....................................109
17.2. Informative References ..................................111
7. Short Authentication String ....................................77
7.1. SAS Verified Flag .........................................78
7.2. Signing the SAS ...........................................79
7.2.1. OpenPGP Signatures .................................81
7.2.2. ECDSA Signatures with X.509v3 Certs ................82
7.2.3. Signing the SAS without a PKI ......................83
7.3. Relaying the SAS through a PBX ............................84
7.3.1. PBX Enrollment and the PBX Enrollment Flag .........87
8. Signaling Interactions .........................................89
8.1. Binding the Media Stream to the Signaling Layer
via the Hello Hash ........................................90
8.1.1. Integrity-Protected Signaling Enables
Integrity-Protected DH Exchange ....................92
8.2. Deriving the SRTP Secret (srtps) from the
Signaling Layer ...........................................93
8.3. Codec Selection for Secure Media ..........................94
9. False ZRTP Packet Rejection ....................................95
10. Intermediary ZRTP Devices .....................................97
11. The ZRTP Disclosure Flag ......................................98
11.1. Guidelines on Proper Implementation of the
Disclosure Flag .........................................100
12. Mapping between ZID and AOR (SIP URI) ........................100
13. IANA Considerations ..........................................102
14. Media Security Requirements ..................................102
15. Security Considerations ......................................104
15.1. Self-Healing Key Continuity Feature .....................107
16. Acknowledgments ..............................................108
17. References ...................................................109
17.1. Normative References ....................................109
17.2. Informative References ..................................111
ZRTP is a key agreement protocol that performs a Diffie-Hellman key exchange during call setup in the media path and is transported over the same port as the Real-time Transport Protocol (RTP) [RFC3550] media stream which has been established using a signaling protocol such as Session Initiation Protocol (SIP) [RFC3261]. This generates a shared secret, which is then used to generate keys and salt for a Secure RTP (SRTP) [RFC3711] session. ZRTP borrows ideas from [PGPfone]. A reference implementation of ZRTP is available in [Zfone].
ZRTP是一种密钥协议协议，在媒体路径中的呼叫设置期间执行Diffie-Hellman密钥交换，并通过与实时传输协议（RTP）[RFC3550]媒体流相同的端口进行传输，该媒体流已使用诸如会话发起协议（SIP）[RFC3261]等信令协议建立。这将生成一个共享密钥，然后用于为安全RTP（SRTP）[RFC3711]会话生成密钥和salt。ZRTP借鉴了[PGPfone]的思想。[Zfone]中提供了ZRTP的参考实现。
The ZRTP protocol has some nice cryptographic features lacking in many other approaches to media session encryption. Although it uses a public key algorithm, it does not rely on a public key infrastructure (PKI). In fact, it does not use persistent public keys at all. It uses ephemeral Diffie-Hellman (DH) with hash
ZRTP协议具有许多其他媒体会话加密方法所缺乏的一些良好的加密特性。虽然它使用公钥算法，但它不依赖公钥基础设施（PKI）。事实上，它根本不使用持久公钥。它使用短暂的Diffie-Hellman（DH）和散列
commitment and allows the detection of man-in-the-middle (MiTM) attacks by displaying a short authentication string (SAS) for the users to read and verbally compare over the phone. It has Perfect Forward Secrecy, meaning the keys are destroyed at the end of the call, which precludes retroactively compromising the call by future disclosures of key material. But even if the users are too lazy to bother with short authentication strings, we still get reasonable authentication against a MiTM attack, based on a form of key continuity. It does this by caching some key material to use in the next call, to be mixed in with the next call's DH shared secret, giving it key continuity properties analogous to Secure SHell (SSH). All this is done without reliance on a PKI, key certification, trust models, certificate authorities, or key management complexity that bedevils the email encryption world. It also does not rely on SIP signaling for the key management, and in fact, it does not rely on any servers at all. It performs its key agreements and key management in a purely peer-to-peer manner over the RTP packet stream.
承诺，并允许通过显示简短的身份验证字符串（SAS）供用户通过电话阅读和口头比较，从而检测中间人（MiTM）攻击。它具有完美的前向保密性，这意味着在通话结束时密钥会被销毁，这就排除了将来披露密钥材料对通话造成的追溯性损害。但是，即使用户懒得处理短的身份验证字符串，我们仍然可以基于某种形式的密钥连续性获得针对MiTM攻击的合理身份验证。它通过缓存一些在下一次调用中使用的密钥材料来实现这一点，并与下一次调用的DH shared secret混合在一起，为其提供类似于Secure SHell（SSH）的密钥连续性属性。所有这些都是在不依赖PKI、密钥认证、信任模型、证书颁发机构或困扰电子邮件加密世界的密钥管理复杂性的情况下完成的。它也不依赖SIP信令进行密钥管理，事实上，它根本不依赖任何服务器。它在RTP数据包流上以完全对等的方式执行其密钥协议和密钥管理。
ZRTP can be used and discovered without being declared or indicated in the signaling path. This provides a best effort SRTP capability. Also, this reduces the complexity of implementations and minimizes interdependency between the signaling and media layers. However, when ZRTP is indicated in the signaling via the zrtp-hash SDP attribute, ZRTP has additional useful properties. By sending a hash of the ZRTP Hello message in the signaling, ZRTP provides a useful binding between the signaling and media paths, which is explained in Section 8.1. When this is done through a signaling path that has end-to-end integrity protection, the DH exchange is automatically protected from a MiTM attack, which is explained in Section 8.1.1.
可以使用和发现ZRTP，而无需在信令路径中声明或指示。这提供了尽力而为的SRTP功能。此外，这降低了实现的复杂性，并最小化了信令层和媒体层之间的相互依赖性。但是，当通过ZRTP哈希SDP属性在信令中指示ZRTP时，ZRTP具有其他有用的属性。通过在信令中发送ZRTP Hello消息的散列，ZRTP在信令和媒体路径之间提供了有用的绑定，这在第8.1节中进行了解释。当通过具有端到端完整性保护的信令路径执行此操作时，DH交换机将自动受到保护，免受MiTM攻击，如第8.1.1节所述。
ZRTP is designed for unicast media sessions in which there is a voice media stream. For multiparty secure conferencing, separate ZRTP sessions may be negotiated between each party and the conference bridge. For sessions lacking a voice media stream, MiTM protection may be provided by the mechanisms in Sections 8.1.1 or 7.2. In terms of the RTP topologies defined in [RFC5117], ZRTP is designed for Point-to-Point topologies only.
ZRTP是为单播媒体会话设计的，其中有语音媒体流。对于多方安全会议，各方和会议桥之间可以协商单独的ZRTP会话。对于缺少语音媒体流的会话，可通过第8.1.1或7.2节中的机制提供MiTM保护。根据[RFC5117]中定义的RTP拓扑，ZRTP仅设计用于点对点拓扑。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
In this document, a "call" is synonymous with a "session".
在本文档中，“呼叫”是“会话”的同义词。
This section provides a description of how ZRTP works. This description is non-normative in nature but is included to build understanding of the protocol.
本节介绍ZRTP的工作原理。本说明本质上是非规范性的，但其目的是建立对本协议的理解。
ZRTP is negotiated the same way a conventional RTP session is negotiated in an offer/answer exchange using the standard RTP/AVP profile. The ZRTP protocol begins after two endpoints have utilized a signaling protocol, such as SIP, and are ready to exchange media. If Interactive Connectivity Establishment (ICE) [RFC5245] is being used, ZRTP begins after ICE has completed its connectivity checks.
ZRTP的协商方式与使用标准RTP/AVP配置文件在提供/应答交换中协商传统RTP会话的方式相同。ZRTP协议在两个端点使用了信令协议（如SIP）并准备好交换媒体后开始。如果正在使用交互式连接建立（ICE）[RFC5245]，则ZRTP将在ICE完成其连接检查后开始。
ZRTP is multiplexed on the same ports as RTP. It uses a unique header that makes it clearly differentiable from RTP or Session Traversal Utilities for NAT (STUN).
ZRTP在与RTP相同的端口上多路复用。它使用一个唯一的头，使其与RTP或NAT会话遍历实用程序（STUN）明显不同。
ZRTP support can be discovered in the signaling path by the presence of a ZRTP SDP attribute. However, even in cases where this is not received in the signaling, an endpoint can still send ZRTP Hello messages to see if a response is received. If a response is not received, no more ZRTP messages will be sent during this session. This is safe because ZRTP has been designed to be clearly different from RTP and have a similar structure to STUN packets received (sometimes by non-supporting endpoints) during an ICE exchange.
通过存在ZRTP SDP属性，可以在信令路径中发现ZRTP支持。然而，即使在信令中未接收到该消息的情况下，端点仍然可以发送ZRTP Hello消息以查看是否接收到响应。如果未收到响应，则在此会话期间将不再发送ZRTP消息。这是安全的，因为ZRTP被设计为明显不同于RTP，并且与ICE交换期间接收的STUN数据包（有时由非支持端点接收）具有类似的结构。
Both ZRTP endpoints begin the ZRTP exchange by sending a ZRTP Hello message to the other endpoint. The purpose of the Hello message is to confirm that the endpoint supports the protocol and to see what algorithms the two ZRTP endpoints have in common.
两个ZRTP端点通过向另一个端点发送ZRTP Hello消息来开始ZRTP交换。Hello消息的目的是确认端点支持该协议，并查看两个ZRTP端点的共同算法。
The Hello message contains the SRTP configuration options and the ZID. Each instance of ZRTP has a unique 96-bit random ZRTP ID or ZID that is generated once at installation time. ZIDs are discovered during the Hello message exchange. The received ZID is used to look up retained shared secrets from previous ZRTP sessions with the endpoint.
Hello消息包含SRTP配置选项和ZID。ZRTP的每个实例都有一个唯一的96位随机ZRTP ID或ZID，该ID或ZID在安装时生成一次。在Hello消息交换期间发现了zid。接收到的ZID用于从以前与端点的ZRTP会话中查找保留的共享机密。
A response to a ZRTP Hello message is a ZRTP HelloACK message. The HelloACK message simply acknowledges receipt of the Hello. Since RTP commonly uses best effort UDP transport, ZRTP has retransmission timers in case of lost datagrams. There are two timers, both with exponential backoff mechanisms. One timer is used for retransmissions of Hello messages and the other is used for retransmissions of all other messages after receipt of a HelloACK.
对ZRTP Hello消息的响应是ZRTP HelloACK消息。HelloACK消息只是确认收到Hello。由于RTP通常使用尽力而为的UDP传输，ZRTP在丢失数据报的情况下具有重传计时器。有两个计时器，都具有指数退避机制。一个计时器用于重传Hello消息，另一个用于在收到HelloACK后重传所有其他消息。
If an integrity-protected signaling channel is available, a hash of the Hello message can be sent. This allows rejection of false ZRTP Hello messages injected by an attacker.
如果完整性保护的信令通道可用，则可以发送Hello消息的散列。这允许拒绝攻击者注入的虚假ZRTP Hello消息。
Hello and other ZRTP messages also contain a hash image that is used to link the messages together. This allows rejection of false ZRTP messages injected during an exchange.
Hello和其他ZRTP消息还包含用于将消息链接在一起的哈希图像。这允许拒绝在交换期间注入的错误ZRTP消息。
After both endpoints exchange Hello and HelloACK messages, the key agreement exchange can begin with the ZRTP Commit message. ZRTP supports a number of key agreement modes including both Diffie-Hellman and non-Diffie-Hellman modes as described in the following sections.
在两个端点交换Hello和HelloACK消息之后，密钥协议交换可以从ZRTP Commit消息开始。ZRTP支持多种关键协议模式，包括Diffie-Hellman和non-Diffie-Hellman模式，如下节所述。
The Commit message may be sent immediately after both endpoints have completed the Hello/HelloACK discovery handshake, or it may be deferred until later in the call, after the participants engage in some unencrypted conversation. The Commit message may be manually activated by a user interface element, such as a GO SECURE button, which becomes enabled after the Hello/HelloACK discovery phase. This emulates the user experience of a number of secure phones in the Public Switched Telephone Network (PSTN) world [comsec]. However, it is expected that most simple ZRTP user agents will omit such buttons and proceed directly to secure mode by sending a Commit message immediately after the Hello/HelloACK handshake.
提交消息可以在两个端点完成Hello/HelloACK发现握手后立即发送，也可以在参与者参与一些未加密的对话后延迟到稍后的通话中。提交消息可以由用户界面元素（例如GO-SECURE按钮）手动激活，该按钮在Hello/HelloACK发现阶段之后启用。这模拟了公共交换电话网（PSTN）世界[comsec]中许多安全电话的用户体验。然而，预计大多数简单的ZRTP用户代理将省略此类按钮，并通过在Hello/HelloACK握手后立即发送提交消息直接进入安全模式。
An example ZRTP call flow is shown in Figure 1. Note that the order of the Hello/HelloACK exchanges in F1/F2 and F3/F4 may be reversed. That is, either Alice or Bob might send the first Hello message. Note that the endpoint that sends the Commit message is considered the initiator of the ZRTP session and drives the key agreement exchange. The Diffie-Hellman public values are exchanged in the DHPart1 and DHPart2 messages. SRTP keys and salts are then calculated.
图1显示了一个示例ZRTP调用流。注意，F1/F2和F3/F4中Hello/HelloACK交换的顺序可以颠倒。也就是说，Alice或Bob可能会发送第一条Hello消息。请注意，发送提交消息的端点被视为ZRTP会话的发起方，并驱动密钥协议交换。Diffie-Hellman公共值在DHPart1和DHPart2消息中交换。然后计算SRTP键和盐。
The initiator needs to generate its ephemeral key pair before sending the Commit, and the responder generates its key pair before sending DHPart1.
发起方需要在发送提交之前生成其临时密钥对，响应方在发送DHPart1之前生成其密钥对。
Alice Bob
| |
| Alice and Bob establish a media session. |
| They initiate ZRTP on media ports |
| |
| F1 Hello (version, options, Alice's ZID) |
|-------------------------------------------------->|
| HelloACK F2 |
|<--------------------------------------------------|
| Hello (version, options, Bob's ZID) F3 |
|<--------------------------------------------------|
| F4 HelloACK |
|-------------------------------------------------->|
| |
| Bob acts as the initiator. |
| |
| Commit (Bob's ZID, options, hash value) F5 |
|<--------------------------------------------------|
| F6 DHPart1 (pvr, shared secret hashes) |
|-------------------------------------------------->|
| DHPart2 (pvi, shared secret hashes) F7 |
|<--------------------------------------------------|
| |
| Alice and Bob generate SRTP session key. |
| |
| F8 Confirm1 (MAC, D,A,V,E flags, sig) |
|-------------------------------------------------->|
| Confirm2 (MAC, D,A,V,E flags, sig) F9 |
|<--------------------------------------------------|
| F10 Conf2ACK |
|-------------------------------------------------->|
| SRTP begins |
|<=================================================>|
| |
Alice Bob
| |
| Alice and Bob establish a media session. |
| They initiate ZRTP on media ports |
| |
| F1 Hello (version, options, Alice's ZID) |
|-------------------------------------------------->|
| HelloACK F2 |
|<--------------------------------------------------|
| Hello (version, options, Bob's ZID) F3 |
|<--------------------------------------------------|
| F4 HelloACK |
|-------------------------------------------------->|
| |
| Bob acts as the initiator. |
| |
| Commit (Bob's ZID, options, hash value) F5 |
|<--------------------------------------------------|
| F6 DHPart1 (pvr, shared secret hashes) |
|-------------------------------------------------->|
| DHPart2 (pvi, shared secret hashes) F7 |
|<--------------------------------------------------|
| |
| Alice and Bob generate SRTP session key. |
| |
| F8 Confirm1 (MAC, D,A,V,E flags, sig) |
|-------------------------------------------------->|
| Confirm2 (MAC, D,A,V,E flags, sig) F9 |
|<--------------------------------------------------|
| F10 Conf2ACK |
|-------------------------------------------------->|
| SRTP begins |
|<=================================================>|
| |
Figure 1: Establishment of an SRTP Session Using ZRTP
图1：使用ZRTP建立SRTP会话
ZRTP authentication uses a Short Authentication String (SAS), which is ideally displayed for the human user. Alternatively, the SAS can be authenticated by exchanging an optional digital signature (sig) over the SAS in the Confirm1 or Confirm2 messages (described in Section 7.2).
ZRTP身份验证使用一个短的身份验证字符串（SAS），理想情况下为人类用户显示。或者，可以通过在Confirm1或Confirm2消息（如第7.2节所述）中通过SAS交换可选数字签名（sig）对SAS进行身份验证。
The ZRTP Confirm1 and Confirm2 messages are sent for a number of reasons, not the least of which is that they confirm that all the key agreement calculations were successful and thus the encryption will work. They also carry other information such as the Disclosure flag (D), the Allow Clear flag (A), the SAS Verified flag (V), and the
发送ZRTP Confirm1和Confirm2消息的原因有很多，其中最重要的一个原因是它们确认所有密钥协议计算都成功，因此加密将工作。它们还携带其他信息，如披露标志（D）、允许清除标志（A）、SAS验证标志（V）和
Private Branch Exchange (PBX) Enrollment flag (E). All flags are encrypted to shield them from a passive observer.
专用交换机（PBX）注册标志（E）。所有标志都经过加密，以防止被动观察者看到它们。
In the Preshared mode, endpoints can skip the DH calculation if they have a shared secret from a previous ZRTP session. Preshared mode is indicated in the Commit message and results in the same call flow as Multistream mode. The principal difference between Multistream mode and Preshared mode is that Preshared mode uses a previously cached shared secret, rs1, instead of an active ZRTP Session key as the initial keying material.
在预共享模式下，如果端点具有来自先前ZRTP会话的共享密钥，则可以跳过DH计算。预共享模式在提交消息中指示，并产生与多流模式相同的调用流。多流模式和预共享模式之间的主要区别在于，预共享模式使用先前缓存的共享密钥rs1，而不是活动的ZRTP会话密钥作为初始密钥材料。
This mode could be useful for slow processor endpoints so that a DH calculation does not need to be performed every session. Or, this mode could be used to rapidly re-establish an earlier session that was recently torn down or interrupted without the need to perform another DH calculation.
此模式对于较慢的处理器端点可能很有用，因此不需要在每个会话中执行DH计算。或者，此模式可用于快速重新建立最近中断或中断的早期会话，而无需执行另一个DH计算。
Preshared mode has forward secrecy properties. If a phone's cache is captured by an opponent, the cached shared secrets cannot be used to recover earlier encrypted calls, because the shared secrets are replaced with new ones in each new call, as in DH mode. However, the captured secrets can be used by a passive wiretapper in the media path to decrypt the next call, if the next call is in Preshared mode. This differs from DH mode, which requires an active MiTM wiretapper to exploit captured secrets in the next call. However, if the next call is missed by the wiretapper, he cannot wiretap any further calls. Thus, it preserves most of the self-healing properties (Section 15.1) of key continuity enjoyed by DH mode.
预共享模式具有前向保密特性。如果对手捕获了手机的缓存，缓存的共享机密将无法用于恢复先前加密的通话，因为在每个新通话中，共享机密都会被替换为新的机密，就像在DH模式中一样。但是，如果下一个呼叫处于预共享模式，则媒体路径中的被动窃听器可以使用捕获的秘密对下一个呼叫进行解密。这与DH模式不同，DH模式要求活动的MiTM Wiretaper在下一次调用中利用捕获的秘密。但是，如果窃听者错过了下一个电话，他将无法窃听任何其他电话。因此，它保留了DH模式所享有的密钥连续性的大部分自愈特性（第15.1节）。
Multistream mode is an alternative key agreement method used when two endpoints have an established SRTP media stream between them with an active ZRTP Session key. ZRTP can derive multiple SRTP keys from a single DH exchange. For example, an established secure voice call that adds a video stream uses Multistream mode to quickly initiate the video stream without a second DH exchange.
当两个端点之间有一个已建立的SRTP媒体流，并且具有活动的ZRTP会话密钥时，多流模式是另一种密钥协商方法。ZRTP可以从单个DH交换派生多个SRTP密钥。例如，添加视频流的已建立安全语音呼叫使用多流模式快速启动视频流，而无需第二次DH交换。
When Multistream mode is indicated in the Commit message, a call flow similar to Figure 1 is used, but no DH calculation is performed by either endpoint and the DHPart1 and DHPart2 messages are omitted. The Confirm1, Confirm2, and Conf2ACK messages are still sent. Since the cache is not affected during this mode, multiple Multistream ZRTP exchanges can be performed in parallel between two endpoints.
当提交消息中指示多流模式时，将使用类似于图1的调用流，但任一端点都不执行DH计算，并且忽略DHPart1和DHPart2消息。Confirm1、Confirm2和Conf2ACK消息仍会发送。由于缓存在此模式下不受影响，因此可以在两个端点之间并行执行多个多流ZRTP交换。
When adding additional media streams to an existing call, only Multistream mode is used. Only one DH operation is performed, just for the first media stream.
向现有呼叫添加其他媒体流时，仅使用多流模式。仅对第一个媒体流执行一个DH操作。
This section begins the normative description of the protocol.
本节开始对协议进行规范性描述。
ZRTP MUST be multiplexed on the same ports as the RTP media packets.
ZRTP必须在与RTP媒体包相同的端口上多路复用。
To support best effort encryption from the Media Security Requirements [RFC5479], ZRTP uses normal RTP/AVP profile (AVP) media lines in the initial offer/answer exchange. The ZRTP SDP attribute a=zrtp-hash defined in Section 8 SHOULD be used in all offers and answers to indicate support for the ZRTP protocol.
为了支持媒体安全要求[RFC5479]中的尽力而为加密，ZRTP在初始报价/应答交换中使用普通RTP/AVP配置文件（AVP）媒体线路。第8节中定义的ZRTP SDP属性a=ZRTP哈希应用于所有报价和应答中，以表示对ZRTP协议的支持。
ZRTP can be utilized by endpoints that do not have a common signaling protocol but both support SRTP and are relying on a gateway for conversion. As such, it is not always possible for the signaling protocol to relay the zrtp-hash as can be done using SIP.
ZRTP可由没有公共信令协议但都支持SRTP且依赖网关进行转换的端点使用。因此，信令协议并不总是能够像使用SIP那样中继zrtp散列。
The Secure RTP/AVP (SAVP) profile MAY be used in subsequent offer/ answer exchanges after a successful ZRTP exchange has resulted in an SRTP session, or if it is known that the other endpoint supports this profile. Other profiles MAY also be used.
安全RTP/AVP（SAVP）配置文件可在成功的ZRTP交换产生SRTP会话后，或在已知其他端点支持此配置文件的情况下，在后续的提供/应答交换中使用。也可以使用其他配置文件。
The use of the RTP/SAVP profile has caused failures in negotiating best effort SRTP due to the limitations on negotiating profiles using SDP. This is why ZRTP supports the RTP/AVP profile and includes its own discovery mechanisms.
由于使用SDP协商配置文件的局限性，RTP/SAVP配置文件的使用导致了尽最大努力SRTP协商的失败。这就是ZRTP支持RTP/AVP配置文件并包含其自己的发现机制的原因。
In all key agreement modes, the initiator SHOULD NOT send RTP media after sending the Commit message, and it MUST NOT send SRTP media before receiving either the Conf2ACK or the first SRTP media (with a valid SRTP auth tag) from the responder. The responder SHOULD NOT send RTP media after receiving the Commit message, and MUST NOT send SRTP media before receiving the Confirm2 message.
在所有密钥协议模式下，发起方在发送提交消息后不应发送RTP介质，并且在从响应方接收Conf2ACK或第一个SRTP介质（带有有效的SRTP auth标记）之前，不得发送SRTP介质。响应程序在接收到提交消息后不应发送RTP介质，并且在接收到Confirm2消息之前不得发送SRTP介质。
During the ZRTP discovery phase, a ZRTP endpoint discovers if the other endpoint supports ZRTP and the supported algorithms and options. This information is transported in a Hello message, which is described in Section 5.2.
在ZRTP发现阶段，ZRTP端点会发现另一个端点是否支持ZRTP以及支持的算法和选项。该信息在Hello消息中传输，如第5.2节所述。
ZRTP endpoints SHOULD include the SDP attribute a=zrtp-hash in offers and answers, as defined in Section 8.
ZRTP端点应包括SDP属性a=ZRTP散列，如第8节所定义。
The Hello message includes the ZRTP version, Hash Type, Cipher Type, SRTP authentication tag type, Key Agreement Type, and Short Authentication String (SAS) algorithms that are supported. The Hello message also includes a hash image as described in Section 9. In addition, each endpoint sends and discovers ZIDs. The received ZID is used later in the protocol as an index into a cache of shared secrets that were previously negotiated and retained between the two parties.
Hello消息包括受支持的ZRTP版本、哈希类型、密码类型、SRTP身份验证标记类型、密钥协议类型和短身份验证字符串（SAS）算法。Hello消息还包括第9节中描述的散列图像。此外，每个端点发送和发现ZID。接收到的ZID稍后在协议中用作共享机密缓存的索引，该共享机密先前在双方之间协商和保留。
A Hello message can be sent at any time, but it is usually sent at the start of an RTP session to determine if the other endpoint supports ZRTP and also if the SRTP implementations are compatible. A Hello message is retransmitted using timer T1 and an exponential backoff mechanism detailed in Section 6 until the receipt of a HelloACK message or a Commit message.
Hello消息可以随时发送，但通常在RTP会话开始时发送，以确定其他端点是否支持ZRTP，以及SRTP实现是否兼容。在收到HelloACK消息或Commit消息之前，使用计时器T1和第6节中详述的指数退避机制重新传输Hello消息。
The use of the a=zrtp-hash SDP attribute to authenticate the Hello message is described in Section 8.1.
第8.1节介绍了使用a=zrtp hash SDP属性对Hello消息进行身份验证。
If a Hello message, or any other ZRTP message, indicates that there is a synchronization source (SSRC) collision, an Error message (Section 5.9) MUST be sent with the Error Code indicating SSRC collision, and the ZRTP negotiation MUST be terminated. The procedures of RFC 3550, Section 8.2 [RFC3550], SHOULD be followed by both endpoints to resolve this condition, and if it is resolved, a new ZRTP secure session SHOULD be negotiated.
如果Hello消息或任何其他ZRTP消息指示存在同步源（SSRC）冲突，则必须发送一条错误消息（第5.9节），其中包含指示SSRC冲突的错误代码，并且必须终止ZRTP协商。两个端点都应遵循RFC 3550第8.2节[RFC3550]的程序来解决此问题，如果问题得到解决，则应协商新的ZRTP安全会话。
This specification defines ZRTP version 1.10. Since new versions of ZRTP may be developed in the future, this specification defines a protocol version negotiation in this section.
本规范定义了ZRTP版本1.10。由于将来可能会开发新版本的ZRTP，本规范在本节中定义了协议版本协商。
Each party declares what version of the ZRTP protocol they support via the version field in the Hello message (Section 5.2). If both parties have the same version number in their Hello messages, they can proceed with the rest of the protocol. To facilitate both parties reaching this state of protocol version agreement in their Hello messages, ZRTP should use information provided in the signaling layer, if available. If a ZRTP endpoint supports more than one version of the protocol, it SHOULD declare them all in a list of SIP SDP a=zrtp-hash attributes (defined in Section 8), listing separate hashes, with separate ZRTP version numbers in each item in the list.
各方通过Hello消息（第5.2节）中的version字段声明其支持的ZRTP协议版本。如果双方在Hello消息中具有相同的版本号，则可以继续执行协议的其余部分。为了便于双方在Hello消息中达成协议版本协议状态，ZRTP应使用信令层提供的信息（如果可用）。如果ZRTP端点支持多个版本的协议，它应该在SIP SDP a=ZRTP哈希属性列表（在第8节中定义）中声明它们，列出单独的哈希，列表中的每个项目中都有单独的ZRTP版本号。
Both parties should inspect the list of ZRTP version numbers supplied by the other party in the SIP SDP a=zrtp-hash attributes. Both parties SHOULD choose the highest version number that appears in both parties' list of a=zrtp-hash version numbers, and use that version
双方应在SIP SDP a=ZRTP哈希属性中检查另一方提供的ZRTP版本号列表。双方应选择出现在双方a=zrtp哈希版本号列表中的最高版本号，并使用该版本
for their Hello messages. If both parties use the SIP signaling in this manner, their initial Hello messages will have the same ZRTP version number, provided they both have at least one supported protocol version in common. Before the ZRTP key agreement can proceed, an endpoint MUST have sent and received Hellos with the same protocol version.
为他们的问候留言。如果双方都以这种方式使用SIP信令，那么它们的初始Hello消息将具有相同的ZRTP版本号，前提是它们至少有一个共同的受支持协议版本。在ZRTP密钥协议可以继续之前，端点必须发送和接收具有相同协议版本的Hello。
It is best if the signaling layer is used to negotiate the protocol version number. However, the a=zrtp-hash SDP attribute is not always present in the SIP packet, as explained in Section 8.1. In the absence of any guidance from the signaling layer, an endpoint MUST send the highest supported version in initial Hello messages. If the two parties send different protocol version numbers in their Hello messages, they can reach an agreement to use a common version, if one exists. They iteratively apply the following rules until they both have matching version fields in their Hello messages and the key agreement can proceed:
最好使用信令层协商协议版本号。然而，如第8.1节所述，a=zrtp hash SDP属性并不总是存在于SIP数据包中。在没有来自信令层的任何指导的情况下，端点必须在初始Hello消息中发送受支持的最高版本。如果双方在Hello消息中发送不同的协议版本号，则可以达成协议，使用公共版本（如果存在）。他们反复应用以下规则，直到他们的Hello消息中都有匹配的版本字段，并且密钥协议可以继续：
o If an endpoint receives a Hello message with an unsupported version number that is higher than the endpoint's current Hello message version, the received Hello message MUST be ignored. The endpoint continues to retransmit Hello messages on the standard retry schedule (Section 6).
o 如果终结点接收到的Hello消息的版本号高于终结点当前Hello消息的版本号，则必须忽略接收到的Hello消息。端点继续按照标准重试计划重新传输Hello消息（第6节）。
o If an endpoint receives a Hello message with a version number that is lower than the endpoint's current Hello message, and the endpoint supports a version that is less than or equal to the received version number, the endpoint MUST stop retransmitting the old version number and MUST start sending a Hello message with the highest supported version number that is less than or equal to the received version number.
o 如果端点接收到版本号低于其当前Hello消息的Hello消息，并且该端点支持的版本号小于或等于接收到的版本号，端点必须停止重新传输旧版本号，并且必须开始发送支持的最高版本号小于或等于接收到的版本号的Hello消息。
o If an endpoint receives a Hello message with an unsupported version number that is lower than the endpoint's current Hello message, the endpoint MUST send an Error message (Section 5.9) indicating failure to support this ZRTP version.
o 如果端点收到的Hello消息的版本号低于其当前Hello消息的版本号，则该端点必须发送一条错误消息（第5.9节），指示无法支持此ZRTP版本。
The above comparisons are iterated until the version numbers match, or until it exits on a failure to match.
迭代上述比较，直到版本号匹配为止，或者直到匹配失败时退出为止。
For example, assume that Alice supports protocol versions 1.10 and 2.00, and Bob supports versions 1.10 and 1.20. Alice initially sends a Hello with version 2.00, and Bob initially sends a Hello with version 1.20. Bob ignores Alice's 2.00 Hello and continues to send his 1.20 Hellos. Alice detects that Bob does not support 2.00 and she stops sending her 2.00 Hellos and starts sending a stream of 1.10 Hellos. Bob sees the 1.10 Hello from Alice and stops sending his 1.20 Hellos and switches to sending 1.10 Hellos.
例如，假设Alice支持协议版本1.10和2.00，Bob支持版本1.10和1.20。Alice最初使用版本2.00发送Hello，Bob最初使用版本1.20发送Hello。鲍勃无视爱丽丝2点的问候，继续向她打1点20分的问候。Alice检测到Bob不支持2.00，她停止发送2.00 Hello，并开始发送1.10 Hello的流。Bob看到Alice发来的1.10 Hello，停止发送1.20 Hello，转而发送1.10 Hello。
At that point, they have converged on using version 1.10 and the protocol proceeds on that basis.
在这一点上，他们已经在使用版本1.10上取得了一致，协议也在这个基础上继续进行。
When comparing protocol versions, a ZRTP endpoint MUST include only the first three octets of the version field in the comparison. The final octet is ignored, because it is not significant for interoperability. For example, "1.1 ", "1.10", "1.11", or "1.1a" are all regarded as a version match, because they would all be interoperable versions.
比较协议版本时，ZRTP端点必须仅包括比较中版本字段的前三个八位字节。最后一个八位组被忽略，因为它对互操作性没有意义。例如，“1.1”、“1.10”、“1.11”或“1.1a”都被视为版本匹配，因为它们都是可互操作的版本。
Changes in protocol version numbers are expected to be infrequent after version 1.10. Supporting multiple versions adds code complexity and may introduce security weaknesses in the implementation. The old adage about keeping it simple applies especially to implementing security protocols. Endpoints SHOULD NOT support protocol versions earlier than version 1.10.
在版本1.10之后，协议版本号的更改预计不太频繁。支持多个版本会增加代码复杂性，并可能在实现中引入安全弱点。关于保持简单的古老格言尤其适用于实现安全协议。端点不应支持早于1.10版的协议版本。
A method is provided to allow the two parties to mutually and deterministically choose the same DH key size and algorithm before a Commit message is sent.
提供了一种方法，以允许双方在发送提交消息之前相互确定地选择相同的DH密钥大小和算法。
Each Hello message lists the algorithms in the order of preference for that ZRTP endpoint. Endpoints eliminate the non-intersecting choices from each of their own lists, resulting in each endpoint having a list of algorithms in common that might or might not be ordered the same as the other endpoint's list. Each endpoint compares the first item on their own list with the first item on the other endpoint's list and SHOULD choose the faster of the two algorithms. For example:
每个Hello消息都会按照ZRTP端点的首选顺序列出算法。端点从各自的列表中删除非相交选项，从而使每个端点都有一个共同的算法列表，这些算法的顺序可能与另一个端点的列表相同，也可能不同。每个端点将自己列表中的第一项与另一个端点列表中的第一项进行比较，并应选择两种算法中速度较快的一种。例如：
o Alice's full list: DH2k, DH3k, EC25
o Alice的完整列表：DH2k、DH3k、EC25
o Bob's full list: EC38, EC25, DH3k
o Bob的完整列表：EC38、EC25、DH3k
o Alice's intersecting list: DH3k, EC25
o 爱丽丝的交叉列表：DH3k，EC25
o Bob's intersecting list: EC25, DH3k
o Bob的交叉列表：EC25，DH3k
o Alice's first choice is DH3k, and Bob's first choice is EC25.
o Alice的首选是DH3k，Bob的首选是EC25。
o Thus, both parties choose EC25 (ECDH-256) because it's faster.
o 因此，双方都选择EC25（ECDH-256），因为它更快。
To decide which DH algorithm is faster, the following ranking, from fastest to slowest is defined: DH-2048, ECDH-256, DH-3072, ECDH-384, ECDH-521. These are all defined in Section 5.1.5.
为了确定哪个DH算法更快，定义了以下从最快到最慢的排名：DH-2048、ECDH-256、DH-3072、ECDH-384、ECDH-521。这些都在第5.1.5节中定义。
If both endpoints follow this method, they may each start their DH calculations as soon as they receive the Hello message, and there will be no need for either endpoint to discard their DH calculation if the other endpoint becomes the initiator.
如果两个端点都遵循此方法，则它们可以在收到Hello消息后立即开始各自的DH计算，并且如果另一个端点成为启动器，则任何一个端点都不需要放弃其DH计算。
This method is used only to negotiate DH key size. For the rest of the algorithm choices, it's simply whatever the initiator selects from the algorithms in common. Note that the DH key size influences the Hash Type and the size of the symmetric cipher key, as explained in Section 5.1.5.
此方法仅用于协商DH密钥大小。对于其余的算法选择，它只是发起者从共同的算法中选择的任何东西。请注意，DH密钥大小影响散列类型和对称密码密钥的大小，如第5.1.5节所述。
Unfavorable choices will never be made by this method, because each endpoint will omit from their respective lists choices that are too slow or not secure enough to meet their security policy.
这种方法永远不会做出不利的选择，因为每个端点都会从各自的列表中忽略速度太慢或安全性不足以满足其安全策略的选择。
After both parties have received compatible Hello messages, a Commit message (Section 5.4) can be sent to begin the ZRTP key exchange. The endpoint that sends the Commit is known as the initiator, while the receiver of the Commit is known as the responder.
双方收到兼容的Hello消息后，可以发送提交消息（第5.4节）以开始ZRTP密钥交换。发送提交的端点称为发起方，而提交的接收方称为响应方。
If both sides send Commit messages initiating a secure session at the same time, the following rules are used to break the tie:
如果双方同时发送发起安全会话的提交消息，则使用以下规则打破僵局：
o If one Commit is for a DH mode while the other is for Preshared mode, then the Preshared Commit MUST be discarded and the DH Commit proceeds.
o 如果一个提交用于DH模式，而另一个提交用于预共享模式，则必须放弃预共享提交，然后DH提交继续进行。
o If the two Commits are both Preshared mode, and one party has set the MiTM (M) flag in the Hello message and the other has not, the Commit message from the party who set the (M) flag MUST be discarded, and the one who has not set the (M) flag becomes the initiator, regardless of the nonce values. In other words, for Preshared mode, the phone is the initiator and the PBX is the responder.
o 如果两个提交都是预共享模式，并且一方在Hello消息中设置了MiTM（M）标志，而另一方未设置，则必须丢弃来自设置（M）标志的一方的提交消息，并且未设置（M）标志的一方将成为发起方，而不管nonce值如何。换句话说，对于预共享模式，电话是发起方，PBX是响应方。
o If the two Commits are either both DH modes or both non-DH modes, then the Commit message with the lowest hvi (hash value of initiator) value (for DH Commits), or lowest nonce value (for non-DH Commits), MUST be discarded and the other side is the initiator, and the protocol proceeds with the initiator's Commit. The two hvi or nonce values are compared as large unsigned integers in network byte order.
o 如果两个提交都是DH模式或非DH模式，则必须丢弃具有最低hvi（启动器的哈希值）值（对于DH提交）或最低nonce值（对于非DH提交）的提交消息，另一方是启动器，协议继续执行启动器的提交。两个hvi或nonce值作为网络字节顺序的大无符号整数进行比较。
If one Commit is for Multistream mode while the other is for non-Multistream (DH or Preshared) mode, a software error has occurred and the ZRTP negotiation should be terminated. This should never occur
如果一个提交用于多流模式，而另一个提交用于非多流（DH或预共享）模式，则发生软件错误，应终止ZRTP协商。这是不应该发生的
because of the constraints on Multistream mode described in Section 4.4.3.
由于第4.4.3节中描述的多流模式的限制。
In the event that Commit messages are sent by both ZRTP endpoints at the same time, but are received in different media streams, the same resolution rules apply as if they were received on the same stream. The media stream in which the Commit was received or sent will proceed through the ZRTP exchange while the media stream with the discarded Commit must wait for the completion of the other ZRTP exchange.
如果提交消息由两个ZRTP端点同时发送，但在不同的媒体流中接收，则应用相同的解析规则，就像它们在同一流中接收一样。接收或发送提交的媒体流将通过ZRTP交换继续，而丢弃提交的媒体流必须等待其他ZRTP交换完成。
If a commit contention forces a DH Commit message to be discarded, the responder's DH public value should only be discarded if it does not match the initiator's DH key size. This will not happen if both endpoints choose a common key size via the method described in Section 4.1.2.
如果提交争用强制丢弃DH commit消息，则仅当响应程序的DH public值与启动器的DH密钥大小不匹配时，才应丢弃响应程序的DH public值。如果两个端点通过第4.1.2节中描述的方法选择一个公共密钥大小，则不会发生这种情况。
The following sections describe how ZRTP endpoints generate and/or use the set of shared secrets s1, auxsecret, and pbxsecret through the exchange of the DHPart1 and DHPart2 messages. This doesn't cover the Diffie-Hellman calculations. It only covers the method whereby the two parties determine if they already have shared secrets in common in their caches.
以下各节描述ZRTP端点如何通过DHPart1和DHPart2消息的交换生成和/或使用共享机密s1、auxsecret和pbxsecret集。这不包括Diffie Hellman的计算。它仅涵盖双方确定其缓存中是否已经共享了共同秘密的方法。
Each ZRTP endpoint maintains a long-term cache of shared secrets that it has previously negotiated with the other party. The ZID of the other party, received in the other party's Hello message, is used as an index into this cache to find the set of shared secrets, if any exist. This cache entry may contain previously retained shared secrets, rs1 and rs2, which give ZRTP its key continuity features. If the other party is a PBX, the cache may also contain a trusted MiTM PBX shared secret, called pbxsecret, defined in Section 7.3.1.
每个ZRTP端点都维护一个共享机密的长期缓存，该缓存以前与另一方协商过。在另一方的Hello消息中接收到的另一方的ZID用作此缓存的索引，以查找共享机密集（如果存在）。此缓存项可能包含以前保留的共享机密rs1和rs2，这为ZRTP提供了关键的连续性功能。如果另一方是PBX，缓存还可能包含第7.3.1节中定义的受信任的MiTM PBX共享机密，称为pbxsecret。
The DHPart1 and DHPart2 messages contain a list of hashes of these shared secrets to allow the two endpoints to compare the hashes with what they have in their caches to detect whether the two sides share any secrets that can be used in the calculation of the session key. The use of this shared secret cache is described in Section 4.9.
DHPart1和DHPart2消息包含这些共享机密的哈希列表，以允许两个端点将哈希值与其缓存中的哈希值进行比较，以检测双方是否共享可用于会话密钥计算的任何机密。第4.9节介绍了该共享秘密缓存的使用。
If no secret of a given type is available, a random value is generated and used for that secret to ensure a mismatch in the hash comparisons in the DHPart1 and DHPart2 messages. This prevents an eavesdropper from knowing which types of shared secrets are available between the endpoints.
如果给定类型的机密不可用，将生成一个随机值并用于该机密，以确保DHPart1和DHPart2消息中的哈希比较不匹配。这可以防止窃听者知道端点之间存在哪些类型的共享机密。
Section 4.3.1 refers to the auxiliary shared secret auxsecret. The auxsecret shared secret may be defined by the VoIP user agent out-of-band from the ZRTP protocol. In some cases, it may be provided by the signaling layer as srtps, which is defined in Section 8.2. If it is not provided by the signaling layer, the auxsecret shared secret may be manually provisioned in other application-specific ways that are out of band, such as computed from a hashed pass phrase by prior agreement between the two parties or supplied by a hardware token. Or, it may be a family key used by an institution to which the two parties both belong. It is a generalized mechanism for providing a shared secret that is agreed to between the two parties out of scope of the ZRTP protocol. It is expected that most typical ZRTP endpoints will rarely use auxsecret.
第4.3.1节涉及辅助共享秘密auxsecret。auxsecret共享秘密可由VoIP用户代理从ZRTP协议带外定义。在某些情况下，它可以由信令层作为srtps提供，如第8.2节所定义。如果它不是由信令层提供的，则auxsecret共享秘密可以以带外的其他特定于应用的方式手动提供，例如通过双方之间的事先协议从散列密码短语计算或由硬件令牌提供。或者，它可能是双方都属于的机构使用的家庭密钥。它是一种通用的机制，用于提供双方在ZRTP协议范围外商定的共享秘密。预计大多数典型的ZRTP端点很少使用auxsecret。
For both the initiator and the responder, the shared secrets s1, s2, and s3 will be calculated so that they can all be used later to calculate s0 in Section 4.4.1.4. Here is how s1, s2, and s3 are calculated by both parties.
对于发起者和响应者，将计算共享机密s1、s2和s3，以便以后可以使用它们来计算第4.4.1.4节中的s0。以下是双方计算s1、s2和s3的方法。
The shared secret s1 will be either the initiator's rs1 or the initiator's rs2, depending on which of them can be found in the responder's cache. If the initiator's rs1 matches the responder's rs1 or rs2, then s1 MUST be set to the initiator's rs1. If and only if that match fails, then if the initiator's rs2 matches the responder's rs1 or rs2, then s1 MUST be set to the initiator's rs2. If that match also fails, then s1 MUST be set to null. The complexity of the s1 calculation is to recover from any loss of cache sync from an earlier aborted session, due to the Two Generals' Problem [Byzantine].
共享秘密s1将是发起方的rs1或发起方的rs2，这取决于在响应方的缓存中可以找到它们中的哪一个。如果启动器的rs1与响应程序的rs1或rs2匹配，则必须将s1设置为启动器的rs1。如果且仅当该匹配失败，则如果发起方的rs2与响应方的rs1或rs2匹配，则必须将s1设置为发起方的rs2。如果该匹配也失败，则s1必须设置为null。s1计算的复杂性在于，由于两位将军的问题[Byzantine]，从先前中止的会话中恢复任何缓存同步丢失。
The shared secret s2 MUST be set to the value of auxsecret if and only if both parties have matching values for auxsecret, as determined by comparing the hashes of auxsecret sent in the DH messages. If they don't match, s2 MUST be set to null.
当且仅当双方都有auxsecret的匹配值时，共享秘密s2必须设置为auxsecret的值，这是通过比较DH消息中发送的auxsecret的散列确定的。如果它们不匹配，s2必须设置为null。
The shared secret s3 MUST be set to the value of pbxsecret if and only if both parties have matching values for pbxsecret, as determined by comparing the hashes of pbxsecret sent in the DH messages. If they don't match, s3 MUST be set to null.
共享秘密s3必须设置为pbxsecret的值，当且仅当双方都有匹配的pbxsecret值时，这是通过比较DH消息中发送的pbxsecret的哈希值确定的。如果它们不匹配，s3必须设置为null。
If s1, s2, or s3 have null values, they are assumed to have a zero length for the purposes of hashing them later during the s0 calculation in Section 4.4.1.4.
如果s1、s2或s3具有空值，则假定其长度为零，以便在第4.4.1.4节s0计算期间对其进行散列。
The comparison of hashes of rs1, rs2, auxsecret, and pbxsecret is described in Section 4.3.1.
第4.3.1节描述了rs1、rs2、auxsecret和pbxsecret哈希的比较。
Both parties calculate a set of non-invertible hashes (implemented via the MAC defined in Section 5.1.2.1) of shared secrets that may be present in each of their caches. These hashes are truncated to the leftmost 64 bits:
双方计算可能存在于各自缓存中的共享秘密的一组不可逆散列（通过第5.1.2.1节中定义的MAC实现）。这些哈希被截断为最左边的64位：
rs1IDr = MAC(rs1, "Responder")
rs1IDr=MAC（rs1，“响应者”）
rs2IDr = MAC(rs2, "Responder")
rs2IDr=MAC（rs2，“响应者”）
auxsecretIDr = MAC(auxsecret, Responder's H3)
auxsecretIDr=MAC（auxsecret，响应者的H3）
pbxsecretIDr = MAC(pbxsecret, "Responder")
pbxsecretIDr=MAC（pbxsecret，“响应者”）
rs1IDi = MAC(rs1, "Initiator")
rs1IDi=MAC（rs1，“启动器”）
rs2IDi = MAC(rs2, "Initiator")
rs2IDi=MAC（rs2，“启动器”）
auxsecretIDi = MAC(auxsecret, Initiator's H3)
auxsecretIDi=MAC（auxsecret，发起者的H3）
pbxsecretIDi = MAC(pbxsecret, "Initiator")
pbxsecretIDi=MAC（pbxsecret，“启动器”）
The responder sends rs1IDr, rs2IDr, auxsecretIDr, and pbxsecretIDr in the DHPart1 message. The initiator sends rs1IDi, rs2IDi, auxsecretIDi, and pbxsecretIDi in the DHPart2 message.
响应程序在DHPart1消息中发送rs1IDr、rs2IDr、auxsecretIDr和pbxsecretIDr。启动器在DHPart2消息中发送rs1IDi、rs2IDi、auxsecretIDi和pbxsecretIDi。
The responder uses the locally computed rs1IDi, rs2IDi, auxsecretIDi, and pbxsecretIDi to compare against the corresponding fields in the received DHPart2 message. The initiator uses the locally computed rs1IDr, rs2IDr, auxsecretIDr, and pbxsecretIDr to compare against the corresponding fields in the received DHPart1 message.
响应程序使用本地计算的rs1IDi、rs2IDi、auxsecretIDi和pbxsecretIDi与接收到的DHPart2消息中的相应字段进行比较。启动器使用本地计算的rs1IDr、rs2IDr、auxsecretIDr和pbxsecretIDr与接收到的DHPart1消息中的相应字段进行比较。
From these comparisons, s1, s2, and s3 are calculated per the methods described in Section 4.3. The secrets corresponding to matching hashes are kept while the secrets corresponding to the non-matching ones are replaced with a null, which is assumed to have a zero length for the purposes of hashing them later. The resulting s1, s2, and s3 values are used later to calculate s0 in Section 4.4.1.4.
根据这些比较，s1、s2和s3按照第4.3节所述的方法进行计算。与匹配散列相对应的秘密将被保留，而与非匹配散列相对应的秘密将被替换为空值，该空值假定为零长度，以便稍后对其进行散列。所得s1、s2和s3值稍后用于计算第4.4.1.4节中的s0。
For example, consider two ZRTP endpoints who share secrets rs1 and pbxsecret (defined in Section 7.3.1). During the comparison, rs1ID and pbxsecretID will match but auxsecretID will not. As a result, s1 = rs1, s2 will be null, and s3 = pbxsecret.
例如，考虑两个共享秘密RS1和PBX机密的ZRTP端点（在7.3.1节中定义）。在比较过程中，rs1ID和pbxsecretID将匹配，但auxsecretID将不匹配。因此，s1=rs1，s2将为null，s3=pbxsecret。
A shared secret cache mismatch is defined to mean that we expected a cache match because rs1 exists in our local cache, but we computed a null value for s1 (per the method described in Section 4.3).
共享秘密缓存不匹配的定义是指我们期望缓存匹配，因为本地缓存中存在rs1，但我们为s1计算了空值（按照第4.3节中描述的方法）。
If one party has a cached shared secret and the other party does not, this indicates one of two possible situations. Either there is a MiTM attack or one of the legitimate parties has lost their cached shared secret by some mishap. Perhaps they inadvertently deleted their cache or their cache was lost or disrupted due to restoring their disk from an earlier backup copy. The party that has the surviving cache entry can easily detect that a cache mismatch has occurred, because they expect their own cached secret to match the other party's cached secret, but it does not match. It is possible for both parties to detect this condition if both parties have surviving cached secrets that have fallen out of sync, due perhaps to one party restoring from a disk backup.
如果一方拥有缓存的共享机密，而另一方没有，这表示两种可能的情况之一。要么是MiTM攻击，要么是某个合法方因某种意外事件丢失了其缓存的共享秘密。可能是他们无意中删除了缓存，或者由于从早期备份副本还原磁盘而导致缓存丢失或中断。拥有幸存缓存项的一方可以很容易地检测到缓存不匹配，因为他们希望自己的缓存机密与另一方的缓存机密匹配，但不匹配。如果双方都有可能由于一方从磁盘备份恢复而失去同步的剩余缓存机密，则双方都可能检测到这种情况。
If either party discovers a cache mismatch, the user agent who makes this discovery must treat this as a possible security event and MUST alert their own user that there is a heightened risk of a MiTM attack, and that the user should verbally compare the SAS with the other party to ascertain that no MiTM attack has occurred. If a cache mismatch is detected and it is not possible to compare the SAS, either because the user interface does not support it or because one or both endpoints are unmanned devices, and no other SAS comparison mechanism is available, the session MAY be terminated.
如果任何一方发现缓存不匹配，则进行此发现的用户代理必须将此视为可能的安全事件，并且必须提醒其自己的用户存在更高的MiTM攻击风险，并且用户应口头将SAS与另一方进行比较，以确定未发生MiTM攻击。如果检测到缓存不匹配，并且由于用户界面不支持SAS，或者由于一个或两个端点都是无人设备，并且没有其他可用的SAS比较机制，因此无法比较SAS，则可能会终止会话。
The session need not be terminated on a cache mismatch event if:
如果发生以下情况，则无需在缓存不匹配事件时终止会话：
o the mechanism described in Section 8.1.1 is available, which allows authentication of the DH exchange without human assistance, or
o 第8.1.1节所述的机制可用，允许在无需人工协助的情况下对DH交换进行认证，或
o any mechanism is available to determine if the SAS matches. This would require either circumstances that allow human verbal comparisons of the SAS or by use of the OPTIONAL digital signature feature on the SAS hash, as described in Section 7.2.
o 任何机制都可用于确定SAS是否匹配。这需要允许对SAS进行人工语言比较的情况，或者使用SAS哈希上的可选数字签名功能，如第7.2节所述。
Even if the user interface does not permit an SAS comparison, the human user MUST be warned and may elect to proceed with the call at their own risk.
即使用户界面不允许SAS比较，也必须警告人类用户，并可能选择继续调用，风险由他们自己承担。
If and only if a cache mismatch event occurs, the cache update mechanism in Section 4.6.1 is affected, requiring the user to verify the SAS before the cache is updated. The user will thus be alerted of this security condition on every call until the SAS is verified.
如果且仅当发生缓存不匹配事件时，第4.6.1节中的缓存更新机制才会受到影响，要求用户在更新缓存之前验证SAS。因此，在验证SAS之前，每次呼叫都会提醒用户此安全状况。
This is described in Section 4.6.1.1.
第4.6.1.1节对此进行了描述。
Here is a non-normative example of a cache-mismatch alert message from a ZRTP user agent (specifically, [Zfone]), designed for a desktop PC graphical user interface environment. It is by no means required that the alert be this detailed:
以下是一个非规范性示例，该示例显示了ZRTP用户代理（特别是[Zfone]）为桌面PC图形用户界面环境设计的缓存不匹配警报消息。绝对不要求警报如此详细：
We expected the other party to have a shared secret cached from a previous call, but they don't have it. This may mean your partner simply lost his cache of shared secrets, but it could also mean someone is trying to wiretap you. To resolve this question you must check the authentication string with your partner. If it doesn't match, it indicates the presence of a wiretapper.
我们希望另一方缓存来自上一次调用的共享机密，但他们没有。这可能意味着你的伴侣只是丢失了他共享的秘密，但也可能意味着有人试图窃听你。要解决此问题，必须与合作伙伴检查身份验证字符串。如果不匹配，则表示存在窃听器。
If the alert is rendered by a robot voice instead of a GUI, brevity may be more important:
如果警报由机器人语音而不是GUI呈现，则简洁可能更为重要：
Something's wrong. You must check the authentication string with your partner. If it doesn't match, it indicates the presence of a wiretapper.
有点不对劲。您必须与合作伙伴一起检查身份验证字符串。如果不匹配，则表示存在窃听器。
A mismatch of auxsecret is handled differently than a mismatch of rs1. An auxsecret mismatch is defined to mean that auxsecret exists locally, but we computed a null value for s2 (per the method described in Section 4.3). This mismatch should be made visible to whichever user has auxsecret defined. The mismatch should be made visible to both users if they both have auxsecret defined but they fail to match. The severity of the user notification is implementation dependent. Aborting the session is not required. If auxsecret matches, it should not excuse a mismatch of rs1, which still requires a strong warning to the user.
auxsecret的不匹配处理方式与rs1的不匹配处理方式不同。auxsecret失配被定义为意味着auxsecret局部存在，但我们计算了s2的空值（按照第4.3节中描述的方法）。无论用户定义了auxsecret，都应该可以看到这种不匹配。如果两个用户都定义了auxsecret，但没有匹配，那么应该使不匹配对两个用户都可见。用户通知的严重性取决于实现。不需要中止会话。如果auxsecret匹配，它不应该原谅rs1的不匹配，这仍然需要向用户发出强烈警告。
The next step is the generation of a secret for deriving SRTP keying material. ZRTP uses Diffie-Hellman and two non-Diffie-Hellman modes, described in the following subsections.
下一步是生成用于导出SRTP密钥材料的密钥。ZRTP使用Diffie-Hellman和两种非Diffie-Hellman模式，将在以下小节中介绍。
The purpose of the Diffie-Hellman (either Finite Field Diffie-Hellman or Elliptic Curve Diffie-Hellman) exchange is for the two ZRTP endpoints to generate a new shared secret, s0. In addition, the endpoints discover if they have any cached or previously stored shared secrets in common, and it uses them as part of the calculation of the session keys.
Diffie-Hellman（有限域Diffie-Hellman或椭圆曲线Diffie-Hellman）交换的目的是让两个ZRTP端点生成一个新的共享秘密s0。此外，端点会发现它们是否有任何缓存的或以前存储的共享机密，并将其用作会话密钥计算的一部分。
Because the DH exchange affects the state of the retained shared secret cache, only one in-process ZRTP DH exchange may occur at a time between two ZRTP endpoints. Otherwise, race conditions and cache integrity problems will result. When multiple media streams are established in parallel between the same pair of ZRTP endpoints (determined by the ZIDs in the Hello messages), only one can be processed. Once that exchange completes with Confirm2 and Conf2ACK messages, another ZRTP DH exchange can begin. This constraint does not apply when Multistream mode key agreement is used since the cached shared secrets are not affected.
由于DH交换会影响保留共享机密缓存的状态，因此两个ZRTP端点之间一次只能发生一个进程内ZRTP DH交换。否则，将导致竞争条件和缓存完整性问题。当在同一对ZRTP端点（由Hello消息中的ZID确定）之间并行建立多个媒体流时，只能处理一个媒体流。一旦使用Confirm2和Conf2ACK消息完成交换，另一个ZRTP DH交换就可以开始了。当使用多流模式密钥协议时，此约束不适用，因为缓存的共享机密不受影响。
From the intersection of the algorithms in the sent and received Hello messages, the initiator chooses a hash, cipher, auth tag, Key Agreement Type, and SAS Type to be used.
从发送和接收的Hello消息中算法的交叉点，发起方选择要使用的哈希、密码、身份验证标记、密钥协议类型和SAS类型。
A Diffie-Hellman mode is selected by setting the Key Agreement Type in the Commit to one of the DH or Elliptic Curve Diffie-Hellman (ECDH) values from the table in Section 5.1.5. In this mode, the key agreement begins with the initiator choosing a fresh random Diffie-Hellman (DH) secret value (svi) based on the chosen Key Agreement Type value, and computing the public value. (Note that to speed up processing, this computation can be done in advance.) For guidance on generating random numbers, see Section 4.8.
Diffie-Hellman模式是通过将提交中的密钥协议类型设置为第5.1.5节表格中的DH或椭圆曲线Diffie-Hellman（ECDH）值之一来选择的。在这种模式下，密钥协商开始于发起方基于所选密钥协商类型值选择新的随机Diffie-Hellman（DH）秘密值（svi），并计算公共值。（请注意，为了加快处理速度，可以提前完成此计算。）有关生成随机数的指导，请参阅第4.8节。
For Finite Field Diffie-Hellman, the value for the DH generator g, the DH prime p, and the length of the DH secret value, svi, are defined in Section 5.1.5.
对于有限域Diffie-Hellman，第5.1.5节定义了DH生成器g的值、DH素数p和DH秘密值的长度svi。
pvi = g^svi mod p
pvi=g^svi mod p
where g and p are determined by the Key Agreement Type value. The DH public value pvi value is formatted as a big-endian octet string and fixed to the bit-length of the DH prime; leading zeros MUST NOT be truncated.
其中g和p由密钥协议类型值确定。DH公共值pvi值被格式化为大端八进制字符串，并固定为DH素数的位长度；前导零不能被截断。
For Elliptic Curve DH, pvi is calculated and formatted according to the ECDH specification in Section 5.1.5, which refers in detail to certain sections of NIST SP 800-56A [NIST-SP800-56A].
对于椭圆曲线DH，根据第5.1.5节中的ECDH规范计算并格式化pvi，该规范详细参考了NIST SP 800-56A[NIST-SP800-56A]的某些章节。
The hash commitment is performed by the initiator of the ZRTP exchange. The hash value of the initiator, hvi, includes a hash of the entire DHPart2 message as shown in Figure 9 (which includes the Diffie-Hellman public value, pvi), and the responder's Hello message (where '||' means concatenation). The hvi hash is truncated to 256 bits:
哈希承诺由ZRTP交换的发起方执行。启动器hvi的散列值包括整个DHPart2消息的散列，如图9所示（其中包括Diffie-Hellman公共值pvi）和响应者的Hello消息（其中“| |”表示串联）。hvi哈希被截断为256位：
hvi = hash(initiator's DHPart2 message || responder's Hello message)
hvi=hash（发起者的DHPart2消息| |响应者的Hello消息）
Note that the Hello message includes the fields shown in Figure 3.
注意，Hello消息包括图3所示的字段。
The information from the responder's Hello message is included in the hash calculation to prevent a bid-down attack by modification of the responder's Hello message.
来自响应者的Hello消息的信息包含在哈希计算中，以通过修改响应者的Hello消息来防止出价下降攻击。
The initiator sends the hvi in the Commit message.
启动器在提交消息中发送hvi。
The use of hash commitment in the DH exchange constrains the attacker to only one guess to generate the correct Short Authentication String (SAS) (Section 7) in his attack, which means the SAS can be quite short. A 16-bit SAS, for example, provides the attacker only one chance out of 65536 of not being detected. Without this hash commitment feature, a MiTM attacker would acquire both the pvi and pvr public values from the two parties before having to choose his own two DH public values for his MiTM attack. He could then use that information to quickly perform a bunch of trial DH calculations for both sides until he finds two with a matching SAS. To raise the cost of this birthday attack, the SAS would have to be much longer. The Short Authentication String would have to become a Long Authentication String, which would be unacceptable to the user. A hash commitment precludes this attack by forcing the MiTM to choose his own two DH public values before learning the public values of either of the two parties.
DH exchange中使用哈希承诺限制攻击者仅猜测一次，以在其攻击中生成正确的短身份验证字符串（SAS）（第7节），这意味着SAS可能非常短。例如，16位SAS仅为攻击者提供65536个未被检测到的机会中的一个。如果没有此哈希承诺功能，MiTM攻击者将从双方获取pvi和pvr公共值，然后必须为其MiTM攻击选择自己的两个DH公共值。然后，他可以利用这些信息为双方快速执行一系列试验DH计算，直到找到两个匹配SAS。为了提高这次生日攻击的成本，SAS必须更长。短身份验证字符串必须变成长身份验证字符串，这对于用户来说是不可接受的。散列承诺通过强制MiTM在学习双方的公共值之前选择自己的两个DH公共值来阻止此攻击。
Upon receipt of the Commit message, the responder generates its own fresh random DH secret value, svr, and computes the public value. (Note that to speed up processing, this computation can be done in advance, with no need to discard this computation if both endpoints chose the same algorithm via Section 4.1.2.) For guidance on random number generation, see Section 4.8.
收到提交消息后，响应者生成自己的新随机DH秘密值svr，并计算公共值。（请注意，为了加快处理速度，可以提前完成此计算，如果两个端点通过第4.1.2节选择了相同的算法，则无需放弃此计算。）有关随机数生成的指导，请参阅第4.8节。
For Finite Field Diffie-Hellman, the value for the DH generator g, the DH prime p, and the length of the DH secret value, svr, are defined in Section 5.1.5.
对于有限域Diffie-Hellman，第5.1.5节定义了DH生成器g的值、DH素数p和DH秘密值的长度svr。
pvr = g^svr mod p
pvr=g^svr模块p
The pvr value is formatted as a big-endian octet string, fixed to the bit-length of the DH prime; leading zeros MUST NOT be truncated.
pvr值的格式为大端八位字符串，固定为DH素数的位长度；前导零不能被截断。
For Elliptic Curve DH, pvr is calculated and formatted according to the ECDH specification in Section 5.1.5, which refers in detail to certain sections of NIST SP 800-56A.
对于椭圆曲线DH，根据第5.1.5节中的ECDH规范计算并格式化pvr，该规范详细参考了NIST SP 800-56A的某些章节。
Upon receipt of the DHPart2 message, the responder checks that the initiator's DH public value is not equal to 1 or p-1. An attacker might inject a false DHPart2 message with a value of 1 or p-1 for g^svi mod p, which would cause a disastrously weak final DH result to be computed. If pvi is 1 or p-1, the user SHOULD be alerted of the attack and the protocol exchange MUST be terminated. Otherwise, the responder computes its own value for the hash commitment using the DH public value (pvi) received in the DHPart2 message and its own Hello message and compares the result with the hvi received in the Commit message. If they are different, a MiTM attack is taking place and the user is alerted and the protocol exchange terminated.
收到DHPart2消息后，响应者检查启动器的DH公共值是否不等于1或p-1。攻击者可能会为g^svi mod p注入一个值为1或p-1的虚假DHPart2消息，这将导致计算出极其微弱的最终DH结果。如果pvi为1或p-1，则应向用户发出攻击警报，并且必须终止协议交换。否则，响应者使用在DHPart2消息中接收的DH公共值（pvi）和其自己的Hello消息计算其自己的哈希承诺值，并将结果与在提交消息中接收的hvi进行比较。如果它们不同，则会发生MiTM攻击，并向用户发出警报，协议交换终止。
The responder then calculates the Diffie-Hellman result:
然后，响应者计算Diffie-Hellman结果：
DHResult = pvi^svr mod p
DHResult=pvi^svr mod p
Upon receipt of the DHPart1 message, the initiator checks that the responder's DH public value is not equal to 1 or p-1. An attacker might inject a false DHPart1 message with a value of 1 or p-1 for g^svr mod p, which would cause a disastrously weak final DH result to be computed. If pvr is 1 or p-1, the user should be alerted of the attack and the protocol exchange MUST be terminated.
收到DHPart1消息后，发起方检查响应方的DH公共值是否不等于1或p-1。攻击者可能会为g^svr mod p注入值为1或p-1的虚假DHPart1消息，这将导致计算出灾难性的弱最终DH结果。如果pvr为1或p-1，则应向用户发出攻击警报，并且必须终止协议交换。
The initiator then sends a DHPart2 message containing the initiator's DH public value and the set of calculated shared secret IDs as defined in Section 4.3.1.
然后，启动器发送一条DHPart2消息，其中包含启动器的DH公共值和第4.3.1节中定义的一组计算出的共享机密ID。
The initiator calculates the same Diffie-Hellman result using:
启动器使用以下公式计算相同的Diffie-Hellman结果：
DHResult = pvr^svi mod p
DHResult=pvr^svi模块p
A hash of the received and sent ZRTP messages in the current ZRTP exchange in the following order is calculated by both parties:
双方按照以下顺序计算当前ZRTP交换中接收和发送的ZRTP消息的散列：
total_hash = hash(Hello of responder || Commit || DHPart1 || DHPart2)
total_hash=hash（响应者的你好| |提交| | DHPart1 | | DHPart2）
Note that only the ZRTP messages (Figures 3, 5, 8, and 9), not the entire ZRTP packets, are included in the total_hash.
注意，只有ZRTP消息（图3、图5、图8和图9）而不是整个ZRTP数据包包含在total_散列中。
For both the initiator and responder, the DHResult is formatted as a big-endian octet string and fixed to the width of the DH prime; leading zeros MUST NOT be truncated. For example, for a 3072-bit p, DHResult would be a 384 octet value, with the first octet the most significant. DHResult may also be the result of an ECDH calculation, which is discussed in Section 5.1.5.
对于发起者和响应者，DHResult的格式为大端八位字节字符串，并固定为DH素数的宽度；前导零不能被截断。例如，对于3072位p，DHResult将是384个八位组的值，其中第一个八位组的有效性最高。DHResult也可能是第5.1.5节中讨论的ECDH计算结果。
Key | Size of
Agreement | DHResult
------------------------
DH-3072 | 384 octets
------------------------
DH-2048 | 256 octets
------------------------
ECDH P-256 | 32 octets
------------------------
ECDH P-384 | 48 octets
------------------------
Key | Size of
Agreement | DHResult
------------------------
DH-3072 | 384 octets
------------------------
DH-2048 | 256 octets
------------------------
ECDH P-256 | 32 octets
------------------------
ECDH P-384 | 48 octets
------------------------
The authors believe the calculation of the final shared secret, s0, is in compliance with the recommendations in Sections 5.8.1 and 6.1.2.1 of NIST SP 800-56A [NIST-SP800-56A]. This is done by hashing a concatenation of a number of items, including the DHResult, the ZID's of the initiator (ZIDi) and the responder (ZIDr), the total_hash, and the set of non-null shared secrets as described in Section 4.3.
作者认为，最终共享秘密s0的计算符合NIST SP 800-56A[NIST-SP800-56A]第5.8.1节和第6.1.2.1节中的建议。这是通过对许多项的串联进行散列来实现的，包括DHResult、发起方（ZDI）和响应方（ZDR）的ZID、total_散列和第4.3节所述的非空共享机密集。
In Section 5.8.1 of [NIST-SP800-56A], NIST requires certain parameters to be hashed together in a particular order, which NIST refers to as: Z, AlgorithmID, PartyUInfo, PartyVInfo, SuppPubInfo, and SuppPrivInfo. In our implementation, our DHResult corresponds to Z, "ZRTP-HMAC-KDF" corresponds to AlgorithmID, our ZIDi and ZIDr correspond to PartyUInfo and PartyVInfo, our total_hash corresponds to SuppPubInfo, and the set of three shared secrets s1, s2, and s3 corresponds to SuppPrivInfo. NIST also requires a 32-bit big-endian integer counter to be included in the hash each time the hash is computed, which we have set to the fixed value of 1 because we only compute the hash once. NIST refers to the final hash output as DerivedKeyingMaterial, which corresponds to our s0 in this calculation.
在[NIST-SP800-56A]第5.8.1节中，NIST要求按照特定顺序将某些参数散列在一起，NIST将其称为：Z、AlgorithmID、PartyInfo、PartyInfo、SuppPubInfo和SuppPrivInfo。在我们的实现中，我们的DHResult对应于Z，“ZRTP-HMAC-KDF”对应于AlgorithmID，我们的ZIDi和ZIDr对应于PartyInfo和PartyInfo，我们的total_散列对应于SuppPubInfo，三个共享秘密的集合s1、s2和s3对应于SuppPrivInfo。NIST还要求每次计算散列时都在散列中包含一个32位big-endian整数计数器，我们将其设置为固定值1，因为我们只计算一次散列。NIST将最终散列输出称为DerivedKeyingMaterial，它对应于本次计算中的s0。
s0 = hash(counter || DHResult || "ZRTP-HMAC-KDF" || ZIDi ||
ZIDr || total_hash || len(s1) || s1 || len(s2) ||
s2 || len(s3) || s3)
s0 = hash(counter || DHResult || "ZRTP-HMAC-KDF" || ZIDi ||
ZIDr || total_hash || len(s1) || s1 || len(s2) ||
s2 || len(s3) || s3)
Note that temporary values s1, s2, and s3 were calculated per the methods described in Section 4.3. DHResult, s1, s2, and s3 MUST all be erased from memory immediately after they are used to calculate s0.
请注意，临时值s1、s2和s3是按照第4.3节所述的方法计算的。DHResult、s1、s2和s3在用于计算s0后必须立即从内存中删除。
The length of the DHResult field was implicitly agreed to by the negotiated DH prime size. The length of total_hash is implicitly determined by the negotiated hash algorithm. All of the explicit length fields, len(), in the above hash are 32-bit big-endian integers, giving the length in octets of the field that follows. Some members of the set of shared secrets (s1, s2, and s3) may have lengths of zero if they are null (not shared) and are each preceded by a 4-octet length field. For example, if s2 is null, len(s2) is 0x00000000, and s2 itself would be absent from the hash calculation, which means len(s3) would immediately follow len(s2). While inclusion of ZIDi and ZIDr may be redundant, because they are implicitly included in the total_hash, we explicitly include them here to follow NIST SP 800-56A. The fixed-length string "ZRTP-HMAC-KDF" (not null-terminated) identifies for what purpose the resulting s0 will be used, which is to serve as the key derivation key for the ZRTP HMAC-based key derivation function (KDF) defined in Section 4.5.1 and used in Section 4.5.3.
DHResult字段的长度由协商的DH prime size隐式同意。总_散列的长度由协商散列算法隐式确定。上面散列中的所有显式长度字段len（）都是32位big-endian整数，表示后面字段的长度（以八位字节为单位）。如果共享机密集（s1、s2和s3）的某些成员为空（非共享），则它们的长度可能为零，并且每个成员前面都有一个4个八位字节的长度字段。例如，如果s2为null，len（s2）为0x00000000，并且s2本身将不在散列计算中，这意味着len（s3）将紧跟在len（s2）之后。虽然包含ZDI和ZDR可能是多余的，因为它们隐式地包含在total_散列中，我们在这里明确地包含它们，以遵循NIST SP 800-56A。固定长度字符串“ZRTP-HMAC-KDF”（不以null结尾）确定结果s0的用途，该s0将用作第4.5.1节中定义并在第4.5.3节中使用的基于ZRTP-HMAC的密钥派生函数（KDF）的密钥派生密钥。
The authors believe ZRTP DH mode is in full compliance with two relevant NIST documents that cover key derivations. First, Section 5.8.1 of [NIST-SP800-56A] computes what NIST refers to as DerivedKeyingMaterial, which ZRTP refers to as s0. This s0 then serves as the key derivation key, which NIST refers to as KI in the key derivation function described in Sections 5 and 5.1 of [NIST-SP800-108], to derive all the rest of the subkeys needed by ZRTP. For ECDH mode, the authors believe the s0 calculation is also in compliance with Section 3.1 of the National Security Agency's (NSA's) Suite B Implementer's Guide to NIST SP 800-56A [NSA-Suite-B-Guide-56A].
作者认为ZRTP DH模式完全符合两份涉及关键衍生产品的相关NIST文件。首先，[NIST-SP800-56A]第5.8.1节计算了NIST称之为衍生键控材料的材料，ZRTP称之为s0。然后，该s0用作密钥派生密钥，NIST在[NIST-SP800-108]第5节和第5.1节中描述的密钥派生函数中将其称为KI，以派生ZRTP所需的所有剩余子密钥。对于ECDH模式，作者认为s0计算也符合国家安全局（NSA）的NIST SP 800-56A套件B实施者指南第3.1节[NSA-Suite-B-Guide-56A]。
The ZRTP key derivation function (KDF) (Section 4.5.1) requires the use of a KDF Context field (per [NIST-SP800-108] guidelines), which should include the ZIDi, ZIDr, and a nonce value known to both parties. The total_hash qualifies as a nonce value, because its computation included nonce material from the initiator's Commit message and the responder's Hello message.
ZRTP密钥派生函数（KDF）（第4.5.1节）要求使用KDF上下文字段（根据[NIST-SP800-108]指南），其中应包括ZIDi、ZIDr和双方已知的nonce值。total_散列符合nonce值的条件，因为它的计算包括来自发起方的Commit消息和响应方的Hello消息的nonce内容。
KDF_Context = (ZIDi || ZIDr || total_hash)
KDF_Context = (ZIDi || ZIDr || total_hash)
At this point in DH mode, the two endpoints proceed to the key derivations of ZRTPSess and the rest of the keys in Section 4.5.2, now that there is a defined s0.
此时，在DH模式下，两个端点继续进行ZRTPSES的键派生，以及第4.5.2节中的其余键，现在已经定义了s0。
The Preshared key agreement mode can be used to generate SRTP keys and salts without a DH calculation, instead relying on a shared secret from previous DH calculations between the endpoints.
预共享密钥协商模式可用于生成SRTP密钥和SALT，而无需DH计算，而是依赖于来自端点之间先前DH计算的共享秘密。
This key agreement mode is useful to rapidly re-establish a secure session between two parties who have recently started and ended a secure session that has already performed a DH key agreement, without performing another lengthy DH calculation, which may be desirable on slow processors in resource-limited environments. Preshared mode MUST NOT be used for adding additional media streams to an existing call. Multistream mode MUST be used for this purpose.
此密钥协商模式有助于在最近启动和结束已执行DH密钥协商的安全会话的双方之间快速重新建立安全会话，而无需执行另一个冗长的DH计算，这在资源有限的环境中可能需要在较慢的处理器上进行。预共享模式不得用于向现有呼叫添加其他媒体流。为此，必须使用多流模式。
In the most severe resource-limited environments, Preshared mode may be useful with processors that cannot perform a DH calculation in an ergonomically acceptable time limit. Shared key material may be manually provisioned between two such endpoints in advance and still allow a limited subset of functionality. Such a "better than nothing" implementation would have to be regarded as non-compliant with the ZRTP specification, but it could interoperate in Preshared (and if applicable, Multistream) mode with a compliant ZRTP endpoint.
在最严重的资源受限环境中，预共享模式可能适用于无法在符合人体工程学的可接受时间限制内执行DH计算的处理器。共享密钥材料可以预先在两个这样的端点之间手动配置，并且仍然允许有限的功能子集。这种“总比没有好”的实现必须被视为不符合ZRTP规范，但它可以在预共享（以及如果适用，多流）模式下与兼容的ZRTP端点进行互操作。
Because Preshared mode affects the state of the retained shared secret cache, only one in-process ZRTP Preshared exchange may occur at a time between two ZRTP endpoints. This rule is explained in more detail in Section 4.4.1, and applies for the same reasons as in DH mode.
由于预共享模式会影响保留共享机密缓存的状态，因此两个ZRTP端点之间一次只能发生一次进程内ZRTP预共享交换。第4.4.1节对该规则进行了更详细的解释，其适用原因与DH模式相同。
Preshared mode is only included in this specification to meet the R-REUSE requirement in the Media Security Requirements [RFC5479] document. A series of preshared-keyed calls between two ZRTP endpoints should use a DH key exchange periodically. Preshared mode is only used if a cached shared secret has been established in an earlier session by a DH exchange, as discussed in Section 4.9.
预共享模式仅包含在本规范中，以满足媒体安全要求[RFC5479]文档中的R-重用要求。两个ZRTP端点之间的一系列预共享密钥调用应定期使用DH密钥交换。如第4.9节所述，仅当DH exchange在早期会话中建立了缓存共享机密时，才使用预共享模式。
Preshared mode is selected by setting the Key Agreement Type to Preshared in the Commit message. This results in the same call flow as Multistream mode. The principal difference between Multistream mode and Preshared mode is that Preshared mode uses a previously cached shared secret, rs1, instead of an active ZRTP Session key, ZRTPSess, as the initial keying material.
通过在提交消息中将密钥协议类型设置为“预共享”，可以选择预共享模式。这将产生与多流模式相同的调用流。多流模式和预共享模式之间的主要区别在于，预共享模式使用先前缓存的共享密钥rs1而不是活动的ZRTP会话密钥ZRTPSES作为初始密钥材料。
Preshared mode depends on having a reliable shared secret in its cache. Before Preshared mode is used, the initial DH exchange that gave rise to the shared secret SHOULD have used at least one of these
预共享模式取决于其缓存中是否有可靠的共享机密。在使用预共享模式之前，产生共享秘密的初始DH交换应该至少使用其中一种
anti-MiTM mechanisms: 1) A verbal comparison of the SAS, evidenced by the SAS Verified flag, or 2) an end-to-end integrity-protected delivery of the a=zrtp-hash in the signaling (Section 8.1.1), or 3) a digital signature on the sashash (Section 7.2).
反MiTM机制：1）SAS的口头比较，由SAS验证标志证明，或2）信令中A=zrtp散列的端到端完整性保护传递（第8.1.1节），或3）sashash上的数字签名（第7.2节）。
The Commit message (Figure 7) is sent by the initiator of the ZRTP exchange. From the intersection of the algorithms in the sent and received Hello messages, the initiator chooses a hash, cipher, auth tag, Key Agreement Type, and SAS Type to be used.
提交消息（图7）由ZRTP交换的启动器发送。从发送和接收的Hello消息中算法的交叉点，发起方选择要使用的哈希、密码、身份验证标记、密钥协议类型和SAS类型。
To assemble a Preshared commit, we must first construct a temporary preshared_key, which is constructed from one of several possible combinations of cached key material, depending on what is available in the shared secret cache. If rs1 is not available in the initiator's cache, then Preshared mode MUST NOT be used.
要组装预共享提交，我们必须首先构造一个临时预共享密钥，该密钥由缓存密钥材料的几种可能组合之一构造，具体取决于共享秘密缓存中的可用内容。如果rs1在启动器的缓存中不可用，则不得使用预共享模式。
preshared_key = hash(len(rs1) || rs1 || len(auxsecret) || auxsecret ||
len(pbxsecret) || pbxsecret)
preshared_key = hash(len(rs1) || rs1 || len(auxsecret) || auxsecret ||
len(pbxsecret) || pbxsecret)
All of the explicit length fields, len(), in the above hash are 32- bit big-endian integers, giving the length in octets of the field that follows. Some members of the set of shared secrets (rs1, auxsecret, and pbxsecret) may have lengths of zero if they are null (not available), and are each preceded by a 4-octet length field. For example, if auxsecret is null, len(auxsecret) is 0x00000000, and auxsecret itself would be absent from the hash calculation, which means len(pbxsecret) would immediately follow len(auxsecret).
上面散列中的所有显式长度字段len（）都是32位big-endian整数，给出后面字段的长度（以八位字节为单位）。共享机密集的某些成员（rs1、auxsecret和pbxsecret）如果为null（不可用），则其长度可能为零，并且每个成员前面都有一个4个八位字节的长度字段。例如，如果auxsecret为null，则len（auxsecret）为0x00000000，并且auxsecret本身将不在散列计算中，这意味着len（pbxsecret）将立即跟随len（auxsecret）。
In place of hvi in the Commit message, two smaller fields are inserted by the initiator:
启动器插入两个较小的字段来代替提交消息中的hvi：
- A random nonce of length 4 words (16 octets).
- 一种长度为4个字（16个八位字节）的随机时态。
- A keyID = MAC(preshared_key, "Prsh") truncated to 64 bits.
- 密钥ID=MAC（预共享密钥，“Prsh”）被截断为64位。
Note: Since the nonce is used to calculate different SRTP key and salt pairs for each session, a duplication will result in the same key and salt being generated for the two sessions, which would have disastrous security consequences.
注意：由于nonce用于为每个会话计算不同的SRTP密钥和salt对，因此重复将导致为两个会话生成相同的密钥和salt，这将产生灾难性的安全后果。
The responder uses the received keyID to search for matching key material in its cache. It does this by computing a preshared_key value and keyID value using the same formula as the initiator, depending on what is available in the responder's local cache. If
响应者使用收到的密钥ID在其缓存中搜索匹配的密钥材料。它通过使用与启动器相同的公式计算预共享的密钥值和密钥ID值来实现这一点，具体取决于响应程序的本地缓存中可用的内容。如果
the locally computed keyID does not match the received keyID in the Commit, the responder recomputes a new preshared_key and keyID from a different subset of shared keys from the cache, dropping auxsecret, pbxsecret, or both from the hash calculation, until a matching preshared_key is found or it runs out of possibilities. Note that rs2 is not included in the process.
本地计算的keyID与提交中接收到的keyID不匹配，响应程序从缓存中的不同共享密钥子集重新计算新的预共享密钥和keyID，从哈希计算中删除auxsecret、pbxsecret或两者，直到找到匹配的预共享密钥或其可能性耗尽。请注意，过程中不包括rs2。
If it finds the appropriate matching shared key material, it is used to derive s0 and a new ZRTPSess key, as described in the next section on shared secret calculation, Section 4.4.2.4.
如果找到合适的匹配共享密钥材料，将使用该材料导出s0和新的ZRTPSES密钥，如下一节共享密钥计算第4.4.2.4节所述。
If the responder determines that it does not have a cached shared secret from a previous DH exchange, or it fails to match the keyID hash from the initiator with any combination of its shared keys, it SHOULD respond with its own DH Commit message. This would reverse the roles and the responder would become the initiator, because the DH Commit must always "trump" the Preshared Commit message as described in Section 4.2. The key exchange would then proceed using DH mode. However, if a severely resource-limited responder lacks the computing resources to respond in a reasonable time with a DH Commit, it MAY respond with a ZRTP Error message (Section 5.9) indicating that no shared secret is available.
如果响应程序确定它没有来自先前DH交换的缓存共享密钥，或者它无法将来自启动器的keyID哈希与其共享密钥的任何组合匹配，那么它应该使用自己的DH Commit消息进行响应。这将颠倒角色，响应者将成为发起人，因为DH提交必须始终“胜过”第4.2节中描述的预共享提交消息。然后，密钥交换将使用DH模式进行。但是，如果资源严重受限的响应者缺乏计算资源，无法在合理的时间内响应DH Commit，则其可能会响应ZRTP错误消息（第5.9节），指示没有可用的共享机密。
If both sides send Preshared Commit messages initiating a secure session at the same time, the contention is resolved and the initiator/responder roles are settled according to Section 4.2, and the protocol proceeds.
如果双方同时发送发起安全会话的预共享提交消息，则根据第4.2节解决争用，并解决发起方/响应方角色，协议继续。
In Preshared mode, both the DHPart1 and DHPart2 messages are skipped. After receiving the Commit message from the initiator, the responder sends the Confirm1 message after calculating this stream's SRTP keys, as described below.
在预共享模式下，将跳过DHPart1和DHPart2消息。从发起方接收到提交消息后，响应方在计算该流的SRTP密钥后发送Confirm1消息，如下所述。
Preshared mode requires that the s0 and ZRTPSess keys be derived from the preshared_key, and this must be done in a way that guarantees uniqueness for each session. This is done by using nonce material from both parties: the explicit nonce in the initiator's Preshared Commit message (Figure 7) and the H3 field in the responder's Hello message (Figure 3). Thus, both parties force the resulting shared secret to be unique for each session.
预共享模式要求s0和ZRTPSES密钥从预共享_密钥派生，并且必须以保证每个会话唯一性的方式进行。这是通过使用双方的nonce材料来实现的：启动器的预共享提交消息中的显式nonce（图7）和响应者的Hello消息中的H3字段（图3）。因此，双方都强制生成的共享秘密对于每个会话都是唯一的。
A hash of the received and sent ZRTP messages in the current ZRTP exchange for the current media stream is calculated:
计算当前媒体流在当前ZRTP交换中接收和发送的ZRTP消息的散列：
total_hash = hash(Hello of responder || Commit)
total_hash=hash（响应者的你好| |提交）
Note that only the ZRTP messages (Figures 3 and 7), not the entire ZRTP packets, are included in the total_hash.
注意，只有ZRTP消息（图3和图7）而不是整个ZRTP数据包包含在total_散列中。
The ZRTP key derivation function (KDF) (Section 4.5.1) requires the use of a KDF Context field (per [NIST-SP800-108] guidelines), which should include the ZIDi, ZIDr, and a nonce value known to both parties. The total_hash qualifies as a nonce value, because its computation included nonce material from the initiator's Commit message and the responder's Hello message.
ZRTP密钥派生函数（KDF）（第4.5.1节）要求使用KDF上下文字段（根据[NIST-SP800-108]指南），其中应包括ZIDi、ZIDr和双方已知的nonce值。total_散列符合nonce值的条件，因为它的计算包括来自发起方的Commit消息和响应方的Hello消息的nonce内容。
KDF_Context = (ZIDi || ZIDr || total_hash)
KDF_Context = (ZIDi || ZIDr || total_hash)
The s0 key is derived via the ZRTP key derivation function (Section 4.5.1) from preshared_key and the nonces implicitly included in the total_hash. The nonces also ensure KDF_Context is unique for each session, which is critical for security.
s0密钥通过ZRTP密钥派生函数（第4.5.1节）从预共享的_密钥和总_散列中隐式包含的nonce派生而来。nonce还确保每个会话的KDF_上下文是唯一的，这对安全性至关重要。
s0 = KDF(preshared_key, "ZRTP PSK", KDF_Context, negotiated hash length)
s0=KDF（预共享密钥，“ZRTP PSK”，KDF_上下文，协商的哈希长度）
The preshared_key MUST be erased as soon as it has been used to calculate s0.
在使用预共享密钥计算s0后，必须立即擦除该密钥。
At this point in Preshared mode, the two endpoints proceed to the key derivations of ZRTPSess and the rest of the keys in Section 4.5.2, now that there is a defined s0.
此时，在预共享模式下，两个端点继续进行ZRTPSES的密钥派生，以及第4.5.2节中的其余密钥，现在已经定义了s0。
The Multistream key agreement mode can be used to generate SRTP keys and salts for additional media streams established between a pair of endpoints. Multistream mode cannot be used unless there is an active SRTP session established between the endpoints, which means a ZRTP Session key is active. This ZRTP Session key can be used to generate keys and salts without performing another DH calculation. In this mode, the retained shared secret cache is not used or updated. As a result, multiple ZRTP Multistream mode exchanges can be processed in parallel between two endpoints.
多流密钥协议模式可用于为在一对端点之间建立的附加媒体流生成SRTP密钥和SALT。除非在端点之间建立了活动的SRTP会话（这意味着ZRTP会话密钥处于活动状态），否则无法使用多流模式。此ZRTP会话密钥可用于生成密钥和SALT，而无需执行另一个DH计算。在此模式下，不使用或更新保留的共享机密缓存。因此，可以在两个端点之间并行处理多个ZRTP多流模式交换。
Multistream mode is also used to resume a secure call that has gone clear using a GoClear message as described in Section 4.7.2.1.
如第4.7.2.1节所述，多流模式还可用于恢复使用GoClear消息清除的安全呼叫。
When adding additional media streams to an existing call, Multistream mode MUST be used. The first media stream MUST use either DH mode or Preshared mode. Only one DH exchange or Preshared exchange is performed, just for the first media stream. The DH exchange or Preshared exchange MUST be completed for the first media stream before Multistream mode is used to add any other media streams. In a
向现有呼叫添加其他媒体流时，必须使用多流模式。第一个媒体流必须使用DH模式或预共享模式。仅针对第一媒体流执行一次DH交换或预共享交换。在使用多流模式添加任何其他媒体流之前，必须完成第一个媒体流的DH交换或预共享交换。在一个
Multistream session, a ZRTP endpoint MUST use the same ZID for all media streams, matching the ZID used in the first media stream.
在多流会话中，ZRTP端点必须对所有媒体流使用相同的ZID，与第一个媒体流中使用的ZID匹配。
Multistream mode is selected by the initiator setting the Key Agreement Type to "Mult" in the Commit message (Figure 6). The Cipher Type, Auth Tag Length, and Hash in Multistream mode SHOULD be set by the initiator to the same as the values as in the initial DH Mode Commit. The SAS Type is ignored as there is no SAS authentication in this mode.
多流模式是由启动器在提交消息中将密钥协议类型设置为“Mult”来选择的（图6）。发起程序应将多流模式下的密码类型、身份验证标记长度和哈希设置为与初始DH模式提交中的值相同。SAS类型被忽略，因为在此模式下没有SAS身份验证。
Note: This requirement is needed since some endpoints cannot support different SRTP algorithms for different media streams. However, in the case of Multistream mode being used to go secure after a GoClear, the requirement to use the same SRTP algorithms is relaxed if there are no other active SRTP sessions.
注意：由于某些端点不能为不同的媒体流支持不同的SRTP算法，因此需要此要求。但是，如果在GoClear之后使用多流模式来保护安全，则如果没有其他活动SRTP会话，则使用相同SRTP算法的要求将被放宽。
In place of hvi in the Commit, a random nonce of length 4 words (16 octets) is chosen. Its value MUST be unique for all nonce values chosen for active ZRTP sessions between a pair of endpoints. If a Commit is received with a reused nonce value, the ZRTP exchange MUST be immediately terminated.
在提交中，选择长度为4个字（16个八位字节）的随机nonce代替hvi。对于为一对端点之间的活动ZRTP会话选择的所有nonce值，其值必须是唯一的。如果使用重用的nonce值接收到提交，则必须立即终止ZRTP交换。
Note: Since the nonce is used to calculate different SRTP key and salt pairs for each media stream, a duplication will result in the same key and salt being generated for the two media streams, which would have disastrous security consequences.
注意：由于nonce用于为每个媒体流计算不同的SRTP密钥和salt对，因此复制将导致为两个媒体流生成相同的密钥和salt，这将产生灾难性的安全后果。
If a Commit is received selecting Multistream mode, but the responder does not have a ZRTP Session Key available, the exchange MUST be terminated. Otherwise, the responder proceeds to the next section on shared secret calculation, Section 4.4.3.2.
如果选择多流模式接收到提交，但响应程序没有可用的ZRTP会话密钥，则必须终止交换。否则，响应者进入下一节共享秘密计算，第4.4.3.2节。
If both sides send Multistream Commit messages at the same time, the contention is resolved and the initiator/responder roles are settled according to Section 4.2, and the protocol proceeds.
如果双方同时发送多流提交消息，则根据第4.2节解决争用，并解决发起方/响应方角色，协议继续。
In Multistream mode, both the DHPart1 and DHPart2 messages are skipped. After receiving the Commit message from the initiator, the responder sends the Confirm1 message after calculating this stream's SRTP keys, as described below.
在多流模式下，将跳过DHPart1和DHPart2消息。从发起方接收到提交消息后，响应方在计算该流的SRTP密钥后发送Confirm1消息，如下所述。
In Multistream mode, each media stream requires that a set of keys be derived from the ZRTPSess key, and this must be done in a way that guarantees uniqueness for each media stream. This is done by using
在多流模式下，每个媒体流都要求从ZRTPSES密钥派生一组密钥，并且必须以保证每个媒体流唯一性的方式来完成。这是通过使用
nonce material from both parties: the explicit nonce in the initiator's Multistream Commit message (Figure 6) and the H3 field in the responder's Hello message (Figure 3). Thus, both parties force the resulting shared secret to be unique for each media stream.
双方的nonce资料：发起方的多流提交消息（图6）中的显式nonce和响应方的Hello消息（图3）中的H3字段。因此，双方强制结果共享秘密对于每个媒体流是唯一的。
A hash of the received and sent ZRTP messages in the current ZRTP exchange for the current media stream is calculated:
计算当前媒体流在当前ZRTP交换中接收和发送的ZRTP消息的散列：
total_hash = hash(Hello of responder || Commit)
total_hash=hash（响应者的你好| |提交）
This refers to the Hello and Commit messages for the current media stream, which is using Multistream mode, not the original media stream that included a full DH key agreement. Note that only the ZRTP messages (Figures 3 and 6), not the entire ZRTP packets, are included in the hash.
这是指当前媒体流的Hello和Commit消息，该媒体流使用多流模式，而不是包含完整DH密钥协议的原始媒体流。注意，散列中只包括ZRTP消息（图3和图6），而不是整个ZRTP数据包。
The ZRTP key derivation function (KDF) (Section 4.5.1) requires the use of a KDF Context field (per [NIST-SP800-108] guidelines), which should include the ZIDi, ZIDr, and a nonce value known to both parties. The total_hash qualifies as a nonce value, because its computation included nonce material from the initiator's Commit message and the responder's Hello message.
ZRTP密钥派生函数（KDF）（第4.5.1节）要求使用KDF上下文字段（根据[NIST-SP800-108]指南），其中应包括ZIDi、ZIDr和双方已知的nonce值。total_散列符合nonce值的条件，因为它的计算包括来自发起方的Commit消息和响应方的Hello消息的nonce内容。
KDF_Context = (ZIDi || ZIDr || total_hash)
KDF_Context = (ZIDi || ZIDr || total_hash)
The current stream's SRTP keys and salts for the initiator and responder are calculated using the ZRTP Session Key ZRTPSess and the nonces implicitly included in the total_hash. The nonces also ensure that KDF_Context will be unique for each media stream, which is critical for security. For each additional media stream, a separate s0 is derived from ZRTPSess via the ZRTP key derivation function (Section 4.5.1):
使用ZRTP会话密钥ZRTPSES和包含在total_散列中的nonce来计算发起方和响应方的当前流的SRTP密钥和SALT。nonce还确保KDF_上下文对于每个媒体流都是唯一的，这对安全性至关重要。对于每个附加媒体流，通过ZRTP密钥派生功能从ZRTPSES派生出一个单独的s0（第4.5.1节）：
s0 = KDF(ZRTPSess, "ZRTP MSK", KDF_Context, negotiated hash length)
s0=KDF（ZRTPSES，“ZRTP MSK”，KDF_上下文，协商的哈希长度）
Note that the ZRTPSess key was previously derived from material that also includes a different and more inclusive total_hash from the entire packet sequence that performed the original DH exchange for the first media stream in this ZRTP session.
注意，ZRTPSES密钥先前是从还包括不同且更具包容性的total_散列的材料中派生出来的，该散列来自对该ZRTP会话中的第一媒体流执行原始DH交换的整个分组序列。
At this point in Multistream mode, the two endpoints begin key derivations in Section 4.5.3.
此时，在多流模式下，两个端点开始第4.5.3节中的关键推导。
To derive keys from a shared secret, ZRTP uses an HMAC-based key derivation function, or KDF. It is used throughout Section 4.5.3 and in other sections. The HMAC function for the KDF is based on the negotiated hash algorithm defined in Section 5.1.2.
为了从共享密钥派生密钥，ZRTP使用基于HMAC的密钥派生函数或KDF。在第4.5.3节和其他章节中使用。KDF的HMAC函数基于第5.1.2节中定义的协商哈希算法。
The authors believe the ZRTP KDF is in full compliance with the recommendations in NIST SP 800-108 [NIST-SP800-108]. Section 7.5 of the NIST document describes "key separation", which is a security requirement for the cryptographic keys derived from the same key derivation key. The keys shall be separate in the sense that the compromise of some derived keys will not degrade the security strength of any of the other derived keys or the security strength of the key derivation key. Strong preimage resistance is provided.
作者认为ZRTP KDF完全符合NIST SP 800-108[NIST-SP800-108]中的建议。NIST文件第7.5节描述了“密钥分离”，这是从同一密钥派生密钥派生的加密密钥的安全要求。密钥应分开，即某些衍生密钥的泄露不会降低任何其他衍生密钥的安全强度或密钥衍生密钥的安全强度。具有很强的抗预成像能力。
The ZRTP KDF runs the NIST pseudorandom function (PRF) in counter mode, with only a single iteration of the counter. The NIST PRF is based on the HMAC function. The ZRTP KDF never has to generate more than 256 bits (or 384 bits for Suite B applications) of output key material, so only a single invocation of the HMAC function is needed.
ZRTP KDF在计数器模式下运行NIST伪随机函数（PRF），只需对计数器进行一次迭代。NIST PRF基于HMAC功能。ZRTP KDF从不需要生成超过256位（对于套件B应用程序为384位）的输出密钥材料，因此只需调用一次HMAC函数。
The ZRTP KDF is defined in this manner, per Sections 5 and 5.1 of [NIST-SP800-108]:
根据[NIST-SP800-108]第5节和第5.1节，ZRTP KDF的定义如下：
KDF(KI, Label, Context, L) = HMAC(KI, i || Label || 0x00 || Context || L)
KDF（KI，Label，Context，L）=HMAC（KI，i | Label | 0x00 | Context | L）
The HMAC in the KDF is keyed by KI, which is a secret key derivation key that is unknown to the wiretapper (for example, s0). The HMAC is computed on a concatenated set of nonsecret fields that are defined as follows. The first field is a 32-bit big-endian integer counter (i) required by NIST to be included in the HMAC each time the HMAC is computed, which we have set to the fixed value of 0x000001 because we only compute the HMAC once. Label is a string of nonzero octets that identifies the purpose for the derived keying material. The octet 0x00 is a delimiter required by NIST. The NIST KDF formula has a "Context" field that includes ZIDi, ZIDr, and some optional nonce material known to both parties. L is a 32-bit big-endian positive integer, not to exceed the length in bits of the output of the HMAC. The output of the KDF is truncated to the leftmost L bits. If SHA-384 is the negotiated hash algorithm, the HMAC would be HMAC-SHA-384; thus, the maximum value of L would be 384, the negotiated hash length.
KDF中的HMAC由KI设置密钥，KI是一个秘密密钥派生密钥，有线窃听器不知道该密钥（例如s0）。HMAC是在一组串联的非保密字段上计算的，这些字段定义如下。第一个字段是NIST要求在每次计算HMAC时包含在HMAC中的32位大端整数计数器（i），我们将其设置为固定值0x000001，因为我们只计算一次HMAC。Label是一个非零八位字节字符串，用于标识派生键控材质的用途。八位字节0x00是NIST要求的分隔符。NIST KDF公式有一个“上下文”字段，其中包括ZIDi、ZIDr和双方已知的一些可选的nonce材料。L是32位大端正整数，不超过HMAC输出的位长度。KDF的输出被截断为最左边的L位。如果SHA-384是协商哈希算法，则HMAC将是HMAC-SHA-384；因此，L的最大值将是384，即协商的散列长度。
The ZRTP KDF is not to be confused with the SRTP KDF defined in [RFC3711].
ZRTP KDF不得与[RFC3711]中定义的SRTP KDF混淆。
Both DH mode and Preshared mode (but not Multistream mode) come to this common point in the protocol to derive ZRTPSess and the SAS from s0, via the ZRTP Key Derivation Function (Section 4.5.1). At this point, s0 has been calculated, as well as KDF_Context. These calculations are done only for the first media stream, not for Multistream mode.
DH模式和预共享模式（但不是多流模式）在协议中都达到了这个共同点，通过ZRTP密钥派生功能从s0派生ZRTPSES和SAS（第4.5.1节）。此时，已经计算了s0以及KDF_上下文。这些计算仅针对第一个媒体流进行，而不是针对多流模式。
The ZRTPSess key is used only for these two purposes: 1) to generate the additional s0 keys (Section 4.4.3.2) for adding additional media streams to this session in Multistream mode, and 2) to generate the pbxsecret (Section 7.3.1) that may be cached for use in future sessions. The ZRTPSess key is kept for the duration of the call signaling session between the two ZRTP endpoints. That is, if there are two separate calls between the endpoints (in SIP terms, separate SIP dialogs), then a ZRTP Session Key MUST NOT be used across the two call signaling sessions. ZRTPSess MUST be destroyed no later than the end of the call signaling session.
ZRTPSES密钥仅用于以下两个目的：1）生成额外的s0密钥（第4.4.3.2节），用于在多流模式下向该会话添加额外的媒体流；2）生成pbxsecret（第7.3.1节），该pbxsecret可缓存以在未来会话中使用。ZRTPSES密钥在两个ZRTP端点之间的呼叫信令会话期间保持不变。也就是说，如果端点之间有两个单独的呼叫（在SIP术语中，是单独的SIP对话框），则ZRTP会话密钥不得在两个呼叫信令会话之间使用。ZRTPSES必须在呼叫信令会话结束之前销毁。
ZRTPSess = KDF(s0, "ZRTP Session Key", KDF_Context, negotiated hash length)
ZRTPSES=KDF（s0，“ZRTP会话密钥”，KDF_上下文，协商的哈希长度）
Note that KDF_Context is unique for each media stream, but only the first media stream is permitted to calculate ZRTPSess.
请注意，KDF_上下文对于每个媒体流都是唯一的，但只允许第一个媒体流计算ZRTPSES。
There is only one Short Authentication String (SAS) (Section 7) computed per call, which is applicable to all media streams derived from a single DH key agreement in a ZRTP session. KDF_Context is unique for each media stream, but only the first media stream is permitted to calculate sashash.
每个调用只计算一个短认证字符串（SAS）（第7节），它适用于ZRTP会话中从单个DH密钥协议派生的所有媒体流。KDF_上下文对于每个媒体流都是唯一的，但只允许第一个媒体流计算sashash。
sashash = KDF(s0, "SAS", KDF_Context, 256)
sashash=KDF（s0，“SAS”，KDF_上下文，256）
sasvalue = sashash [truncated to leftmost 32 bits]
sasvalue=sashash[截断为最左边的32位]
Despite the exposure of the SAS to the two parties, the rest of the keying material is protected by the key separation properties of the KDF (Section 4.5.1).
尽管SAS暴露于双方，其余的键控材料仍受到KDF键控分离特性的保护（第4.5.1节）。
ZRTP-enabled VoIP clients may need to support additional forms of communication, such as text chat, instant messaging, or file transfers. These other forms of communication may need to be encrypted, and would benefit from leveraging the ZRTP key exchange used for the VoIP part of the call. In that case, more key material
支持ZRTP的VoIP客户端可能需要支持其他形式的通信，如文本聊天、即时消息或文件传输。这些其他形式的通信可能需要加密，并将受益于利用用于呼叫VoIP部分的ZRTP密钥交换。在这种情况下，更多的关键材料
MAY be derived and "exported" from the ZRTP protocol and provided as a shared secret to the VoIP client for these non-VoIP purposes. The application can use this exported key in application-specific ways, outside the scope of the ZRTP protocol.
可以从ZRTP协议派生和“导出”，并作为共享机密提供给VoIP客户端，用于这些非VoIP目的。应用程序可以在ZRTP协议范围之外，以特定于应用程序的方式使用此导出密钥。
ExportedKey = KDF(s0, "Exported key", KDF_Context, negotiated hash length)
ExportedKey=KDF（s0，“导出密钥”，KDF_上下文，协商的哈希长度）
Only one ExportedKey is computed per call. KDF_Context is unique for each media stream, but only the first media stream is permitted to calculate ExportedKey.
每次调用只计算一个ExportedKey。KDF_上下文对于每个媒体流都是唯一的，但只允许第一个媒体流计算ExportedKey。
The application may use this exported key to derive other subkeys for various non-ZRTP purposes, via a KDF using separate KDF label strings defined by the application. This key or its derived subkeys can be used for encryption, or used to authenticate other key exchanges carried out by the application, protected by ZRTP's MiTM defense umbrella. The exported key and its descendants may be used for as long as needed by the application, maintained in a separate crypto context that may outlast the VoIP session.
应用程序可以使用此导出的键，通过使用应用程序定义的单独KDF标签字符串的KDF，为各种非ZRTP目的派生其他子键。此密钥或其派生子密钥可用于加密，或用于验证应用程序执行的其他密钥交换，受ZRTP的MiTM保护伞保护。导出的密钥及其子代可以在应用程序需要的时间内使用，并在可能持续VoIP会话的单独加密上下文中维护。
At this point in DH mode or Preshared mode, the two endpoints proceed on to the key derivations in Section 4.5.3, now that there is a defined s0 and ZRTPSess key.
此时，在DH模式或预共享模式下，两个端点继续进行第4.5.3节中的密钥推导，现在已经定义了s0和ZRTPSES密钥。
DH mode, Multistream mode, and Preshared mode all come to this common point in the protocol to derive a set of keys from s0. It can be assumed that s0 has been calculated, as well the ZRTPSess key and KDF_Context. A separate s0 key is associated with each media stream.
DH模式、多流模式和预共享模式在协议中都达到这个共同点，以从s0导出一组密钥。可以假设已经计算了s0以及ZRTPSES密钥和KDF_上下文。单独的s0密钥与每个媒体流相关联。
Subkeys are not drawn directly from s0, as done in NIST SP 800-56A. To enhance key separation, ZRTP uses s0 to key a Key Derivation Function (Section 4.5.1) based on [NIST-SP800-108]. Since s0 already included total_hash in its derivation, it is redundant to use total_hash again in the KDF Context in all the invocations of the KDF keyed by s0. Nonetheless, NIST SP 800-108 always requires KDF Context to be defined for the KDF, and nonce material is required in some KDF invocations (especially for Multistream mode and Preshared mode), so total_hash is included as a nonce in the KDF Context.
如NIST SP 800-56A所述，子键不是直接从s0中提取的。为了增强密钥分离，ZRTP根据[NIST-SP800-108]使用s0为密钥派生函数（第4.5.1节）设置密钥。由于s0在其派生中已经包含total_hash，因此在s0键控的KDF的所有调用中，在KDF上下文中再次使用total_hash是多余的。尽管如此，NIST SP 800-108始终要求为KDF定义KDF上下文，并且某些KDF调用（特别是多流模式和预共享模式）中需要nonce材料，因此在KDF上下文中，total_hash作为nonce包含。
Separate SRTP master keys and master salts are derived for use in each direction for each media stream. Unless otherwise specified, ZRTP uses SRTP with no Master Key Identifier (MKI), 32-bit authentication using HMAC-SHA1, AES-CM 128 or 256-bit key length, 112-bit session salt key length, 2^48 key derivation rate, and SRTP prefix length 0. Secure RTCP (SRTCP) is also used, deriving the
为在每个媒体流的每个方向上使用，导出了单独的SRTP主密钥和主密钥。除非另有规定，ZRTP使用不带主密钥标识符（MKI）的SRTP、使用HMAC-SHA1的32位身份验证、AES-CM 128或256位密钥长度、112位会话盐密钥长度、2^48密钥派生率和SRTP前缀长度0。还使用了安全RTCP（SRTCP），从而导出
SRTCP keys from the same master keys and salts as SRTP, using the mechanisms specified in [RFC3711], without requiring a separate ZRTP negotiation for RTCP.
SRTCP密钥来自与SRTP相同的主密钥和盐，使用[RFC3711]中规定的机制，无需为RTCP进行单独的ZRTP协商。
The ZRTP initiator encrypts and the ZRTP responder decrypts packets by using srtpkeyi and srtpsalti, while the ZRTP responder encrypts and the ZRTP initiator decrypts packets by using srtpkeyr and srtpsaltr. The SRTP key and salt values are truncated (taking the leftmost bits) to the length determined by the chosen SRTP profile. These are generated by:
ZRTP启动器使用srtpkeyi和srtpsalti加密数据包，ZRTP响应程序解密数据包，而ZRTP响应程序使用srtpkeyr和srtpsaltr加密数据包，ZRTP启动器解密数据包。SRTP密钥和salt值被截断（取最左边的位）到所选SRTP配置文件确定的长度。这些数据由以下内容生成：
srtpkeyi = KDF(s0, "Initiator SRTP master key", KDF_Context, negotiated AES key length)
srtpkeyi=KDF（s0，“启动器SRTP主密钥”，KDF_上下文，协商的AES密钥长度）
srtpsalti = KDF(s0, "Initiator SRTP master salt", KDF_Context, 112)
srtpsalti=KDF（s0，“启动器SRTP主盐”，KDF_上下文，112）
srtpkeyr = KDF(s0, "Responder SRTP master key", KDF_Context, negotiated AES key length)
srtpkeyr=KDF（s0，“响应者SRTP主密钥”，KDF_上下文，协商的AES密钥长度）
srtpsaltr = KDF(s0, "Responder SRTP master salt", KDF_Context, 112)
srtpsaltr=KDF（s0，“响应者SRTP主盐”，KDF_上下文，112）
The MAC keys are the same length as the output of the underlying hash function in the KDF and are thus generated without truncation. They are used only by ZRTP and not by SRTP. Different MAC keys are needed for the initiator and the responder to ensure that GoClear messages in each direction are unique and can not be cached by an attacker and reflected back to the endpoint.
MAC密钥的长度与KDF中底层哈希函数的输出长度相同，因此生成时不会截断。它们仅由ZRTP使用，不由SRTP使用。发起方和响应方需要不同的MAC密钥，以确保每个方向上的GoClear消息都是唯一的，攻击者无法缓存这些消息并将其反射回端点。
mackeyi = KDF(s0, "Initiator HMAC key", KDF_Context, negotiated hash length)
mackeyi=KDF（s0，“启动器HMAC密钥”，KDF_上下文，协商的哈希长度）
mackeyr = KDF(s0, "Responder HMAC key", KDF_Context, negotiated hash length)
mackeyr=KDF（s0，“响应者HMAC密钥”，KDF_上下文，协商的哈希长度）
ZRTP keys are generated for the initiator and responder to use to encrypt the Confirm1 and Confirm2 messages. They are truncated to the same size as the negotiated SRTP key size.
ZRTP密钥是为启动器和响应程序生成的，用于加密Confirm1和Confirm2消息。它们被截断为与协商的SRTP密钥大小相同的大小。
zrtpkeyi = KDF(s0, "Initiator ZRTP key", KDF_Context, negotiated AES key length)
zrtpkeyi=KDF（s0，“启动器ZRTP密钥”，KDF_上下文，协商的AES密钥长度）
zrtpkeyr = KDF(s0, "Responder ZRTP key", KDF_Context, negotiated AES key length)
zrtpkeyr=KDF（s0，“响应者ZRTP密钥”，KDF_上下文，协商的AES密钥长度）
All key material is destroyed as soon as it is no longer needed, no later than the end of the call. s0 is erased in Section 4.6.1, and the rest of the session key material is erased in Sections 4.7.2.1 and 4.7.3.
所有关键材料在不再需要时立即销毁，不迟于通话结束。第4.6.1节删除s0，第4.7.2.1节和第4.7.3节删除会话密钥材料的其余部分。
The Confirm1 and Confirm2 messages (Figure 10) contain the cache expiration interval (defined in Section 4.9) for the newly generated retained shared secret. The flagoctet is an 8-bit unsigned integer made up of these flags: the PBX Enrollment flag (E) defined in Section 7.3.1, the SAS Verified flag (V) defined in Section 7.1, the Allow Clear flag (A) defined in Section 4.7.2, and the Disclosure flag (D) defined in Section 11.
Confirm1和Confirm2消息（图10）包含新生成的保留共享机密的缓存过期时间间隔（在第4.9节中定义）。flagoctet是由以下标志组成的8位无符号整数：第7.3.1节中定义的PBX注册标志（E）、第7.1节中定义的SAS验证标志（V）、第4.7.2节中定义的允许清除标志（A）以及第11节中定义的披露标志（D）。
flagoctet = (E * 2^3) + (V * 2^2) + (A * 2^1) + (D * 2^0)
flagoctet = (E * 2^3) + (V * 2^2) + (A * 2^1) + (D * 2^0)
Part of the Confirm1 and Confirm2 messages are encrypted using full-block Cipher Feedback Mode and contain a 128-bit random Cipher FeedBack (CFB) Initialization Vector (IV). The Confirm1 and Confirm2 messages also contain a MAC covering the encrypted part of the Confirm1 or Confirm2 message that includes a string of zeros, the signature length, flag octet, cache expiration interval, signature type block (if present), and signature (Section 7.2) (if present). For the responder:
部分Confirm1和Confirm2消息使用全分组密码反馈模式进行加密，并包含128位随机密码反馈（CFB）初始化向量（IV）。Confirm1和Confirm2消息还包含一个MAC，覆盖Confirm1或Confirm2消息的加密部分，该部分包括一串零、签名长度、标志八位字节、缓存过期间隔、签名类型块（如果存在）和签名（第7.2节）（如果存在）。对于响应者：
confirm_mac = MAC(mackeyr, encrypted part of Confirm1)
确认\u mac=mac（mackeyr，Confirm1的加密部分）
For the initiator:
对于发起人：
confirm_mac = MAC(mackeyi, encrypted part of Confirm2)
确认\u mac=mac（mackeyi，Confirm2的加密部分）
The mackeyi and mackeyr keys are computed in Section 4.5.3.
mackeyi和mackeyr键的计算见第4.5.3节。
The exchange is completed when the responder sends either the Conf2ACK message or the responder's first SRTP media packet (with a valid SRTP auth tag). The initiator MUST treat the first valid SRTP media from the responder as equivalent to receiving a Conf2ACK. The responder may respond to Confirm2 with either SRTP media, Conf2ACK, or both, in whichever order the responder chooses (or whichever order the "cloud" chooses to deliver them).
当响应者发送Conf2ACK消息或响应者的第一个SRTP媒体包（带有有效的SRTP auth标记）时，交换完成。发起者必须将来自响应者的第一个有效SRTP介质视为等同于接收Conf2ACK。响应者可以按照响应者选择的顺序（或“云”选择的交付顺序）使用SRTP媒体、Conf2ACK或两者来响应Confirm2。
After receiving the Confirm messages, both parties must now update their retained shared secret rs1 in their respective caches, provided the following conditions hold:
收到确认消息后，双方现在必须更新各自缓存中保留的共享机密rs1，前提是满足以下条件：
(1) This key exchange is either DH or Preshared mode, not Multistream mode, which does not update the cache.
(1) 此密钥交换是DH或预共享模式，而不是不更新缓存的多流模式。
(2) Depending on the values of the cache expiration intervals that are received in the two Confirm messages, there are some
(2) 根据在两条确认消息中接收到的缓存过期时间间隔的值，有一些
scenarios that do not update the cache, as explained in Section 4.9.
如第4.9节所述，不更新缓存的场景。
(3) The responder MUST receive the initiator's Confirm2 message before updating the responder's cache.
(3) 在更新响应程序的缓存之前，响应程序必须接收启动器的Confirm2消息。
(4) The initiator MUST receive either the responder's Conf2ACK message or the responder's SRTP media (with a valid SRTP auth tag) before updating the initiator's cache.
(4) 在更新启动器缓存之前，启动器必须接收响应程序的Conf2ACK消息或响应程序的SRTP介质（带有有效的SRTP auth标记）。
The cache update may also be affected by a cache mismatch, according to Section 4.6.1.1.
根据第4.6.1.1节，缓存更新也可能受到缓存不匹配的影响。
For DH mode only, before updating the retained shared secret rs1 in the cache, each party first discards their old rs2 and copies their old rs1 to rs2. The old rs1 is saved to rs2 because of the risk of session interruption after one party has updated his own rs1 but before the other party has enough information to update her own rs1. If that happens, they may regain cache sync in the next session by using rs2 (per Section 4.3). This mitigates the well-known Two Generals' Problem [Byzantine]. The old rs1 value is not saved in Preshared mode.
仅对于DH模式，在更新缓存中保留的共享机密rs1之前，各方首先丢弃其旧rs2，并将其旧rs1复制到rs2。旧的rs1保存到rs2，因为在一方更新了自己的rs1之后，但在另一方有足够的信息更新自己的rs1之前，存在会话中断的风险。如果发生这种情况，他们可能会在下一个会话中使用rs2重新获得缓存同步（根据第4.3节）。这缓解了众所周知的两位将军的问题[拜占庭]。旧的rs1值不会以预共享模式保存。
For DH mode and Preshared mode, both parties compute a new rs1 value from s0 via the ZRTP key derivation function (Section 4.5.1):
对于DH模式和预共享模式，双方通过ZRTP密钥推导函数从s0计算新的rs1值（第4.5.1节）：
rs1 = KDF(s0, "retained secret", KDF_Context, 256)
rs1=KDF（s0，“保留秘密”，KDF_上下文，256）
Note that KDF_Context is unique for each media stream, but only the first media stream is permitted to update rs1.
请注意，KDF_上下文对于每个媒体流都是唯一的，但只允许第一个媒体流更新rs1。
Each media stream has its own s0. At this point in the protocol for each media stream, the corresponding s0 MUST be erased.
每个媒体流都有自己的s0。在每个媒体流的协议中，此时必须擦除相应的s0。
If a shared secret cache mismatch (as defined in Section 4.3.2) is detected in the current session, it indicates a possible MiTM attack. However, there may be evidence to the contrary, if either one of the following conditions are met:
如果在当前会话中检测到共享机密缓存不匹配（如第4.3.2节所定义），则表示可能存在MiTM攻击。但是，如果满足以下任一条件，则可能有相反的证据：
o Successful use of the mechanism described in Section 8.1.1, but only if fully supported by end-to-end integrity-protected delivery of the a=zrtp-hash in the signaling via SIP Identity [RFC4474] or better still, Dan Wing's SIP Identity using Media Path [SIP-IDENTITY]. This allows authentication of the DH exchange without human assistance.
o 成功使用第8.1.1节中所述的机制，但仅在通过SIP标识[RFC4474]或更好的方式，Dan Wing使用媒体路径[SIP-Identity]的SIP标识在信令中的a=zrtp散列的端到端完整性保护交付完全支持的情况下。这允许在无需人工协助的情况下对DH exchange进行身份验证。
o A good signature is received and verified using the digital signature feature on the SAS hash, as described in Section 7.2, if this feature is supported.
o 如第7.2节所述，如果支持此功能，则使用SAS哈希上的数字签名功能接收并验证良好的签名。
If there is a cache mismatch in the absence of the aforementioned mitigating evidence, the cache update MUST be delayed in the current session until the user verbally compares the SAS with his partner during the call and confirms a successful SAS verify via his user interface as described in Section 7.1. If the session ends before that happens, the cache update is not performed, leaving the rs1/rs2 values unmodified in the cache. Regardless of whether a cache mismatch occurs, s0 must still be erased.
如果在没有上述缓解证据的情况下存在缓存不匹配，则必须在当前会话中延迟缓存更新，直到用户在通话期间口头比较SAS与其合作伙伴，并通过第7.1节所述的用户界面确认SAS验证成功。如果会话在此之前结束，则不会执行缓存更新，从而在缓存中保留未修改的rs1/rs2值。无论是否发生缓存不匹配，s0都必须被擦除。
If no cache entry exists, as is the case in the initial call, the cache update is handled in the normal fashion.
如果不存在缓存项（如初始调用中的情况），则以正常方式处理缓存更新。
A ZRTP session is normally terminated at the end of a call, but it may be terminated early by either the Error message or the GoClear message.
ZRTP会话通常在呼叫结束时终止，但也可能因错误消息或GoClear消息而提前终止。
The Error message (Section 5.9) is used to terminate an in-progress ZRTP exchange due to an error. The Error message contains an integer Error Code for debugging purposes. The termination of a ZRTP key agreement exchange results in no updates to the cached shared secrets and deletion of all crypto context for that media stream. The ZRTP Session key, ZRTPSess, is only deleted if all ZRTP media streams that are using it are terminated.
错误消息（第5.9节）用于因错误而终止正在进行的ZRTP交换。错误消息包含用于调试的整数错误代码。ZRTP密钥协议交换的终止不会更新缓存的共享机密，也不会删除该媒体流的所有加密上下文。ZRTP会话密钥ZRTPSES只有在所有使用它的ZRTP媒体流终止时才会被删除。
Because no key agreement has been reached, the Error message cannot use the same MAC protection as the GoClear message. A denial of service is possible by injecting fake Error messages. (However, even if the Error message were somehow designed with integrity protection, it would raise other questions. What would a badly formed Error message mean if it were sent to report a badly formed message? A good message?)
由于未达成密钥协议，错误消息不能使用与GoClear消息相同的MAC保护。通过注入虚假错误消息，可以拒绝服务。（但是，即使错误消息以某种方式设计为具有完整性保护，也会引发其他问题。如果发送错误消息以报告格式错误的消息，则错误消息意味着什么？好消息？）
The GoClear message (Section 5.11) is used to switch from SRTP to RTP, usually because the user has chosen to do that by pressing a button. The GoClear uses a MAC of the Message Type Block sent in the GoClear message computed with the mackey derived from the shared secret. This MAC is truncated to the leftmost 64 bits. When sent by the initiator:
GoClear消息（第5.11节）用于从SRTP切换到RTP，通常是因为用户已选择通过按下按钮进行切换。GoClear使用GoClear消息中发送的消息类型块的MAC，该消息类型块使用从共享机密派生的mackey进行计算。此MAC被截断为最左边的64位。由启动器发送时：
clear_mac = MAC(mackeyi, "GoClear ")
清除（mackeyi，GoClear）
When sent by the responder:
由响应者发送时：
clear_mac = MAC(mackeyr, "GoClear ")
清除（mackeyr，“GoClear”）
Both of these MACs are calculated across the 8-octet "GoClear " Message Type Block, including the trailing space.
这两个MAC都是通过8个八位字节的“GoClear”消息类型块（包括尾随空格）计算的。
A GoClear message that does not receive a ClearACK response must be resent. If a GoClear message is received with a bad MAC, ClearACK MUST NOT be sent and the GoClear MUST NOT be acted on by the recipient, but it MAY be processed as a security exception, perhaps by logging or alerting the user.
必须重新发送未收到ClearACK响应的GoClear消息。如果收到带有坏MAC的GoClear消息，则不得发送ClearACK，接收者不得对GoClear采取行动，但可将其作为安全异常处理，可能通过记录或提醒用户。
A ZRTP endpoint MAY choose to accept GoClear messages after the session has switched to SRTP, allowing the session to revert to RTP. This is indicated in the Confirm1 or Confirm2 messages (Figure 10) by setting the Allow Clear flag (A). If an endpoint sets the Allow Clear (A) flag in their Confirm message, it indicates that they support receiving GoClear messages.
ZRTP端点可以选择在会话切换到SRTP后接受GoClear消息，从而允许会话恢复到RTP。这在Confirm1或Confirm2消息（图10）中通过设置允许清除标志（A）来指示。如果端点在其确认消息中设置了允许清除（A）标志，则表示它们支持接收GoClear消息。
A ZRTP endpoint that receives a GoClear MUST authenticate the message by checking the clear_mac. If the message authenticates, the endpoint stops sending SRTP packets, and generates a ClearACK in response. It MUST also delete all the crypto key material for all the SRTP media streams, as defined in Section 4.7.2.1.
接收GoClear的ZRTP端点必须通过检查clear_mac对消息进行身份验证。如果消息经过身份验证，端点将停止发送SRTP数据包，并生成ClearACK作为响应。还必须删除第4.7.2.1节中定义的所有SRTP媒体流的所有加密密钥材料。
Until confirmation from the user is received (e.g., clicking a button, pressing a dual-tone multi-frequency (DTMF) key, etc.), the ZRTP endpoint MUST NOT resume sending RTP packets. The endpoint then renders to the user an indication that the media session has switched to clear mode and waits for confirmation from the user. This blocks the flow of sensitive discourse until the user is forced to take notice that he's no longer protected by encryption. To prevent pinholes from closing or NAT bindings from expiring, the ClearACK message MAY be resent at regular intervals (e.g., every 5 seconds) while waiting for confirmation from the user. After confirmation of the notification is received from the user, the sending of RTP packets may begin.
在收到用户的确认（例如，单击按钮、按双音多频（DTMF）键等）之前，ZRTP端点不得恢复发送RTP数据包。然后，端点向用户呈现媒体会话已切换到清除模式的指示，并等待用户确认。这会阻止敏感信息的传播，直到用户被迫注意到他不再受加密保护。为了防止针孔关闭或NAT绑定过期，在等待用户确认时，可以定期（例如，每5秒）重新发送ClearACK消息。在从用户接收到通知的确认之后，可以开始发送RTP分组。
After sending a GoClear message, the ZRTP endpoint stops sending SRTP packets. When a ClearACK is received, the ZRTP endpoint deletes the crypto context for the SRTP session, as defined in Section 4.7.2.1, and may then resume sending RTP packets.
发送GoClear消息后，ZRTP端点停止发送SRTP数据包。当接收到ClearACK时，ZRTP端点删除SRTP会话的加密上下文，如第4.7.2.1节所定义，然后可以恢复发送RTP数据包。
In the event a ClearACK is not received before the retransmissions of GoClear are exhausted, the key material is deleted, as defined in Section 4.7.2.1.
如果在GoClear的重新传输耗尽之前未收到ClearACK，则按照第4.7.2.1节的规定删除关键材料。
After the users have transitioned from SRTP media back to RTP media (clear mode), they may decide later to return to secure mode by manual activation, usually by pressing a GO SECURE button. In that case, a new secure session is initiated by the party that presses the button, by sending a new Commit message, leading to a new session key negotiation. It is not necessary to send another Hello message, as the two parties have already done that at the start of the call and thus have already discovered each other's ZRTP capabilities. It is possible for users to toggle back and forth between clear and secure modes multiple times in the same session, just as they could in the old days of secure PSTN phones.
在用户从SRTP介质转换回RTP介质（清除模式）后，他们可能会决定稍后通过手动激活（通常通过按下安全按钮）返回安全模式。在这种情况下，按下按钮的一方通过发送新的提交消息来启动新的安全会话，从而导致新的会话密钥协商。无需发送另一条Hello消息，因为双方在通话开始时已经发送了Hello消息，因此已经发现了对方的ZRTP功能。用户可以在同一会话中多次在清除模式和安全模式之间来回切换，就像在过去安全的PSTN电话中一样。
All SRTP session key material MUST be erased by the receiver of the GoClear message upon receiving a properly authenticated GoClear. The same key destruction MUST be done by the sender of GoClear message, upon receiving the ClearACK. This must be done for the key material for all of the media streams.
GoClear消息的接收者必须在收到经过适当认证的GoClear后擦除所有SRTP会话密钥材料。收到ClearACK后，GoClear消息的发送方必须销毁相同的密钥。必须对所有媒体流的关键材料执行此操作。
All key material that would have been erased at the end of the SIP session MUST be erased, as described in Section 4.7.3, with the single exception of ZRTPSess. In this case, ZRTPSess is destroyed in a manner different from the other key material. Both parties replace ZRTPSess with a KDF-derived non-invertible function of itself:
如第4.7.3节所述，本应在SIP会话结束时擦除的所有关键材料必须擦除，ZRTPSES除外。在这种情况下，ZRTPSES的销毁方式与其他关键材料不同。双方将ZRTPSES替换为KDF派生的自身不可逆函数：
ZRTPSess = KDF(ZRTPSess, "New ZRTP Session", (ZIDi || ZIDr), negotiated hash length)
ZRTPSES=KDF（ZRTPSES，“新ZRTP会话”（ZIDi | | ZIDr），协商哈希长度）
ZRTPSess will be replaced twice if a session generates separate GoClear messages for both audio and video streams, and the two endpoints need not carry out the replacements in the same order.
如果会话为音频和视频流生成单独的GoClear消息，那么ZRTPSES将被替换两次，并且两个端点不需要以相同的顺序执行替换。
The destruction of key material meets the requirements of Perfect Forward Secrecy (PFS), but still preserves a new version of ZRTPSess, so that the user can later re-initiate secure mode during the same session without performing another Diffie-Hellman calculation using Multistream mode, which requires and assumes the existence of ZRTPSess with the same value at both ZRTP endpoints. A new key negotiation after a GoClear SHOULD use a Multistream Commit message.
密钥材料的销毁满足完美前向保密（PFS）的要求，但仍保留新版本的ZRTPSES，因此用户可以在同一会话期间重新启动安全模式，而无需使用多流模式执行另一个Diffie-Hellman计算，它要求并假设两个ZRTP端点上存在具有相同值的ZRTPSES。GoClear之后的新密钥协商应使用多流提交消息。
Note: Multistream mode is preferred over a Diffie-Hellman mode since this does not require the generation of a new hash chain and a new signaling exchange to exchange new Hello Hash values.
注意：多流模式优于Diffie-Hellman模式，因为这不需要生成新的哈希链和新的信令交换来交换新的Hello哈希值。
Later, at the end of the entire call, ZRTPSess is finally destroyed along with the other key material, as described in Section 4.7.3.
随后，在整个调用结束时，ZRTPSES最终与其他关键材料一起销毁，如第4.7.3节所述。
All SRTP session key material MUST be erased by both parties at the end of the call. In particular, the destroyed key material includes the SRTP session keys and salts, SRTP master keys and salts, and all material sufficient to reconstruct the SRTP keys and salts, including ZRTPSess and s0 (although s0 should have been destroyed earlier, in Section 4.6.1). This must be done for the key material for all of the media streams. The only exceptions are the cached shared secrets needed for future sessions, including rs1, rs2, and pbxsecret.
通话结束时，双方必须擦除所有SRTP会话密钥材料。特别是，销毁的密钥材料包括SRTP会话密钥和盐、SRTP主密钥和盐，以及足以重建SRTP密钥和盐的所有材料，包括ZRTPSES和s0（尽管s0应在第4.6.1节中提前销毁）。必须对所有媒体流的关键材料执行此操作。唯一的例外是未来会话所需的缓存共享机密，包括rs1、rs2和pbxsecret。
The ZRTP protocol uses random numbers for cryptographic key material, notably for the DH secret exponents and nonces, which must be freshly generated with each session. Whenever a random number is needed, all of the following criteria must be satisfied:
ZRTP协议使用随机数作为加密密钥材料，尤其是DH秘密指数和nonce，它们必须在每次会话中新生成。每当需要随机数时，必须满足以下所有标准：
Random numbers MUST be freshly generated, meaning that they must not have been used in a previous calculation.
随机数必须是新生成的，这意味着它们不能在以前的计算中使用。
When generating a random number k of L bits in length, k MUST be chosen with equal probability from the range of [1 < k < 2^L].
当生成长度为L位的随机数k时，必须从[1<k<2^L]范围内以相等的概率选择k。
It MUST be derived from a physical entropy source, such as radio frequency (RF) noise, acoustic noise, thermal noise, high-resolution timings of environmental events, or other unpredictable physical sources of entropy. One possible source of entropy for a VoIP client would be microphone noise. For a detailed explanation of cryptographic grade random numbers and guidance for collecting suitable entropy, see [RFC4086] and Chapter 10 of "Practical Cryptography" [Ferguson]. The raw entropy must be distilled and processed through a deterministic random-bit generator (DRBG). Examples of DRBGs may be found in [NIST-SP800-90], in [Ferguson], and in [RFC5869]. Failure to use true entropy from the physical environment as a basis for generating random cryptographic key material would lead to a disastrous loss of security.
它必须来自物理熵源，如射频（RF）噪声、声噪声、热噪声、环境事件的高分辨率计时或其他不可预测的物理熵源。VoIP客户端熵的一个可能来源是麦克风噪音。有关加密级随机数的详细解释和收集适当熵的指南，请参见[RFC4086]和“实用密码术”[Ferguson]第10章。原始熵必须通过确定性随机位生成器（DRBG）进行提取和处理。DRBG的示例可在[NIST-SP800-90]、[Ferguson]和[RFC5869]中找到。如果不使用物理环境中的真实熵作为生成随机密码密钥材料的基础，将导致灾难性的安全损失。
Each instance of ZRTP has a unique 96-bit random ZRTP ID, or ZID, that is generated once at installation time. It is used to look up retained shared secrets in a local cache. A single global ZID for a single installation is the simplest way to implement ZIDs. However, it is specifically not precluded for an implementation to use multiple ZIDs, up to the limit of a separate one per callee. This then turns it into a long-lived "association ID" that does not apply to any other associations between a different pair of parties. It is a goal of this protocol to permit both options to interoperate freely. A PBX acting as a trusted man in the middle will also generate a single ZID and use that ZID for all endpoints behind it, as described in Section 10.
ZRTP的每个实例都有一个唯一的96位随机ZRTP ID或ZID，该ID在安装时生成一次。它用于在本地缓存中查找保留的共享机密。单个安装的单个全局ZID是实现ZID的最简单方法。但是，一个实现不排除使用多个ZID，最多每个被调用方使用一个单独的ZID。然后，这将把它变成一个长期存在的“关联ID”，它不适用于不同一对当事人之间的任何其他关联。该协议的目标是允许两个选项自由互操作。在中间充当可信人的PBX也将生成单个ZID，并使用ZID来支持它后面的所有端点，如第10节所述。
There is no protocol mechanism to invalidate a previously used ZID. An endpoint wishing to change ZIDs would simply generate a new one and begin using it.
没有使以前使用的ZID无效的协议机制。希望更改ZID的端点只需生成一个新的ZID并开始使用它。
The ZID should not be hard coded or hard defined in the firmware of a product. It should be randomly generated by the software and stored at installation or initialization time. It should be randomly generated rather than allocated from a preassigned range of ZID values, because 96 bits should be enough to avoid birthday collisions in realistic scenarios.
产品固件中不应硬编码或硬定义ZID。它应由软件随机生成，并在安装或初始化时存储。它应该随机生成，而不是从预先指定的ZID值范围中分配，因为96位应该足以避免现实场景中的生日冲突。
Each time a new s0 is calculated, a new retained shared secret rs1 is generated and stored in the cache, indexed by the ZID of the other endpoint. This cache updating is described in Section 4.6.1. For the new retained shared secret, each endpoint chooses a cache expiration value that is an unsigned 32-bit integer of the number of seconds that this secret should be retained in the cache. The time interval is relative to when the Confirm1 message is sent or received.
每次计算新的s0时，都会生成一个新的保留共享秘密rs1并存储在缓存中，由另一个端点的ZID索引。第4.6.1节描述了缓存更新。对于新的保留共享机密，每个端点选择一个缓存过期值，该值是该机密应保留在缓存中的秒数的无符号32位整数。时间间隔与发送或接收Confirm1消息的时间有关。
The cache intervals are exchanged in the Confirm1 and Confirm2 messages (Figure 10). The actual cache interval used by both endpoints is the minimum of the values from the Confirm1 and Confirm2 messages. A value of 0 seconds means the newly computed shared secret SHOULD NOT be stored in the cache, and if a cache entry already exists from an earlier call, the stored cache interval should be set to 0. This means if either Confirm message contains a null cache expiration interval, and there is no cache entry already defined, no new cache entry is created. A value of 0xffffffff means the secret should be cached indefinitely and is the recommended value. If the ZRTP exchange is Multistream mode, the field in the Confirm1 and Confirm2 is set to 0xffffffff and is ignored; the cache is not updated.
缓存间隔在Confirm1和Confirm2消息中交换（图10）。两个端点使用的实际缓存间隔是Confirm1和Confirm2消息中的最小值。值为0秒表示新计算的共享机密不应存储在缓存中，如果先前调用中已存在缓存项，则存储的缓存间隔应设置为0。这意味着，如果任一确认消息包含空缓存过期时间间隔，并且没有已定义的缓存项，则不会创建新的缓存项。0xFFFFFF的值意味着应该无限期地缓存机密，这是建议的值。如果ZRTP交换为多流模式，则Confirm1和Confirm2中的字段设置为0xFFFFFF并被忽略；缓存未更新。
The expiration interval need not be used to force the deletion of a shared secret from the cache when the interval has expired. It just means the shared secret MAY be deleted from that cache at any point after the interval has expired without causing the other party to note it as an unexpected security event when the next key negotiation occurs between the same two parties. This means there need not be perfectly synchronized deletion of expired secrets from the two caches, and makes it easy to avoid a race condition that might otherwise be caused by clock skew.
当间隔过期时，不需要使用过期间隔强制从缓存中删除共享机密。这只是意味着，在间隔到期后的任何时候，共享密钥都可以从缓存中删除，而不会导致另一方在同一双方之间进行下一次密钥协商时将其作为意外安全事件进行记录。这意味着不需要完全同步地删除两个缓存中的过期机密，并且可以很容易地避免可能由时钟偏移引起的竞争条件。
If the expiration interval is not properly agreed to by both endpoints, it may later result in false alarms of MiTM attacks, due to apparent cache mismatches (Section 4.3.2).
如果两个端点未正确同意过期时间间隔，则可能会由于明显的缓存不匹配而导致MiTM攻击的假警报（第4.3.2节）。
The relationship between a ZID and a SIP AOR is explained in Section 12.
第12节解释了ZID和SIP AOR之间的关系。
It is possible to implement a simplified but nonetheless useful (and still compliant) profile of the ZRTP protocol that does not support any caching of shared secrets. In this case, the users would have to rely exclusively on the verbal SAS comparison for every call. That is, unless MiTM protection is provided by the mechanisms in Section 8.1.1 or 7.2, which introduce their own forms of complexity.
可以实现ZRTP协议的简化但仍然有用（并且仍然兼容）的概要文件，该概要文件不支持共享机密的任何缓存。在这种情况下，用户将不得不完全依赖于每个呼叫的口头SAS比较。也就是说，除非第8.1.1节或第7.2节中的机制提供了MiTM保护，这些机制引入了其自身的复杂性形式。
If a ZRTP endpoint does not support the caching of shared secrets, it MUST set the cache expiration interval to zero, and MUST set the SAS Verified (V) flag (Section 7.1) to false. In addition, because the ZID serves mainly as a cache index, the ZID would not be required to maintain the same value across separate SIP sessions, although there is no reason why it should not.
如果ZRTP端点不支持缓存共享机密，则必须将缓存过期时间间隔设置为零，并且必须将SAS验证（V）标志（第7.1节）设置为false。此外，由于ZID主要用作缓存索引，因此不需要在单独的SIP会话中保持相同的值，尽管没有理由不这样做。
Cacheless operation would sacrifice the key continuity (Section 15.1) features, as well as Preshared mode (Section 4.4.2). Further, if the pbxsecret is also not cached, there would be no PBX trusted MiTM (Section 7.3) features, including the PBX security enrollment (Section 7.3.1) mechanism.
无缓存操作将牺牲密钥连续性（第15.1节）功能以及预共享模式（第4.4.2节）。此外，如果pbxsecret也未缓存，则不会有PBX受信任的MiTM（第7.3节）功能，包括PBX安全注册（第7.3.1节）机制。
All ZRTP messages use the message format defined in Figure 2. All word lengths referenced in this specification are 32 bits, or 4 octets. All integer fields are carried in network byte order, that is, most-significant byte (octet) first, commonly known as big-endian.
所有ZRTP消息都使用图2中定义的消息格式。本规范中引用的所有字长均为32位或4个八位字节。所有整数字段都按网络字节顺序进行传输，也就是说，最高有效字节（八位字节）优先，通常称为big-endian。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Not Used (set to zero) | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie 'ZRTP' (0x5a525450) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ZRTP Message (length depends on Message Type) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Not Used (set to zero) | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie 'ZRTP' (0x5a525450) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ZRTP Message (length depends on Message Type) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: ZRTP Packet Format
图2:ZRTP数据包格式
The Sequence Number is a count that is incremented for each ZRTP packet sent. The count is initialized to a random value. This is useful in estimating ZRTP packet loss and also detecting when ZRTP packets arrive out of sequence.
序列号是为每个发送的ZRTP数据包递增的计数。计数初始化为随机值。这在估计ZRTP数据包丢失和检测ZRTP数据包何时无序到达方面很有用。
The ZRTP Magic Cookie is a 32-bit string that uniquely identifies a ZRTP packet and has the value 0x5a525450.
ZRTP Magic Cookie是一个32位字符串，用于唯一标识ZRTP数据包，其值为0x5a525450。
Source Identifier is the SSRC number of the RTP stream to which this ZRTP packet relates. For cases of forking or forwarding, RTP, and hence ZRTP, may arrive at the same port from several different sources -- each of these sources will have a different SSRC and may initiate an independent ZRTP protocol session. SSRC collisions would be disruptive to ZRTP. SSRC collision handling procedures are described in Section 4.1.
源标识符是与此ZRTP数据包相关的RTP流的SSRC号。对于分叉或转发的情况，RTP和ZRTP可能会从几个不同的源到达同一端口——这些源中的每一个都有不同的SSRC，并且可能会启动独立的ZRTP协议会话。SSRC碰撞将破坏ZRTP。SSRC碰撞处理程序见第4.1节。
This format is clearly identifiable as non-RTP due to the first two bits being zero, which looks like RTP version 0, which is not a valid RTP version number. It is clearly distinguishable from STUN since the Magic Cookies are different. The 12 unused bits are set to zero and MUST be ignored when received. In early versions of this spec, ZRTP messages were encapsulated in RTP header extensions, which made ZRTP an eponymous variant of RTP. In later versions, the packet format changed to make it syntactically distinguishable from RTP.
由于前两位为零（看起来像RTP版本0，不是有效的RTP版本号），此格式可以清楚地识别为非RTP。因为魔法饼干是不同的，所以它与眩晕很明显是不同的。12个未使用的位设置为零，接收时必须忽略。在本规范的早期版本中，ZRTP消息封装在RTP头扩展中，这使ZRTP成为RTP的同名变体。在以后的版本中，数据包格式发生了变化，使其在语法上与RTP不同。
The ZRTP messages are defined in Figures 3 to 17 and are of variable length.
ZRTP消息在图3至图17中定义，其长度可变。
The ZRTP protocol uses a 32-bit Cyclic Redundancy Check (CRC) as defined in RFC 4960, Appendix B [RFC4960], in each ZRTP packet to detect transmission errors. ZRTP packets are typically transported by UDP, which carries its own built-in 16-bit checksum for integrity, but ZRTP does not rely on it. This is because of the effect of an undetected transmission error in a ZRTP message. For example, an undetected error in the DH exchange could appear to be an active man-in-the-middle attack. A false announcement of this by ZRTP clients can be psychologically distressing. The probability of such a false alarm hinges on a mere 16-bit checksum that usually protects UDP packets, so more error detection is needed. For these reasons, this belt-and-suspenders approach is used to minimize the chance of a transmission error affecting the ZRTP key agreement.
ZRTP协议在每个ZRTP数据包中使用RFC 4960附录B[RFC4960]中定义的32位循环冗余校验（CRC）来检测传输错误。ZRTP数据包通常由UDP传输，UDP自带16位完整性校验和，但ZRTP不依赖它。这是因为ZRTP消息中未检测到的传输错误的影响。例如，DH交换中未检测到的错误可能是中间人主动攻击。ZRTP客户对这一点的虚假声明可能会让人感到心理上的痛苦。这种错误警报的概率取决于通常保护UDP数据包的16位校验和，因此需要更多的错误检测。出于这些原因，这种皮带和吊杆方法用于将传输错误影响ZRTP密钥协议的可能性降至最低。
The CRC is calculated across the entire ZRTP packet shown in Figure 2, including the ZRTP header and the ZRTP message, but not including the CRC field. If a ZRTP message fails the CRC check, it is silently discarded.
CRC是跨图2所示的整个ZRTP数据包计算的，包括ZRTP头和ZRTP消息，但不包括CRC字段。如果ZRTP消息未通过CRC检查，则会自动丢弃该消息。
ZRTP messages are designed to simplify endpoint parsing requirements and to reduce the opportunities for buffer overflow attacks (a good goal of any security extension should be to not introduce new attack vectors).
ZRTP消息旨在简化端点解析需求并减少缓冲区溢出攻击的机会（任何安全扩展的一个良好目标都应该是不引入新的攻击向量）。
ZRTP uses a block of 8 octets (2 words) to encode the Message Type. 4-octet (1 word) blocks are used to encode Hash Type, Cipher Type, Key Agreement Type, and Authentication Tag Type. The values in the blocks are ASCII strings that are extended with spaces (0x20) to make them the desired length. Currently defined block values are listed in Tables 1-6.
ZRTP使用8个八位字节（2个字）的块对消息类型进行编码。4个八位字节（1个字）块用于编码哈希类型、密码类型、密钥协议类型和身份验证标记类型。块中的值是ASCII字符串，通过空格（0x20）扩展以使其成为所需的长度。表1-6列出了当前定义的块值。
Additional block values may be defined and used.
可以定义和使用其他块值。
ZRTP uses this ASCII encoding to simplify debugging and make it "Wireshark (Ethereal) friendly".
ZRTP使用这种ASCII编码来简化调试并使其“Wireshark（Ethereal）友好”。
Currently, 16 Message Type Blocks are defined -- they represent the set of ZRTP message primitives. ZRTP endpoints MUST support the Hello, HelloACK, Commit, DHPart1, DHPart2, Confirm1, Confirm2, Conf2ACK, SASrelay, RelayACK, Error, ErrorACK, and PingACK message types. ZRTP endpoints MAY support the GoClear, ClearACK, and Ping messages. In order to generate a PingACK message, it is necessary to parse a Ping message. Additional messages may be defined in extensions to ZRTP.
目前，定义了16个消息类型块——它们表示ZRTP消息原语集。ZRTP端点必须支持Hello、HelloACK、Commit、DHPart1、DHPart2、Confirm1、Confirm2、Conf2ACK、SASrelay、RelayACK、Error、ErrorACK和PingACK消息类型。ZRTP端点可能支持GoClear、ClearACK和Ping消息。为了生成PingACK消息，需要解析Ping消息。附加消息可以在ZRTP的扩展中定义。
Message Type Block | Meaning
---------------------------------------------------
"Hello " | Hello Message
---------------------------------------------------
"HelloACK" | HelloACK Message
---------------------------------------------------
"Commit " | Commit Message
---------------------------------------------------
"DHPart1 " | DHPart1 Message
---------------------------------------------------
"DHPart2 " | DHPart2 Message
---------------------------------------------------
"Confirm1" | Confirm1 Message
---------------------------------------------------
"Confirm2" | Confirm2 Message
---------------------------------------------------
"Conf2ACK" | Conf2ACK Message
---------------------------------------------------
"Error " | Error Message
---------------------------------------------------
"ErrorACK" | ErrorACK Message
---------------------------------------------------
"GoClear " | GoClear Message
---------------------------------------------------
"ClearACK" | ClearACK Message
---------------------------------------------------
"SASrelay" | SASrelay Message
---------------------------------------------------
"RelayACK" | RelayACK Message
---------------------------------------------------
"Ping " | Ping Message
---------------------------------------------------
"PingACK " | PingACK Message
---------------------------------------------------
Message Type Block | Meaning
---------------------------------------------------
"Hello " | Hello Message
---------------------------------------------------
"HelloACK" | HelloACK Message
---------------------------------------------------
"Commit " | Commit Message
---------------------------------------------------
"DHPart1 " | DHPart1 Message
---------------------------------------------------
"DHPart2 " | DHPart2 Message
---------------------------------------------------
"Confirm1" | Confirm1 Message
---------------------------------------------------
"Confirm2" | Confirm2 Message
---------------------------------------------------
"Conf2ACK" | Conf2ACK Message
---------------------------------------------------
"Error " | Error Message
---------------------------------------------------
"ErrorACK" | ErrorACK Message
---------------------------------------------------
"GoClear " | GoClear Message
---------------------------------------------------
"ClearACK" | ClearACK Message
---------------------------------------------------
"SASrelay" | SASrelay Message
---------------------------------------------------
"RelayACK" | RelayACK Message
---------------------------------------------------
"Ping " | Ping Message
---------------------------------------------------
"PingACK " | PingACK Message
---------------------------------------------------
Table 1. Message Type Block Values
表1。消息类型块值
The hash algorithm and its related MAC algorithm are negotiated via the Hash Type Block found in the Hello message (Section 5.2) and the Commit message (Section 5.4).
哈希算法及其相关MAC算法通过Hello消息（第5.2节）和提交消息（第5.4节）中的哈希类型块进行协商。
All ZRTP endpoints MUST support a Hash Type of SHA-256 [FIPS-180-3]. SHA-384 SHOULD be supported and MUST be supported if ECDH-384 is used. Additional Hash Types MAY be used, such as the NIST SHA-3 hash [SHA-3] when it becomes available. Note that the Hash Type refers to
所有ZRTP端点必须支持SHA-256[FIPS-180-3]的哈希类型。应支持SHA-384，如果使用ECDH-384，则必须支持SHA-384。当NIST SHA-3哈希[SHA-3]可用时，可以使用其他哈希类型。请注意，哈希类型指的是
the hash algorithm that will be used throughout the ZRTP key exchange, not the hash algorithm to be used in the SRTP Authentication Tag.
将在整个ZRTP密钥交换过程中使用的哈希算法，而不是将在SRTP身份验证标记中使用的哈希算法。
The choice of the negotiated Hash Type is coupled to the Key Agreement Type, as explained in Section 5.1.5.
协商哈希类型的选择与密钥协议类型耦合，如第5.1.5节所述。
Hash Type Block | Meaning
----------------------------------------------------------
"S256" | SHA-256 Hash defined in FIPS 180-3
----------------------------------------------------------
"S384" | SHA-384 Hash defined in FIPS 180-3
----------------------------------------------------------
"N256" | NIST SHA-3 256-bit hash (when published)
----------------------------------------------------------
"N384" | NIST SHA-3 384-bit hash (when published)
----------------------------------------------------------
Hash Type Block | Meaning
----------------------------------------------------------
"S256" | SHA-256 Hash defined in FIPS 180-3
----------------------------------------------------------
"S384" | SHA-384 Hash defined in FIPS 180-3
----------------------------------------------------------
"N256" | NIST SHA-3 256-bit hash (when published)
----------------------------------------------------------
"N384" | NIST SHA-3 384-bit hash (when published)
----------------------------------------------------------
Table 2. Hash Type Block Values
表2。哈希类型块值
At the time of this writing, the NIST SHA-3 hashes [SHA-3] are not yet available. NIST is expected to publish SHA-3 in 2012, as a successor to the SHA-2 hashes in [FIPS-180-3].
在撰写本文时，NIST SHA-3哈希[SHA-3]还不可用。NIST预计将于2012年发布SHA-3，作为[FIPS-180-3]中SHA-2哈希的后续版本。
ZRTP makes use of message authentication codes (MACs) that are keyed hashes based on the negotiated Hash Type. For the SHA-2 and SHA-3 hashes, the negotiated MAC is the HMAC based on the negotiated hash. This MAC function is also used in the ZRTP key derivation function (Section 4.5.1).
ZRTP利用消息身份验证代码（MAC），这些代码是基于协商哈希类型的密钥哈希。对于SHA-2和SHA-3哈希，协商MAC是基于协商哈希的HMAC。该MAC功能也用于ZRTP密钥派生功能（第4.5.1节）。
The HMAC function is defined in [FIPS-198-1]. A discussion of the general security of the HMAC construction may be found in [RFC2104]. Test vectors for HMAC-SHA-256 and HMAC-SHA-384 may be found in [RFC4231].
HMAC功能在[FIPS-198-1]中定义。有关HMAC施工的一般安全性的讨论，请参见[RFC2104]。HMAC-SHA-256和HMAC-SHA-384的测试向量可在[RFC4231]中找到。
The negotiated Hash Type does not apply to the hash used in the digital signature defined in Section 7.2. For example, even if the negotiated Hash Type is SHA-256, the digital signature may use SHA-384 if an Elliptic Curve Digital Signature Algorithm (ECDSA) P-384 signature key is used. Digital signatures are optional in ZRTP.
协商的哈希类型不适用于第7.2节中定义的数字签名中使用的哈希。例如，即使协商的散列类型是SHA-256，如果使用椭圆曲线数字签名算法（ECDSA）P-384签名密钥，则数字签名也可以使用SHA-384。数字签名在ZRTP中是可选的。
Except for the aforementioned digital signatures, and the special cases noted in Section 5.1.2.2, all the other hashes and MACs used throughout the ZRTP protocol will use the negotiated Hash Type.
除上述数字签名和第5.1.2.2节中提到的特殊情况外，ZRTP协议中使用的所有其他哈希和MAC将使用协商哈希类型。
A future hash may include its own built-in MAC, not based on the HMAC construct, for example, the Skein hash function [Skein]. If NIST chooses such a hash as the SHA-3 winner, Hash Types "N256", and "N384" will still use the related HMAC as the negotiated MAC. If an implementer wishes to use Skein and its built-in MAC as the negotiated MAC, new Hash Types must be used.
未来的散列可以包括其自己的内置MAC，而不是基于HMAC构造，例如Skein散列函数[Skein]。如果NIST选择此类散列作为SHA-3赢家，散列类型“N256”和“N384”仍将使用相关HMAC作为协商MAC。如果实现者希望使用Skein及其内置MAC作为协商MAC，则必须使用新的哈希类型。
While most of the hash and MAC usage in ZRTP is defined by the negotiated Hash Type (Section 5.1.2), some hashes and MACs must be precomputed prior to negotiations, and thus cannot have their algorithms negotiated during the ZRTP exchange. They are implicitly predetermined to use SHA-256 [FIPS-180-3] and HMAC-SHA-256.
虽然ZRTP中的大多数哈希和MAC使用是由协商的哈希类型定义的（第5.1.2节），但某些哈希和MAC必须在协商之前进行预计算，因此不能在ZRTP交换期间协商其算法。它们隐含地预先确定使用SHA-256[FIPS-180-3]和HMAC-SHA-256。
These are the hashes and MACs that MUST use the Implicit hash and MAC algorithm:
以下是必须使用隐式哈希和MAC算法的哈希和MAC：
The hash chain H0-H3 defined in Section 9.
第9节中定义的散列链H0-H3。
The MACs that are keyed by this hash chain, as defined in Section 8.1.1.
按照第8.1.1节的定义，由该散列链设置密钥的MAC。
The Hello Hash in the a=zrtp-hash attribute defined in Section 8.1.
第8.1节中定义的a=zrtp哈希属性中的Hello哈希。
ZRTP defines a method for negotiating different ZRTP protocol versions (Section 4.1.1). SHA-256 is the Implicit Hash and HMAC-SHA-256 is the Implicit MAC for ZRTP protocol version 1.10. Future ZRTP protocol versions may, if appropriate, use another hash algorithm as the Implicit Hash, such as the NIST SHA-3 hash [SHA-3], when it becomes available. For example, a future SIP packet may list two a=zrtp-hash SDP attributes, one based on SHA-256 for ZRTP version 1.10, and another based on SHA-3 for ZRTP version 2.00.
ZRTP定义了协商不同ZRTP协议版本的方法（第4.1.1节）。SHA-256是隐式哈希，HMAC-SHA-256是ZRTP协议版本1.10的隐式MAC。如果合适的话，未来的ZRTP协议版本可以使用另一种哈希算法作为隐式哈希，如NIST SHA-3哈希[SHA-3]，当它可用时。例如，未来的SIP分组可以列出两个a＝zrtp散列SDP属性，一个基于SHA-256用于zrtp版本1.10，另一个基于SHA-3用于zrtp版本2.00。
The block cipher algorithm is negotiated via the Cipher Type Block found in the Hello message (Section 5.2) and the Commit message (Section 5.4).
分组密码算法通过Hello消息（第5.2节）和Commit消息（第5.4节）中的密码类型块进行协商。
All ZRTP endpoints MUST support AES-128 (AES1) and MAY support AES-192 (AES2), AES-256 (AES3), or other Cipher Types. The Advanced Encryption Standard is defined in [FIPS-197].
所有ZRTP端点必须支持AES-128（AES1），并且可以支持AES-192（AES2）、AES-256（AES3）或其他密码类型。[FIPS-197]中定义了高级加密标准。
The use of AES-128 in SRTP is defined by [RFC3711]. The use of AES-192 and AES-256 in SRTP is defined by [RFC6188]. The choice of the AES key length is coupled to the Key Agreement Type, as explained in Section 5.1.5.
[RFC3711]定义了在SRTP中使用AES-128。[RFC6188]定义了在SRTP中使用AES-192和AES-256。AES密钥长度的选择与密钥协议类型相耦合，如第5.1.5节所述。
Other block ciphers may be supported that have the same block size and key sizes as AES. If implemented, they may be used anywhere in ZRTP or SRTP in place of the AES, in the same modes of operation and key size. Notably, in counter mode to replace AES-CM in [RFC3711] and [RFC6188], as well as in CFB mode to encrypt a portion of the Confirm message (Figure 10) and SASrelay message (Figure 16). ZRTP endpoints MAY support the TwoFish [TwoFish] block cipher.
可以支持与AES具有相同块大小和密钥大小的其他分组密码。如果实现，它们可以在ZRTP或SRTP中的任何位置代替AES，以相同的操作模式和密钥大小使用。值得注意的是，在计数器模式下替换[RFC3711]和[RFC6188]中的AES-CM，以及在CFB模式下加密部分确认消息（图10）和SASrelay消息（图16）。ZRTP端点可能支持TwoFish[TwoFish]分组密码。
Cipher Type Block | Meaning
-------------------------------------------------
"AES1" | AES with 128-bit keys
-------------------------------------------------
"AES2" | AES with 192-bit keys
-------------------------------------------------
"AES3" | AES with 256-bit keys
-------------------------------------------------
"2FS1" | TwoFish with 128-bit keys
-------------------------------------------------
"2FS2" | TwoFish with 192-bit keys
-------------------------------------------------
"2FS3" | TwoFish with 256-bit keys
-------------------------------------------------
Cipher Type Block | Meaning
-------------------------------------------------
"AES1" | AES with 128-bit keys
-------------------------------------------------
"AES2" | AES with 192-bit keys
-------------------------------------------------
"AES3" | AES with 256-bit keys
-------------------------------------------------
"2FS1" | TwoFish with 128-bit keys
-------------------------------------------------
"2FS2" | TwoFish with 192-bit keys
-------------------------------------------------
"2FS3" | TwoFish with 256-bit keys
-------------------------------------------------
Table 3. Cipher Type Block Values
表3。密码类型块值
All ZRTP endpoints MUST support HMAC-SHA1 authentication tags for SRTP, with both 32-bit and 80-bit length tags as defined in [RFC3711].
所有ZRTP端点必须支持SRTP的HMAC-SHA1身份验证标记，具有[RFC3711]中定义的32位和80位长度标记。
ZRTP endpoints MAY support 32-bit and 64-bit SRTP authentication tags based on the Skein hash function [Skein]. The Skein-512-MAC key length is fixed at 256 bits for this application, and the output length is adjustable. The Skein MAC is defined in Sections 2.6 and 4.3 of [Skein] and is not based on the HMAC construct. Reference implementations for Skein may be found at [Skein1]. A Skein-based MAC is significantly more efficient than HMAC-SHA1, especially for short SRTP payloads.
ZRTP端点可以支持基于Skein哈希函数[Skein]的32位和64位SRTP身份验证标签。对于该应用程序，Skein-512-MAC密钥长度固定为256位，输出长度可调。Skein MAC在[Skein]第2.6节和第4.3节中定义，不基于HMAC结构。Skein的参考实现可在[Skein1]中找到。基于Skein的MAC明显比HMAC-SHA1更有效，尤其是对于短SRTP有效负载。
The Skein MAC key is computed by the SRTP key derivation function, which is also referred to as the AES-CM PRF, or pseudorandom function. This is defined either in [RFC3711] or in [RFC6188],
Skein MAC密钥由SRTP密钥推导函数计算，该函数也称为AES-CM PRF或伪随机函数。这在[RFC3711]或[RFC6188]中定义，
depending on the selected SRTP AES key length. To compute a Skein MAC key, the SRTP PRF output for the authentication key is left untruncated at 256 bits, instead of the usual truncated length of 160 bits (the key length used by HMAC-SHA1).
取决于选定的SRTP AES密钥长度。为了计算Skein MAC密钥，认证密钥的SRTP PRF输出在256位处不受信任，而不是通常的160位截断长度（HMAC-SHA1使用的密钥长度）。
Auth Tag Type Block | Meaning
----------------------------------------------------------
"HS32" | 32-bit authentication tag based on
| HMAC-SHA1 as defined in RFC 3711.
----------------------------------------------------------
"HS80" | 80-bit authentication tag based on
| HMAC-SHA1 as defined in RFC 3711.
----------------------------------------------------------
"SK32" | 32-bit authentication tag based on
| Skein-512-MAC as defined in [Skein],
| with 256-bit key, 32-bit MAC length.
----------------------------------------------------------
"SK64" | 64-bit authentication tag based on
| Skein-512-MAC as defined in [Skein],
| with 256-bit key, 64-bit MAC length.
----------------------------------------------------------
Auth Tag Type Block | Meaning
----------------------------------------------------------
"HS32" | 32-bit authentication tag based on
| HMAC-SHA1 as defined in RFC 3711.
----------------------------------------------------------
"HS80" | 80-bit authentication tag based on
| HMAC-SHA1 as defined in RFC 3711.
----------------------------------------------------------
"SK32" | 32-bit authentication tag based on
| Skein-512-MAC as defined in [Skein],
| with 256-bit key, 32-bit MAC length.
----------------------------------------------------------
"SK64" | 64-bit authentication tag based on
| Skein-512-MAC as defined in [Skein],
| with 256-bit key, 64-bit MAC length.
----------------------------------------------------------
Table 4. Auth Tag Type Values
表4。验证标记类型值
Implementers should be aware that AES-GCM and AES-CCM for SRTP are expected to become available when [SRTP-AES-GCM] is published as an RFC. If an implementer wishes to use these modes when they become available, new Auth Tag Types must be added.
实施者应意识到，当[SRTP-AES-GCM]作为RFC发布时，预计SRTP的AES-GCM和AES-CCM将可用。如果实现者希望在这些模式可用时使用它们，则必须添加新的身份验证标记类型。
All ZRTP endpoints MUST support DH3k, SHOULD support Preshared, and MAY support EC25, EC38, and DH2k.
所有ZRTP端点必须支持DH3k，应该支持预共享，并且可以支持EC25、EC38和DH2k。
If a ZRTP endpoint supports multiple concurrent media streams, such as audio and video, it MUST support Multistream (Section 4.4.3) mode. Also, if a ZRTP endpoint supports the GoClear message (Section 4.7.2), it SHOULD support Multistream, to be used if the two parties choose to return to the secure state after going Clear (as explained in Section 4.7.2.1).
如果ZRTP端点支持多个并发媒体流，如音频和视频，则它必须支持多流（第4.4.3节）模式。此外，如果ZRTP端点支持GoClear消息（第4.7.2节），则应支持多流，如果双方选择在清除后返回安全状态，则应使用多流（如第4.7.2.1节所述）。
For Finite Field Diffie-Hellman, ZRTP endpoints MUST use the DH parameters defined in [RFC3526], as follows. DH3k uses the 3072-bit modular exponentiation group (MODP). DH2k uses the 2048-bit MODP group. The DH generator g is 2. The random Diffie-Hellman secret exponent SHOULD be twice as long as the AES key length. If AES-128 is used, the DH secret value SHOULD be 256 bits long. If AES-256 is used, the secret value SHOULD be 512 bits long.
对于有限域Diffie-Hellman，ZRTP端点必须使用[RFC3526]中定义的DH参数，如下所示。DH3k使用3072位模幂组（MODP）。DH2k使用2048位MODP组。DH发生器g为2。随机Diffie-Hellman秘密指数应为AES密钥长度的两倍。如果使用AES-128，则DH秘密值的长度应为256位。如果使用AES-256，则秘密值的长度应为512位。
If Elliptic Curve DH is used, the ECDH algorithm and key generation is from [NIST-SP800-56A]. The curves used are from [NSA-Suite-B], which uses the same curves as ECDSA defined by [FIPS-186-3], and can also be found in RFC 5114, Sections 2.6 through 2.8 [RFC5114]. ECDH test vectors may be found in RFC 5114, appendices A.6 through A.8 [RFC5114]. The validation procedures are from [NIST-SP800-56A], Section 5.6.2.6, method 3, Elliptic Curve Cryptography (ECC) Partial Validation. Both the X and Y coordinates of the point on the curve are sent, in the first and second half of the ECDH public value, respectively. The ECDH result returns only the X coordinate, as specified in SP 800-56A. Useful strategies for implementing ECC may be found in [RFC6090].
如果使用椭圆曲线DH，则ECDH算法和密钥生成来自[NIST-SP800-56A]。使用的曲线来自[NSA-Suite-B]，其使用与[FIPS-186-3]定义的ECDSA相同的曲线，也可在RFC 5114第2.6至2.8节[RFC5114]中找到。ECDH测试向量可在RFC 5114附录A.6至A.8[RFC5114]中找到。验证程序来自[NIST-SP800-56A]，第5.6.2.6节，方法3，椭圆曲线密码（ECC）部分验证。曲线上点的X和Y坐标分别在ECDH公共值的上半部分和下半部分发送。ECDH结果仅返回SP 800-56A中规定的X坐标。[RFC6090]中提供了实施ECC的有用策略。
The choice of the negotiated hash algorithm (Section 5.1.2) is coupled to the choice of Key Agreement Type. If ECDH-384 (EC38) is chosen as the key agreement, the negotiated hash algorithm MUST be either SHA-384 or the corresponding SHA-3 successor.
协商哈希算法（第5.1.2节）的选择与密钥协议类型的选择相结合。如果选择ECDH-384（EC38）作为密钥协议，则协商的哈希算法必须是SHA-384或相应的SHA-3后续算法。
The choice of AES key length is coupled to the choice of Key Agreement Type. If EC38 is chosen as the key agreement, AES-256 (AES3) SHOULD be used but AES-192 MAY be used. If DH3k or EC25 is chosen, any AES key size MAY be used. Note that SRTP as defined in [RFC3711] only supports AES-128.
AES密钥长度的选择与密钥协议类型的选择相耦合。如果选择EC38作为密钥协议，则应使用AES-256（AES3），但可以使用AES-192。如果选择DH3k或EC25，则可以使用任何AES密钥大小。请注意，[RFC3711]中定义的SRTP仅支持AES-128。
DH2k is intended to provide acceptable security for low power applications, or for applications that require faster key negotiations. NIST asserts in Table 4 of [NIST-SP800-131A] that DH-2048 is safe to use through 2013. The security of DH2k can be augmented by implementing ZRTP's key continuity features (Section 15.1). DH2k SHOULD use AES-128. If an implementor must use slow hardware, DH2k should precede DH3k in the Hello message.
DH2k旨在为低功耗应用程序或需要更快密钥协商的应用程序提供可接受的安全性。NIST在[NIST-SP800-131A]的表4中声称DH-2048在2013年之前是安全的。通过实施ZRTP的关键连续性功能（第15.1节），可以增强DH2k的安全性。DH2k应使用AES-128。如果实现者必须使用慢速硬件，则在Hello消息中DH2k应位于DH3k之前。
ECDH-521 SHOULD NOT be used, due to disruptive computational delays. These delays may lead to exhaustion of the retransmission schedule, unless both endpoints have very fast hardware. Note that ECDH-521 is not part of NSA Suite B.
由于中断性计算延迟，不应使用ECDH-521。这些延迟可能会导致重传时间表耗尽，除非两个端点都有非常快的硬件。请注意，ECDH-521不是NSA套件B的一部分。
ZRTP also defines two non-DH modes, Multistream and Preshared, in which the SRTP key is derived from a shared secret and some nonce material.
ZRTP还定义了两种非DH模式，即Multistream和Preshared，其中SRTP密钥来自共享密钥和一些nonce材料。
The table below lists the pv length in words and DHPart1 and DHPart2 message length in words for each Key Agreement Type Block.
下表列出了每个关键协议类型块的pv长度（大写），DHPart1和DHPart2消息长度（大写）。
Key Agreement | pv | message | Meaning
Type Block | words | words |
-----------------------------------------------------------
"DH3k" | 96 | 117 | DH mode with p=3072 bit prime
| | | per RFC 3526, Section 4.
-----------------------------------------------------------
"DH2k" | 64 | 85 | DH mode with p=2048 bit prime
| | | per RFC 3526, Section 3.
-----------------------------------------------------------
"EC25" | 16 | 37 | Elliptic Curve DH, P-256
| | | per RFC 5114, Section 2.6
-----------------------------------------------------------
"EC38" | 24 | 45 | Elliptic Curve DH, P-384
| | | per RFC 5114, Section 2.7
-----------------------------------------------------------
"EC52" | 33 | 54 | Elliptic Curve DH, P-521
| | | per RFC 5114, Section 2.8
| | | (deprecated - do not use)
-----------------------------------------------------------
"Prsh" | - | - | Preshared Non-DH mode
-----------------------------------------------------------
"Mult" | - | - | Multistream Non-DH mode
-----------------------------------------------------------
Key Agreement | pv | message | Meaning
Type Block | words | words |
-----------------------------------------------------------
"DH3k" | 96 | 117 | DH mode with p=3072 bit prime
| | | per RFC 3526, Section 4.
-----------------------------------------------------------
"DH2k" | 64 | 85 | DH mode with p=2048 bit prime
| | | per RFC 3526, Section 3.
-----------------------------------------------------------
"EC25" | 16 | 37 | Elliptic Curve DH, P-256
| | | per RFC 5114, Section 2.6
-----------------------------------------------------------
"EC38" | 24 | 45 | Elliptic Curve DH, P-384
| | | per RFC 5114, Section 2.7
-----------------------------------------------------------
"EC52" | 33 | 54 | Elliptic Curve DH, P-521
| | | per RFC 5114, Section 2.8
| | | (deprecated - do not use)
-----------------------------------------------------------
"Prsh" | - | - | Preshared Non-DH mode
-----------------------------------------------------------
"Mult" | - | - | Multistream Non-DH mode
-----------------------------------------------------------
Table 5. Key Agreement Type Block Values
表5。密钥协议类型块值
The SAS Type determines how the SAS is rendered to the user so that the user may verbally compare it with his partner over the voice channel. This allows detection of a MiTM attack.
SAS类型确定如何将SAS呈现给用户，以便用户可以通过语音通道与合作伙伴进行口头比较。这允许检测MiTM攻击。
All ZRTP endpoints MUST support the base32 and MAY support the base256 rendering schemes for the Short Authentication String, and other SAS rendering schemes. See Section 4.5.2 for how the sasvalue is computed and Section 7 for how the SAS is used.
所有ZRTP端点必须支持base32，并且可能支持短身份验证字符串的base256呈现方案以及其他SAS呈现方案。关于如何计算sasvalue，请参见第4.5.2节，关于如何使用SAS，请参见第7节。
SAS Type Block | Meaning
---------------------------------------------------
"B32 " | Short Authentication String using
| base32 encoding
---------------------------------------------------
"B256" | Short Authentication String using
| base256 encoding (PGP Word List)
---------------------------------------------------
SAS Type Block | Meaning
---------------------------------------------------
"B32 " | Short Authentication String using
| base32 encoding
---------------------------------------------------
"B256" | Short Authentication String using
| base256 encoding (PGP Word List)
---------------------------------------------------
Table 6. SAS Type Block Values
表6。SAS类型块值
For the SAS Type of "B256", the most-significant (leftmost) 16 bits of the 32-bit sasvalue are rendered in network byte order using the PGP Word List [pgpwordlist] [Juola1][Juola2].
对于“B256”的SAS类型，32位sasvalue的最高有效（最左边）16位使用PGP字列表[pgpwordlist][Juola1][Juola2]以网络字节顺序呈现。
For the SAS Type of "B32 ", the most-significant (leftmost) 20 bits of the 32-bit sasvalue are rendered as a form of base32 encoding. The leftmost 20 bits of the sasvalue results in four base32 characters that are rendered, most-significant quintet first, to both ZRTP endpoints. Here is a normative pseudocode implementation of the base32 function:
对于“B32”的SAS类型，32位sasvalue的最高有效（最左边）20位以base32编码的形式呈现。sasvalue最左边的20位产生四个base32字符，这些字符首先呈现给两个ZRTP端点，最重要的五重奏。下面是base32函数的标准伪代码实现：
char[4] base32(uint32 bits)
{ int i, n, shift;
char result[4];
for (i=0,shift=27; i!=4; ++i,shift-=5)
{ n = (bits>>shift) & 31;
result[i] = "ybndrfg8ejkmcpqxot1uwisza345h769"[n];
}
return result;
}
char[4] base32(uint32 bits)
{ int i, n, shift;
char result[4];
for (i=0,shift=27; i!=4; ++i,shift-=5)
{ n = (bits>>shift) & 31;
result[i] = "ybndrfg8ejkmcpqxot1uwisza345h769"[n];
}
return result;
}
This base32 encoding scheme differs from RFC 4648, and was designed (by Bryce Wilcox-O'Hearn) to represent bit sequences in a form that is convenient for human users to manipulate with minimal ambiguity. The unusually permuted character ordering was designed for other applications that use bit sequences that do not end on quintet boundaries.
此base32编码方案不同于RFC4648，其设计（由Bryce Wilcox-O'Hearn）以便于人类用户以最小歧义操作的形式表示位序列。这种不寻常的字符排列顺序是为使用不以五行边界结束的位序列的其他应用程序而设计的。
The Signature Type Block specifies what signature algorithm is used to sign the SAS as discussed in Section 7.2. The 4-octet Signature Type Block, along with the accompanying signature block, are OPTIONAL and may be present in the Confirm message (Figure 10) or the SASrelay message (Figure 16). The signature types are given in the table below.
签名类型块指定用于对SAS签名的签名算法，如第7.2节所述。4-octet签名类型块以及附带的签名块是可选的，可以出现在确认消息（图10）或SASLepay消息（图16）中。下表给出了签名类型。
Signature | Meaning
Type Block |
------------------------------------------------
"PGP " | OpenPGP Signature, per RFC 4880
|
------------------------------------------------
"X509" | ECDSA, with X.509v3 cert
| per RFC 5759 and FIPS-186-3
------------------------------------------------
Signature | Meaning
Type Block |
------------------------------------------------
"PGP " | OpenPGP Signature, per RFC 4880
|
------------------------------------------------
"X509" | ECDSA, with X.509v3 cert
| per RFC 5759 and FIPS-186-3
------------------------------------------------
Table 7. Signature Type Block Values
表7。签名类型块值
Additional details on the signature and signing key format may be found in Section 7.2. OpenPGP signatures (Signature Type "PGP ") are discussed in Section 7.2.1. The ECDSA curves are over prime fields only, drawn from Appendix D.1.2 of [FIPS-186-3]. X.509v3 ECDSA Signatures (Signature Type "X509") are discussed in Section 7.2.2.
有关签名和签名密钥格式的更多详细信息，请参见第7.2节。第7.2.1节讨论了OpenPGP签名（签名类型“PGP”）。ECDSA曲线仅在素域上，从[FIPS-186-3]的附录D.1.2中绘制。第7.2.2节讨论了X.509v3 ECDSA签名（签名类型“X509”）。
The Hello message has the format shown in Figure 3.
Hello消息的格式如图3所示。
All ZRTP messages begin with the preamble value 0x505a, then a 16-bit length in 32-bit words. This length includes only the ZRTP message (including the preamble and the length) but not the ZRTP packet header or CRC. The 8-octet Message Type follows the length field.
所有ZRTP消息都以前导码值0x505a开始，然后是32位字中的16位长度。该长度仅包括ZRTP消息（包括前导码和长度），而不包括ZRTP数据包头或CRC。8位字节的消息类型在长度字段后面。
Next, there is a 4-character string containing the version (ver) of the ZRTP protocol, which is "1.10" for this specification. Next, there is the Client Identifier string (cid), which is 4 words long and identifies the vendor and release of the ZRTP software. The 256- bit hash image H3 is defined in Section 9. The next parameter is the ZID, the 96-bit-long unique identifier for the ZRTP endpoint, defined in Section 4.9.
接下来，有一个4个字符的字符串，其中包含ZRTP协议的版本（ver），对于本规范为“1.10”。接下来是客户机标识符字符串（cid），长度为4个字，用于标识ZRTP软件的供应商和版本。256位散列图像H3在第9节中定义。下一个参数是ZID，ZRTP端点的96位长唯一标识符，定义见第4.9节。
The next four bits include three flag bits:
接下来的四位包括三个标志位：
o The Signature-capable flag (S) indicates this Hello message is sent from a ZRTP endpoint which is able to parse and verify digital signatures, as described in Section 7.2. If signatures are not supported, the (S) flag MUST be set to zero.
o 支持签名的标志表示此Hello消息是从能够解析和验证数字签名的ZRTP端点发送的，如第7.2节所述。如果不支持签名，则必须将（S）标志设置为零。
o The MiTM flag (M) is a Boolean that is set to true if and only if this Hello message is sent from a device, usually a PBX, that has the capability to send an SASrelay message (Section 5.13).
o MiTM标志（M）是一个布尔值，当且仅当此Hello消息是从具有发送SASLepay消息能力的设备（通常是PBX）发送时，才会设置为true（第5.13节）。
o The Passive flag (P) is a Boolean normally set to false, and is set to true if and only if this Hello message is sent from a device that is configured to never send a Commit message (Section 5.4). This would mean it cannot initiate secure sessions, but may act as a responder.
o 被动标志（P）是一个布尔值，通常设置为false，当且仅当此Hello消息从配置为从不发送提交消息的设备发送时，才会设置为true（第5.4节）。这意味着它不能启动安全会话，但可以充当响应者。
The next 8 bits are unused and SHOULD be set to zero when sent and MUST be ignored on receipt.
接下来的8位未使用，发送时应设置为零，接收时必须忽略。
Next is a list of supported Hash algorithms, Cipher algorithms, SRTP Auth Tag Types, Key Agreement Types, and SAS Types. The number of listed algorithms are listed for each type: hc=hash count, cc=cipher count, ac=auth tag count, kc=key agreement count, and sc=sas count. The values for these algorithms are defined in Tables 2, 3, 4, 5, and
接下来是受支持的哈希算法、密码算法、SRTP Auth标记类型、密钥协议类型和SAS类型的列表。列出了每种类型的算法数量：hc=哈希计数、cc=密码计数、ac=身份验证标记计数、kc=密钥协议计数和sc=sas计数。这些算法的值在表2、3、4、5和3中定义
6. A count of zero means that only the mandatory-to-implement algorithms are supported. Mandatory algorithms MAY be included in the list. The order of the list indicates the preferences of the endpoint. If a mandatory algorithm is not included in the list, it is implicitly added to the end of the list for preference.
6. 计数为零意味着只支持强制实现算法。列表中可能包括强制算法。列表的顺序指示端点的首选项。如果列表中未包含强制算法，则会将其隐式添加到列表末尾以供选择。
The 64-bit MAC at the end of the message is computed across the whole message, not including the MAC, using the MAC algorithm defined in Section 5.1.2.2. The MAC key is the sender's H2 (defined in Section 9), and thus the MAC cannot be checked by the receiving party until the sender's H2 value is known to the receiving party later in the protocol.
使用第5.1.2.2节中定义的MAC算法，计算整个消息（不包括MAC）末尾的64位MAC。MAC密钥是发送方的H2（在第9节中定义），因此，在接收方在协议中知道发送方的H2值之前，接收方无法检查MAC。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Hello " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| version="1.10" (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Client Identifier (4 words) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Hash image H3 (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ZID (3 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|S|M|P| unused (zeros)| hc | cc | ac | kc | sc |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hash algorithms (0 to 7 values) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cipher algorithms (0 to 7 values) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| auth tag types (0 to 7 values) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Agreement Types (0 to 7 values) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SAS Types (0 to 7 values) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Hello " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| version="1.10" (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Client Identifier (4 words) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Hash image H3 (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ZID (3 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|S|M|P| unused (zeros)| hc | cc | ac | kc | sc |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hash algorithms (0 to 7 values) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cipher algorithms (0 to 7 values) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| auth tag types (0 to 7 values) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Agreement Types (0 to 7 values) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SAS Types (0 to 7 values) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Hello Message Format
图3：Hello消息格式
The HelloACK message is used to stop retransmissions of a Hello message. A HelloACK is sent regardless if the version number in the Hello is supported or the algorithm list supported. The receipt of a HelloACK stops retransmission of the Hello message. The format is shown in the figure below. A Commit message may be sent in place of a HelloACK by an Initiator, if a Commit message is ready to be sent promptly.
HelloACK消息用于停止Hello消息的重新传输。无论支持Hello中的版本号还是支持算法列表，都会发送HelloACK。收到HelloACK停止Hello消息的重新传输。格式如下图所示。如果提交消息已准备好立即发送，则发起方可以发送提交消息来代替HelloACK。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="HelloACK" (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="HelloACK" (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: HelloACK Message Format
图4:HelloACK消息格式
The Commit message is sent to initiate the key agreement process after both sides have received a Hello message, which means it can only be sent after receiving both a Hello message and a HelloACK message. There are three subtypes of Commit messages, whose formats are shown in Figures 5, 6, and 7.
在双方都收到Hello消息后，发送提交消息以启动密钥协商过程，这意味着只有在收到Hello消息和HelloACK消息后才能发送提交消息。提交消息有三个子类型，其格式如图5、6和7所示。
The Commit message contains the Message Type Block, then the 256-bit hash image H2, which is defined in Section 9. The next parameter is the initiator's ZID, the 96-bit-long unique identifier for the ZRTP endpoint, which MUST have the same value as was used in the Hello message.
提交消息包含消息类型块，然后是第9节中定义的256位哈希图像H2。下一个参数是启动器的ZID，ZRTP端点的96位长的唯一标识符，其值必须与Hello消息中使用的值相同。
Next, there is a list of algorithms selected by the initiator (hash, cipher, auth tag type, key agreement, sas type). For a DH Commit, the hash value hvi is a hash of the DHPart2 of the Initiator and the Responder's Hello message, as explained in Section 4.4.1.1.
接下来，是启动器选择的算法列表（哈希、密码、身份验证标记类型、密钥协议、sas类型）。对于DH提交，哈希值hvi是发起方的DHPart2和响应方的Hello消息的哈希，如第4.4.1.1节所述。
The 64-bit MAC at the end of the message is computed across the whole message, not including the MAC, using the MAC algorithm defined in Section 5.1.2.2. The MAC key is the sender's H1 (defined in Section 9), and thus the MAC cannot be checked by the receiving party until the sender's H1 value is known to the receiving party later in the protocol.
使用第5.1.2.2节中定义的MAC算法，计算整个消息（不包括MAC）末尾的64位MAC。MAC密钥是发送方的H1（在第9节中定义），因此，在接收方在协议中稍后知道发送方的H1值之前，接收方无法检查MAC。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=29 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Commit " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Hash image H2 (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ZID (3 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hash algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cipher algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| auth tag type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Agreement Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SAS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| hvi (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=29 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Commit " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Hash image H2 (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ZID (3 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hash algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cipher algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| auth tag type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Agreement Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SAS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| hvi (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: DH Commit Message Format
图5:DH提交消息格式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=25 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Commit " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Hash image H2 (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ZID (3 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hash algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cipher algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| auth tag type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Agreement Type = "Mult" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SAS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| nonce (4 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=25 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Commit " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Hash image H2 (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ZID (3 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hash algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cipher algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| auth tag type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Agreement Type = "Mult" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SAS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| nonce (4 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Multistream Commit Message Format
图6：多流提交消息格式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=27 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Commit " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Hash image H2 (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ZID (3 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hash algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cipher algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| auth tag type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Agreement Type = "Prsh" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SAS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| nonce (4 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| keyID (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=27 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Commit " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Hash image H2 (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ZID (3 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hash algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cipher algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| auth tag type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Agreement Type = "Prsh" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SAS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| nonce (4 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| keyID (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Preshared Commit Message Format
图7：预共享提交消息格式
The DHPart1 message shown in Figure 8 begins the DH exchange. It is sent by the Responder if a valid Commit message is received from the Initiator. The length of the pvr value and the length of the DHPart1 message depends on the Key Agreement Type chosen. This information is contained in the table in Section 5.1.5. Note that for both Multistream and Preshared modes, no DHPart1 or DHPart2 message will be sent.
图8所示的DHPart1消息开始DH交换。如果从启动器接收到有效的提交消息，则由响应程序发送。pvr值的长度和DHPart1消息的长度取决于选择的密钥协议类型。该信息包含在第5.1.5节的表格中。请注意，对于多流和预共享模式，不会发送DHPart1或DHPart2消息。
The 256-bit hash image H1 is defined in Section 9.
256位散列图像H1在第9节中定义。
The next four parameters are non-invertible hashes (computed in Section 4.3.1) of potential shared secrets used in generating the ZRTP secret s0. The first two, rs1IDr and rs2IDr, are the hashes of the responder's two retained shared secrets, truncated to 64 bits. Next, there is auxsecretIDr, a hash of the responder's auxsecret (defined in Section 4.3), truncated to 64 bits. The last parameter is a hash of the trusted MiTM PBX shared secret pbxsecret, defined in Section 7.3.1.
接下来的四个参数是用于生成ZRTP秘密s0的潜在共享秘密的不可逆散列（在第4.3.1节中计算）。前两个，rs1IDr和rs2IDr，是响应者两个保留的共享秘密的散列，被截断为64位。接下来是auxsecretIDr，响应者的auxsecret的散列（定义见第4.3节），被截断为64位。最后一个参数是第7.3.1节中定义的受信任的MiTM PBX共享机密pbxsecret的哈希。
The 64-bit MAC at the end of the message is computed across the whole message, not including the MAC, using the MAC algorithm defined in Section 5.1.2.2. The MAC key is the sender's H0 (defined in Section 9), and thus the MAC cannot be checked by the receiving party until the sender's H0 value is known to the receiving party later in the protocol.
使用第5.1.2.2节中定义的MAC算法，计算整个消息（不包括MAC）末尾的64位MAC。MAC密钥是发送方的H0（在第9节中定义），因此，在接收方在协议中知道发送方的H0值之前，接收方无法检查MAC。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=depends on KA Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="DHPart1 " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Hash image H1 (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rs1IDr (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rs2IDr (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| auxsecretIDr (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pbxsecretIDr (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| pvr (length depends on KA Type) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=depends on KA Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="DHPart1 " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Hash image H1 (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rs1IDr (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rs2IDr (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| auxsecretIDr (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pbxsecretIDr (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| pvr (length depends on KA Type) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: DHPart1 Message Format
图8:DHPart1消息格式
The DHPart2 message, shown in Figure 9, completes the DH exchange. It is sent by the Initiator if a valid DHPart1 message is received from the Responder. The length of the pvi value and the length of the DHPart2 message depends on the Key Agreement Type chosen. This information is contained in the table in Section 5.1.5. Note that for both Multistream and Preshared modes, no DHPart1 or DHPart2 message will be sent.
图9所示的DHPart2消息完成了DH交换。如果从响应程序接收到有效的DHPart1消息，则由启动器发送。pvi值的长度和DHPart2消息的长度取决于选择的密钥协议类型。该信息包含在第5.1.5节的表格中。请注意，对于多流和预共享模式，不会发送DHPart1或DHPart2消息。
The 256-bit hash image H1 is defined in Section 9.
256位散列图像H1在第9节中定义。
The next four parameters are non-invertible hashes (computed in Section 4.3.1) of potential shared secrets used in generating the ZRTP secret s0. The first two, rs1IDi and rs2IDi, are the hashes of the initiator's two retained shared secrets, truncated to 64 bits. Next, there is auxsecretIDi, a hash of the initiator's auxsecret (defined in Section 4.3), truncated to 64 bits. The last parameter is a hash of the trusted MiTM PBX shared secret pbxsecret, defined in Section 7.3.1.
接下来的四个参数是用于生成ZRTP秘密s0的潜在共享秘密的不可逆散列（在第4.3.1节中计算）。前两个，rs1IDi和rs2IDi，是启动器的两个保留共享机密的散列，被截断为64位。接下来是auxsecretIDi，启动器的auxsecret的散列（在第4.3节中定义），被截断为64位。最后一个参数是第7.3.1节中定义的受信任的MiTM PBX共享机密pbxsecret的哈希。
The 64-bit MAC at the end of the message is computed across the whole message, not including the MAC, using the MAC algorithm defined in Section 5.1.2.2. The MAC key is the sender's H0 (defined in Section 9), and thus the MAC cannot be checked by the receiving party until the sender's H0 value is known to the receiving party later in the protocol.
使用第5.1.2.2节中定义的MAC算法，计算整个消息（不包括MAC）末尾的64位MAC。MAC密钥是发送方的H0（在第9节中定义），因此，在接收方在协议中知道发送方的H0值之前，接收方无法检查MAC。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=depends on KA Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="DHPart2 " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Hash image H1 (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rs1IDi (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rs2IDi (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| auxsecretIDi (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pbxsecretIDi (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| pvi (length depends on KA Type) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=depends on KA Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="DHPart2 " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Hash image H1 (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rs1IDi (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rs2IDi (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| auxsecretIDi (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pbxsecretIDi (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| pvi (length depends on KA Type) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: DHPart2 Message Format
图9:DHPart2消息格式
The Confirm1 message is sent by the Responder in response to a valid DHPart2 message after the SRTP session key and parameters have been negotiated. The Confirm2 message is sent by the Initiator in response to a Confirm1 message. The format is shown in Figure 10. The message contains the Message Type Block "Confirm1" or "Confirm2". Next, there is the confirm_mac, a MAC computed over the encrypted part of the message (shown enclosed by "====" in Figure 10). This confirm_mac is keyed and computed according to Section 4.6. The next 16 octets contain the CFB Initialization Vector. The rest of the message is encrypted using CFB and protected by the confirm_mac.
在协商SRTP会话密钥和参数后，响应程序将发送Confirm1消息，以响应有效的DHPart2消息。Confirm2消息由启动器发送以响应Confirm1消息。格式如图10所示。该消息包含消息类型块“Confirm1”或“Confirm2”。接下来是confirm_mac，在消息的加密部分计算的mac（如图10中的“==”所示）。该确认mac根据第4.6节进行键控和计算。接下来的16个八位字节包含CFB初始化向量。消息的其余部分使用CFB加密，并由confirm_mac进行保护。
The first field inside the encrypted region is the hash preimage H0, which is defined in detail in Section 9.
加密区域内的第一个字段是散列预映像H0，其在第9节中详细定义。
The next 15 bits are not used and SHOULD be set to zero when sent and MUST be ignored when received in Confirm1 or Confirm2 messages.
接下来的15位不使用，发送时应设置为零，在Confirm1或Confirm2消息中接收时必须忽略。
The next 9 bits contain the signature length. If no SAS signature (described in Section 7.2) is present, all bits are set to zero. The signature length is in words and includes the signature type block. If the calculated signature octet count is not a multiple of 4, zeros are added to pad it out to a word boundary. If no signature is present, the overall length of the Confirm1 or Confirm2 message will be set to 19 words.
接下来的9位包含签名长度。如果不存在SAS签名（如第7.2节所述），则所有位均设置为零。签名长度以字为单位，包括签名类型块。如果计算出的签名八位组计数不是4的倍数，则添加零以将其填充到字边界。如果没有签名，Confirm1或Confirm2消息的总长度将设置为19个单词。
The next 8 bits are used for flags. Undefined flags are set to zero and ignored. Four flags are currently defined. The PBX Enrollment flag (E) is a Boolean bit defined in Section 7.3.1. The SAS Verified flag (V) is a Boolean bit defined in Section 7.1. The Allow Clear flag (A) is a Boolean bit defined in Section 4.7.2. The Disclosure Flag (D) is a Boolean bit defined in Section 11. The cache expiration interval is defined in Section 4.9.
接下来的8位用于标志。未定义的标志设置为零并被忽略。目前定义了四个标志。PBX注册标志（E）是第7.3.1节中定义的布尔位。SAS验证标志（V）是第7.1节中定义的布尔位。允许清除标志（A）是第4.7.2节中定义的布尔位。公开标志（D）是第11节中定义的布尔位。缓存过期时间间隔在第4.9节中定义。
If the signature length (in words) is non-zero, a signature type block will be present along with a signature block. Next, there is the signature block. The signature block includes the signature and the key (or a link to the key) used to generate the signature (Section 7.2).
如果签名长度（大写）不为零，则签名类型块将与签名块一起出现。接下来是签名块。签名块包括签名和用于生成签名的密钥（或密钥链接）（第7.2节）。
CFB mode [NIST-SP800-38A] is applied with a feedback length of 128 bits, a full cipher block, and the final block is truncated to match the exact length of the encrypted data. The CFB Initialization Vector is a 128-bit random nonce. The block cipher algorithm and the key size are the same as the negotiated block cipher (Section 5.1.3) for media encryption. CFB is used to encrypt the part of the Confirm1 message beginning after the CFB IV to the end of the message (the encrypted region is enclosed by "====" in Figure 10).
应用CFB模式[NIST-SP800-38A]，反馈长度为128位，为完整密码块，最后一个块被截断以匹配加密数据的精确长度。CFB初始化向量是128位随机nonce。分组密码算法和密钥大小与媒体加密的协商分组密码（第5.1.3节）相同。CFB用于加密Confirm1消息中从CFB IV之后开始到消息末尾的部分（加密区域由图10中的“==”括起）。
The responder uses the zrtpkeyr to encrypt the Confirm1 message. The initiator uses the zrtpkeyi to encrypt the Confirm2 message.
响应程序使用zrtpkeyr对Confirm1消息进行加密。启动器使用zrtpkeyi加密Confirm2消息。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Confirm1" or "Confirm2" (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| confirm_mac (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| CFB Initialization Vector (4 words) |
| |
| |
+===============================================================+
| |
| Hash preimage H0 (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused (15 bits of zeros) | sig len (9 bits)|0 0 0 0|E|V|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cache expiration interval (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional signature type block (1 word if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| optional signature block (variable length) |
| . . . |
| |
| |
+===============================================================+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Confirm1" or "Confirm2" (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| confirm_mac (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| CFB Initialization Vector (4 words) |
| |
| |
+===============================================================+
| |
| Hash preimage H0 (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused (15 bits of zeros) | sig len (9 bits)|0 0 0 0|E|V|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cache expiration interval (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional signature type block (1 word if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| optional signature block (variable length) |
| . . . |
| |
| |
+===============================================================+
Figure 10: Confirm1 and Confirm2 Message Format
图10:Confirm1和Confirm2消息格式
The Conf2ACK message is sent by the Responder in response to a valid Confirm2 message. The message format for the Conf2ACK is shown in the figure below. The receipt of a Conf2ACK stops retransmission of the Confirm2 message. Note that the first SRTP media (with a valid SRTP auth tag) from the responder also stops retransmission of the Confirm2 message.
Conf2ACK消息由响应者发送，以响应有效的Confirm2消息。Conf2ACK的消息格式如下图所示。收到Conf2ACK后，将停止Confirm2消息的重新传输。请注意，来自响应程序的第一个SRTP媒体（具有有效的SRTP auth标记）也会停止Confirm2消息的重新传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Conf2ACK" (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Conf2ACK" (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Conf2ACK Message Format
图11:Conf2ACK消息格式
The Error message is sent to terminate an in-process ZRTP key agreement exchange due to an error. The format is shown in the figure below. The use of the Error message is described in Section 4.7.1.
由于错误，发送错误消息以终止正在进行的ZRTP密钥协议交换。格式如下图所示。第4.7.1节描述了错误消息的使用。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=4 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Error " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer Error Code (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=4 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Error " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer Error Code (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Error Message Format
图12：错误消息格式
Defined hexadecimal values for the Error Code are listed in the table below.
下表列出了错误代码的定义十六进制值。
Error Code | Meaning
-----------------------------------------------------------
0x10 | Malformed packet (CRC OK, but wrong structure)
-----------------------------------------------------------
0x20 | Critical software error
-----------------------------------------------------------
0x30 | Unsupported ZRTP version
-----------------------------------------------------------
0x40 | Hello components mismatch
-----------------------------------------------------------
0x51 | Hash Type not supported
-----------------------------------------------------------
0x52 | Cipher Type not supported
-----------------------------------------------------------
0x53 | Public key exchange not supported
-----------------------------------------------------------
0x54 | SRTP auth tag not supported
-----------------------------------------------------------
0x55 | SAS rendering scheme not supported
-----------------------------------------------------------
0x56 | No shared secret available, DH mode required
-----------------------------------------------------------
0x61 | DH Error: bad pvi or pvr ( == 1, 0, or p-1)
-----------------------------------------------------------
0x62 | DH Error: hvi != hashed data
-----------------------------------------------------------
0x63 | Received relayed SAS from untrusted MiTM
-----------------------------------------------------------
0x70 | Auth Error: Bad Confirm pkt MAC
-----------------------------------------------------------
0x80 | Nonce reuse
-----------------------------------------------------------
0x90 | Equal ZIDs in Hello
-----------------------------------------------------------
0x91 | SSRC collision
-----------------------------------------------------------
0xA0 | Service unavailable
-----------------------------------------------------------
0xB0 | Protocol timeout error
-----------------------------------------------------------
0x100 | GoClear message received, but not allowed
-----------------------------------------------------------
Error Code | Meaning
-----------------------------------------------------------
0x10 | Malformed packet (CRC OK, but wrong structure)
-----------------------------------------------------------
0x20 | Critical software error
-----------------------------------------------------------
0x30 | Unsupported ZRTP version
-----------------------------------------------------------
0x40 | Hello components mismatch
-----------------------------------------------------------
0x51 | Hash Type not supported
-----------------------------------------------------------
0x52 | Cipher Type not supported
-----------------------------------------------------------
0x53 | Public key exchange not supported
-----------------------------------------------------------
0x54 | SRTP auth tag not supported
-----------------------------------------------------------
0x55 | SAS rendering scheme not supported
-----------------------------------------------------------
0x56 | No shared secret available, DH mode required
-----------------------------------------------------------
0x61 | DH Error: bad pvi or pvr ( == 1, 0, or p-1)
-----------------------------------------------------------
0x62 | DH Error: hvi != hashed data
-----------------------------------------------------------
0x63 | Received relayed SAS from untrusted MiTM
-----------------------------------------------------------
0x70 | Auth Error: Bad Confirm pkt MAC
-----------------------------------------------------------
0x80 | Nonce reuse
-----------------------------------------------------------
0x90 | Equal ZIDs in Hello
-----------------------------------------------------------
0x91 | SSRC collision
-----------------------------------------------------------
0xA0 | Service unavailable
-----------------------------------------------------------
0xB0 | Protocol timeout error
-----------------------------------------------------------
0x100 | GoClear message received, but not allowed
-----------------------------------------------------------
Table 8. ZRTP Error Codes
表8。ZRTP错误代码
The ErrorACK message is sent in response to an Error message. The receipt of an ErrorACK stops retransmission of the Error message. The format is shown in the figure below.
ErrorACK消息是响应错误消息而发送的。收到ErrorACK将停止错误消息的重新传输。格式如下图所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="ErrorACK" (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="ErrorACK" (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: ErrorACK Message Format
图13:ErrorACK消息格式
Support for the GoClear message is OPTIONAL in the protocol, and it is sent to switch from SRTP to RTP. The format is shown in the figure below. The clear_mac is used to authenticate the GoClear message so that bogus GoClear messages introduced by an attacker can be detected and discarded. The use of GoClear is described in Section 4.7.2.
对GoClear消息的支持在协议中是可选的，它被发送到从SRTP切换到RTP。格式如下图所示。clear_mac用于验证GoClear消息，以便检测并丢弃攻击者引入的伪造GoClear消息。第4.7.2节描述了GoClear的使用。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=5 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="GoClear " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| clear_mac (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=5 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="GoClear " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| clear_mac (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: GoClear Message Format
图14:GoClear消息格式
Support for the ClearACK message is OPTIONAL in the protocol, and it is sent to acknowledge receipt of a GoClear. A ClearACK is only sent if the clear_mac from the GoClear message is authenticated. Otherwise, no response is returned. The format is shown in the figure below.
对ClearACK消息的支持在协议中是可选的，发送该消息是为了确认收到了GoClear。只有来自GoClear消息的clear_mac经过身份验证时，才会发送ClearACK。否则，不会返回响应。格式如下图所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="ClearACK" (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="ClearACK" (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: ClearACK Message Format
图15:ClearACK消息格式
The SASrelay message is sent by a trusted MiTM, most often a PBX. It is not sent as a response to a packet, but is sent as a self-initiated packet by the trusted MiTM (Section 7.3). It can only be sent after the rest of the ZRTP key negotiations have completed, after the Confirm messages and their ACKs. It can only be sent after the trusted MiTM has finished key negotiations with the other party, because it is the other party's SAS that is being relayed. It is sent with retry logic until a RelayACK message (Section 5.14) is received or the retry schedule has been exhausted.
SASrelay消息由受信任的MiTM发送，通常是PBX。它不是作为对数据包的响应发送，而是由受信任的MiTM作为自启动数据包发送（第7.3节）。它只能在其他ZRTP密钥协商完成后，在确认消息及其ACK之后发送。它只能在受信任的MiTM完成与另一方的关键协商后发送，因为正在中继的是另一方的SA。它与重试逻辑一起发送，直到收到RelayACK消息（第5.14节）或重试计划已用尽。
If a device, usually a PBX, sends an SASrelay message, it MUST have previously declared itself as a MiTM device by setting the MiTM (M) flag in the Hello message (Section 5.2). If the receiver of the SASrelay message did not previously receive a Hello message with the MiTM (M) flag set, the Relayed SAS SHOULD NOT be rendered. A RelayACK is still sent, but no Error message is sent.
如果一个设备（通常是PBX）发送一个SASReal消息，那么它必须通过在Hello消息（第5.2节）中设置MiTM（M）标志来声明自己是一个MiTM设备。如果SASrelay消息的接收者之前没有收到设置了MiTM（M）标志的Hello消息，则不应呈现中继SA。仍会发送RelayACK，但不会发送错误消息。
The SASrelay message format is shown in Figure 16. The message contains the Message Type Block "SASrelay". Next, there is a MAC computed over the encrypted part of the message (shown enclosed by "====" in Figure 16). This MAC is keyed the same way as the confirm_mac in the Confirm messages (see Section 4.6). The next 16 octets contain the CFB Initialization Vector. The rest of the message is encrypted using CFB and protected by the MAC.
SASrelay消息格式如图16所示。该消息包含消息类型块“SASrelay”。接下来，在消息的加密部分计算MAC（如图16中的“==”所示）。该MAC的键控方式与确认消息中的确认MAC相同（见第4.6节）。接下来的16个八位字节包含CFB初始化向量。消息的其余部分使用CFB加密，并受MAC保护。
The next 15 bits are not used and SHOULD be set to zero when sent, and they MUST be ignored when received in SASrelay messages.
接下来的15位不使用，发送时应设置为零，在SASRepay消息中接收时必须忽略。
The next 9 bits contain the signature length. The trusted MiTM MAY compute a digital signature on the SAS hash, as described in Section 7.2, using a persistent signing key owned by the trusted MiTM. If no SAS signature is present, all bits are set to zero. The signature length is in words and includes the signature type block. If the calculated signature octet count is not a multiple of 4, zeros are added to pad it out to a word boundary. If no signature block is present, the overall length of the SASrelay message will be set to 19 words.
接下来的9位包含签名长度。如第7.2节所述，受信任的MiTM可以使用受信任的MiTM拥有的持久签名密钥在SAS哈希上计算数字签名。如果不存在SAS签名，则所有位都设置为零。签名长度以字为单位，包括签名类型块。如果计算出的签名八位组计数不是4的倍数，则添加零以将其填充到字边界。如果不存在签名块，SASrelay消息的总长度将设置为19个字。
The next 8 bits are used for flags. Undefined flags are set to zero and ignored. Three flags are currently defined. The Disclosure Flag (D) is a Boolean bit defined in Section 11. The Allow Clear flag (A) is a Boolean bit defined in Section 4.7.2. The SAS Verified flag (V) is a Boolean bit defined in Section 7.1. These flags are updated values to the same flags provided earlier in the Confirm message, but they are updated to reflect the new flag information relayed by the PBX from the other party.
接下来的8位用于标志。未定义的标志设置为零并被忽略。目前定义了三个标志。公开标志（D）是第11节中定义的布尔位。允许清除标志（A）是第4.7.2节中定义的布尔位。SAS验证标志（V）是第7.1节中定义的布尔位。这些标志的更新值与确认消息前面提供的标志相同，但它们被更新以反映PBX从另一方中继的新标志信息。
The next 32-bit word contains the SAS rendering scheme for the relayed sashash, which will be the same rendering scheme used by the other party on the other side of the trusted MiTM. Section 7.3 describes how the PBX determines whether the ZRTP client regards the PBX as a trusted MiTM. If the PBX determines that the ZRTP client trusts the PBX, the next 8 words contain the sashash relayed from the other party. The first 32-bit word of the sashash contains the sasvalue, which may be rendered to the user using the specified SAS rendering scheme. If this SASrelay message is being sent to a ZRTP client that does not trust this MiTM, the sashash will be ignored by the recipient and should be set to zeros by the PBX.
下一个32位字包含中继sashash的SAS呈现方案，该方案将与另一方在受信任MiTM的另一端使用的呈现方案相同。第7.3节描述了PBX如何确定ZRTP客户端是否将PBX视为受信任的MiTM。如果PBX确定ZRTP客户端信任PBX，则接下来的8个字包含从另一方中继的sashash。sassash的第一个32位字包含sasvalue，可以使用指定的SAS呈现方案将其呈现给用户。如果此SASrelay消息被发送到不信任此MiTM的ZRTP客户端，则收件人将忽略sashash，PBX应将其设置为零。
If the signature length (in words) is non-zero, a signature type block will be present along with a signature block. Next, there is the signature block. The signature block includes the signature and the key (or a link to the key) used to generate the signature (Section 7.2).
如果签名长度（大写）不为零，则签名类型块将与签名块一起出现。接下来是签名块。签名块包括签名和用于生成签名的密钥（或密钥链接）（第7.2节）。
CFB mode [NIST-SP800-38A] is applied with a feedback length of 128 bits, a full cipher block, and the final block is truncated to match the exact length of the encrypted data. The CFB Initialization Vector is a 128-bit random nonce. The block cipher algorithm and the key size is same as the negotiated block cipher (Section 5.1.3) for media encryption. CFB is used to encrypt the part of the SASrelay message beginning after the CFB IV to the end of the message (the encrypted region is enclosed by "====" in Figure 16).
应用CFB模式[NIST-SP800-38A]，反馈长度为128位，为完整密码块，最后一个块被截断以匹配加密数据的精确长度。CFB初始化向量是128位随机nonce。分组密码算法和密钥大小与媒体加密的协商分组密码（第5.1.3节）相同。CFB用于加密从CFB IV之后开始到消息末尾的SASrelay消息部分（加密区域由图16中的“==”括起）。
Depending on whether the trusted MiTM had taken the role of the initiator or the responder during the ZRTP key negotiation, the SASrelay message is encrypted with zrtpkeyi or zrtpkeyr.
根据受信任的MiTM在ZRTP密钥协商期间是担任发起方还是响应方的角色，SASReal消息将使用zrtpkeyi或zrtpkeyr进行加密。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="SASrelay" (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| CFB Initialization Vector (4 words) |
| |
| |
+===============================================================+
| Unused (15 bits of zeros) | sig len (9 bits)|0 0 0 0|0|V|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rendering scheme of relayed SAS (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Trusted MiTM relayed sashash (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional signature type block (1 word if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| optional signature block (variable length) |
| . . . |
| |
| |
+===============================================================+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="SASrelay" (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| CFB Initialization Vector (4 words) |
| |
| |
+===============================================================+
| Unused (15 bits of zeros) | sig len (9 bits)|0 0 0 0|0|V|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rendering scheme of relayed SAS (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Trusted MiTM relayed sashash (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional signature type block (1 word if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| optional signature block (variable length) |
| . . . |
| |
| |
+===============================================================+
Figure 16: SASrelay Message Format
图16:SASrelay消息格式
The RelayACK message is sent in response to a valid SASrelay message. The message format for the RelayACK is shown in the figure below. The receipt of a RelayACK stops retransmission of the SASrelay message.
RelayACK消息是响应有效的SASrelay消息而发送的。RelayACK的消息格式如下图所示。接收到中继确认后，将停止重新传输SASrelay消息。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="RelayACK" (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="RelayACK" (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: RelayACK Message Format
图17:RelayACK消息格式
The Ping and PingACK messages are unrelated to the rest of the ZRTP protocol. No ZRTP endpoint is required to generate a Ping message, but every ZRTP endpoint MUST respond to a Ping message with a PingACK message.
Ping和PingACK消息与ZRTP协议的其余部分无关。生成Ping消息不需要ZRTP端点，但每个ZRTP端点必须使用PingACK消息响应Ping消息。
Although Ping and PingACK messages have no effect on the rest of the ZRTP protocol, their inclusion in this specification simplifies the design of "bump-in-the-wire" ZRTP proxies (Section 10) (notably, [Zfone]). It enables proxies to be designed that do not rely on assistance from the signaling layer to map out the associations between media streams and ZRTP endpoints.
尽管Ping和PingACK消息对ZRTP协议的其余部分没有影响，但它们包含在本规范中简化了“线路中的凹凸”ZRTP代理的设计（第10节）（尤其是[Zfone]）。它使代理的设计不依赖于信令层的帮助来映射媒体流和ZRTP端点之间的关联。
Before sending a ZRTP Hello message, a ZRTP proxy MAY send a Ping message as a means to sort out which RTP media streams are connected to particular ZRTP endpoints. Ping messages are generated only by ZRTP proxies. If neither party is a ZRTP proxy, no Ping messages will be encountered. Ping retransmission behavior is discussed in Section 6.
在发送ZRTP Hello消息之前，ZRTP代理可以发送Ping消息作为一种手段，以确定哪些RTP媒体流连接到特定ZRTP端点。Ping消息仅由ZRTP代理生成。如果双方都不是ZRTP代理，则不会遇到Ping消息。Ping重传行为在第6节中讨论。
The Ping message (Figure 18) contains an "EndpointHash", defined in Section 5.16.
Ping消息（图18）包含第5.16节中定义的“EndpointHash”。
The Ping message contains a version number that defines what version of PingACK is requested. If that version number is supported by the Ping responder, a PingACK with a format that matches that version will be received. Otherwise, a PingACK with a lower version number may be received.
Ping消息包含一个版本号，该版本号定义了请求的PingACK版本。如果Ping响应程序支持该版本号，则将收到格式与该版本匹配的PingACK。否则，可能会收到版本号较低的PingACK。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=6 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Ping " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| version="1.10" (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EndpointHash (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=6 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Ping " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| version="1.10" (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EndpointHash (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Ping Message Format
图18:Ping消息格式
A PingACK message is sent only in response to a Ping. A ZRTP endpoint MUST respond to a Ping with a PingACK message. The version of PingACK requested is contained in the Ping message. If that version number is supported, a PingACK with a format that matches that version MUST be sent. Otherwise, if the version number of the Ping is not supported, a PingACK SHOULD be sent in the format of the highest supported version known to the Ping responder. Only version "1.10" is supported in this specification.
Ping确认消息仅在响应Ping时发送。ZRTP端点必须使用PingACK消息响应Ping。请求的PingACK版本包含在Ping消息中。如果支持该版本号，则必须发送格式与该版本匹配的PingACK。否则，如果不支持Ping的版本号，则应以Ping响应程序已知的最高支持版本的格式发送PingACK。本规范仅支持版本“1.10”。
The PingACK message carries its own 64-bit EndpointHash, distinct from the EndpointHash of the other party's Ping message. It is REQUIRED that it be highly improbable for two participants in a call to have the same EndpointHash and that an EndpointHash maintains a persistent value between calls. For a normal ZRTP endpoint, such as a ZRTP-enabled VoIP client, the EndpointHash can be just the truncated ZID. For a ZRTP endpoint such as a PBX that has multiple endpoints behind it, the EndpointHash must be a distinct value for each endpoint behind it. It is recommended that the EndpointHash be a truncated hash of the ZID of the ZRTP endpoint concatenated with something unique about the actual endpoint or phone behind the PBX. This may be the SIP URI of the phone, the PBX extension number, or the local IP address of the phone, whichever is more readily available in the application environment:
PingACK消息携带自己的64位EndpointHash，与另一方的Ping消息的EndpointHash不同。要求调用中的两个参与者不太可能拥有相同的EndpointHash，并且EndpointHash在调用之间保持一个持久值。对于普通的ZRTP端点，例如启用ZRTP的VoIP客户端，EndpointHash可以只是截断的ZID。对于ZRTP端点（如后面有多个端点的PBX），EndpointHash必须是后面每个端点的不同值。建议EndpointHash是ZRTP端点的ZID的截断散列，并与PBX后面的实际端点或电话的唯一性连接在一起。这可以是电话的SIP URI、PBX分机号码或电话的本地IP地址，以应用程序环境中更容易获得的为准：
EndpointHash = hash(ZID || SIP URI of the endpoint)
EndpointHash=hash（端点的ZID | | SIP URI）
EndpointHash = hash(ZID || PBX extension number of the endpoint)
EndpointHash=散列（端点的ZID | | PBX扩展号）
EndpointHash = hash(ZID || local IP address of the endpoint)
EndpointHash=散列（端点的ZID | |本地IP地址）
Any of these formulae confer uniqueness for the simple case of terminating the ZRTP connection at the VoIP client, or the more complex case of a PBX terminating the ZRTP connection for multiple VoIP phones in a conference call, all sharing the PBX's ZID, but with separate IP addresses behind the PBX. There is no requirement for the same hash function to be used by both parties.
这些公式中的任何一个都为在VoIP客户端终止ZRTP连接的简单情况，或PBX在一次会议通话中为多个VoIP电话终止ZRTP连接的更复杂情况提供了唯一性，所有这些电话都共享PBX的ZID，但在PBX后面有单独的IP地址。双方不需要使用相同的哈希函数。
The PingACK message contains the EndpointHash of the sender of the PingACK as well as the EndpointHash of the sender of the Ping. The Source Identifier (SSRC) received in the ZRTP header from the Ping packet (Figure 2) is copied into the PingACK message body (Figure 19). This SSRC is not the SSRC of the sender of the PingACK.
PingACK消息包含PingACK发送方的EndpointHash以及Ping发送方的EndpointHash。ZRTP报头中从Ping数据包（图2）接收到的源标识符（SSRC）被复制到PingACK消息体中（图19）。此SSRC不是PingACK发送方的SSRC。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=9 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="PingACK " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| version="1.10" (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EndpointHash of PingACK Sender (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EndpointHash of Received Ping (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Identifier (SSRC) of Received Ping (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=9 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="PingACK " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| version="1.10" (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EndpointHash of PingACK Sender (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EndpointHash of Received Ping (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Identifier (SSRC) of Received Ping (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: PingACK Message Format
图19:PingACK消息格式
ZRTP uses two retransmission timers T1 and T2. T1 is used for retransmission of Hello messages, when the support of ZRTP by the other endpoint may not be known. T2 is used in retransmissions of all the other ZRTP messages.
ZRTP使用两个重传定时器T1和T2。T1用于重传Hello消息，此时另一个端点对ZRTP的支持可能未知。T2用于所有其他ZRTP消息的重传。
All message retransmissions MUST be identical to the initial message including nonces, public values, etc; otherwise, hashes of the message sequences may not agree.
所有消息重传必须与初始消息相同，包括nonce、公共值等；否则，消息序列的散列可能不一致。
Practical experience has shown that RTP packet loss at the start of an RTP session can be extremely high. Since the entire ZRTP message exchange occurs during this period, the defined retransmission scheme
实践经验表明，RTP会话开始时的RTP数据包丢失可能非常高。由于整个ZRTP消息交换在此期间发生，因此定义的重传方案
is defined to be aggressive. Since ZRTP packets with the exception of the DHPart1 and DHPart2 messages are small, this should have minimal effect on overall bandwidth utilization of the media session.
被定义为具有侵略性。由于除了DHPart1和DHPart2消息之外，ZRTP数据包都很小，这对媒体会话的总体带宽利用率的影响应该最小。
ZRTP endpoints MUST NOT exceed the bandwidth of the resulting media session as determined by the offer/answer exchange in the signaling layer.
ZRTP端点不得超过由信令层中的提供/应答交换确定的结果媒体会话的带宽。
The Ping message (Section 5.15) may follow the same retransmission schedule as the Hello message, but this is not required in this specification. Ping message retransmission is subject to application-specific ZRTP proxy heuristics.
Ping消息（第5.15节）可能遵循与Hello消息相同的重传时间表，但本规范中不要求这样做。Ping消息重传受特定于应用程序的ZRTP代理启发。
Hello ZRTP messages are retransmitted at an interval that starts at T1 seconds and doubles after every retransmission, capping at 200 ms. T1 has a recommended initial value of 50 ms. A Hello message is retransmitted 20 times before giving up, which means the entire retry schedule for Hello messages is exhausted after 3.75 seconds (50 + 100 + 18*200 ms). Retransmission of a Hello ends upon receipt of a HelloACK or Commit message.
Hello ZRTP消息以从T1秒开始并在每次重新传输后加倍的间隔重新传输，上限为200毫秒。T1的建议初始值为50毫秒。Hello消息在放弃之前重新传输20次，这意味着Hello消息的整个重试计划在3.75秒后耗尽（50+100+18*200毫秒）。在收到HelloACK或Commit消息后，Hello的重新传输结束。
The post-Hello ZRTP messages are retransmitted only by the session initiator -- that is, only Commit, DHPart2, and Confirm2 are retransmitted if the corresponding message from the responder, DHPart1, Confirm1, and Conf2ACK, are not received. Note that the Confirm2 message retransmission can also be stopped by receiving the first SRTP media (with a valid SRTP auth tag) from the responder.
post Hello ZRTP消息仅由会话发起方重新传输——也就是说，如果未收到来自响应方DHPart1、Confirm1和Conf2ACK的相应消息，则仅重新传输Commit、DHPart2和Confirm2。请注意，还可以通过从响应者接收第一个SRTP媒体（具有有效的SRTP auth标记）来停止Confirm2消息重传。
The GoClear, Error, and SASrelay messages may be initiated and retransmitted by either party, and responded to by the other party, regardless of which party is the overall session initiator. They are retransmitted if the corresponding response message ClearACK, ErrorACK, and RelayACK are not received.
GoClear、Error和SASrelay消息可由任一方发起和重新传输，并由另一方响应，而不管哪一方是整个会话发起方。如果未收到相应的响应消息ClearACK、ErrorACK和RelayACK，则会重新传输这些消息。
Non-Hello (and non-Ping) ZRTP messages are retransmitted at an interval that starts at T2 seconds and doubles after every retransmission, capping at 1200 ms. T2 has a recommended initial value of 150 ms. Each non-Hello message is retransmitted 10 times before giving up, which means the entire retry schedule is exhausted after 9.45 seconds (150 + 300 + 600 + 7*1200 ms). Only the initiator performs retransmissions. Each message has a response message that stops retransmissions, as shown in the table below. The higher values of T2 means that retransmissions will likely occur only in the event of packet loss.
非Hello（和非Ping）ZRTP消息以T2秒开始的间隔重新传输，每次重新传输后加倍，上限为1200毫秒。T2的建议初始值为150毫秒。每个非Hello消息在放弃之前重新传输10次，这意味着整个重试计划在9.45秒后耗尽（150+300+600+7*1200毫秒）。只有发起方执行重传。每条消息都有一条停止重传的响应消息，如下表所示。T2的较高值意味着只有在数据包丢失的情况下才可能发生重传。
Message Acknowledgement Message
------- -----------------------
Hello HelloACK or Commit
Commit DHPart1 or Confirm1
DHPart2 Confirm1
Confirm2 Conf2ACK or SRTP media
GoClear ClearACK
Error ErrorACK
SASrelay RelayACK
Ping PingACK
Message Acknowledgement Message
------- -----------------------
Hello HelloACK or Commit
Commit DHPart1 or Confirm1
DHPart2 Confirm1
Confirm2 Conf2ACK or SRTP media
GoClear ClearACK
Error ErrorACK
SASrelay RelayACK
Ping PingACK
Table 9. Retransmitted ZRTP Messages and Responses
表9。重新传输的ZRTP消息和响应
The retry schedule must handle not only packet loss, but also slow or heavily loaded peers that need additional time to perform their DH calculations. The following mitigations are recommended:
重试计划不仅必须处理数据包丢失，还必须处理需要额外时间来执行DH计算的慢速或重载对等方。建议采取以下缓解措施：
o Slow or heavily loaded ZRTP endpoints that are at risk of taking too long to perform their DH calculation SHOULD use a HelloACK message instead of a Commit message to reply to a Hello from the other party.
o 缓慢或重载的ZRTP终结点可能会花费太长时间来执行DH计算，它们应该使用HelloACK消息而不是Commit消息来回复来自另一方的Hello。
o If a ZRTP endpoint has evidence that the other party is a ZRTP endpoint, by receiving a Hello message or Ping message, or by receiving a Hello Hash in the signaling layer, it SHOULD extend its own Hello retry schedule to span at least 12 seconds of retries. If this extended Hello retry schedule is exhausted without receiving a HelloACK or Commit message, a late Commit message from the peer SHOULD still be accepted.
o 如果ZRTP端点通过接收Hello消息或Ping消息，或通过在信令层接收Hello散列，有证据表明另一方是ZRTP端点，则它应该将自己的Hello重试计划扩展到至少12秒的重试时间。如果此扩展Hello重试计划在未收到HelloACK或Commit消息的情况下耗尽，则仍应接受来自对等方的延迟提交消息。
These recommended retransmission intervals are designed for a typical broadband Internet connection. In some high-latency communication channels, such as those provided by some mobile phone environments or geostationary satellites, a different retransmission schedule may be used. The initial value for the T1 or T2 retransmission timer should be increased to be no less than the round-trip time provided by the communications channel. It should take into account the time required to transmit the entire message and the entire reply, as well as a reasonable time estimate to perform the DH calculation.
这些建议的重传间隔是为典型的宽带互联网连接而设计的。在一些高延迟通信信道中，例如一些移动电话环境或地球静止卫星提供的信道，可以使用不同的重传时间表。T1或T2重传计时器的初始值应增加至不小于通信信道提供的往返时间。它应考虑传输整个消息和整个回复所需的时间，以及执行DH计算所需的合理时间估计。
ZRTP has its own retransmission schedule because it is carried along with RTP, usually over UDP. In unusual cases, RTP can run over a non-UDP transport, such as TCP or DCCP, which provides its own built-in retransmission mechanism. It may be hard for the ZRTP endpoint to detect that TCP is being used if media relays are involved. The ZRTP endpoint may be sending only UDP, but there may be a media relay along the media path that converts from UDP to TCP for part of the journey. Or, if the ZRTP endpoint is sending TCP,
ZRTP有自己的重传时间表，因为它通常通过UDP与RTP一起传输。在不常见的情况下，RTP可以在非UDP传输上运行，如TCP或DCCP，后者提供了自己的内置重传机制。如果涉及媒体中继，ZRTP端点可能很难检测到正在使用TCP。ZRTP端点可能只发送UDP，但在部分行程中，媒体路径上可能有一个从UDP转换为TCP的媒体中继。或者，如果ZRTP端点正在发送TCP，
the media relay might be converting from TCP to UDP. There have been empirical observations of this in the wild. In cases where TCP is used, ZRTP and TCP might together generate some extra retransmissions. It is tempting to avoid this effect by eliminating the ZRTP retransmission schedule when connected to a TCP channel, but that would risk failure of the protocol, because it may not be TCP all the way to the remote ZRTP endpoint. It only takes a few packets to complete a ZRTP exchange, so trying to optimize out the extra retransmissions in that scenario is not worth the risk.
媒体中继可能正在从TCP转换为UDP。在野外已经有了这方面的经验观察。在使用TCP的情况下，ZRTP和TCP可能一起产生一些额外的重传。当连接到TCP通道时，通过取消ZRTP重传计划来避免这种影响是很有诱惑力的，但这将有协议失败的风险，因为它可能不会一直到远程ZRTP端点。完成ZRTP交换只需要几个数据包，因此在这种情况下尝试优化额外的重传是不值得冒险的。
After receiving a Commit message, but before receiving a Confirm2 message, if a ZRTP responder receives no ZRTP messages for more than 10 seconds, the responder MAY send a protocol timeout Error message and terminate the ZRTP protocol.
在接收到提交消息之后，但在接收到Confirm2消息之前，如果ZRTP响应程序在超过10秒的时间内未接收到ZRTP消息，则响应程序可能会发送协议超时错误消息并终止ZRTP协议。
This section will discuss the implementation of the Short Authentication String, or SAS in ZRTP. The SAS can be verbally compared by the human users reading the string aloud, or it can be compared by validating an OPTIONAL digital signature (described in Section 7.2) exchanged in the Confirm1 or Confirm2 messages.
本节将讨论ZRTP中短身份验证字符串或SAS的实现。SAS可以由朗读字符串的人类用户进行口头比较，也可以通过验证Confirm1或Confirm2消息中交换的可选数字签名（如第7.2节所述）进行比较。
The use of hash commitment in the DH exchange (Section 4.4.1.1) constrains the attacker to only one guess to generate the correct SAS in his attack, which means the SAS can be quite short. A 16-bit SAS, for example, provides the attacker only one chance out of 65536 of not being detected. How the hash commitment enables the SAS to be so short is explained in Section 4.4.1.1.
DH交换中使用哈希承诺（第4.4.1.1节）将攻击者限制为仅猜测一次，以在其攻击中生成正确的SAS，这意味着SAS可能非常短。例如，16位SAS仅为攻击者提供65536个未被检测到的机会中的一个。第4.4.1.1节解释了哈希承诺如何使SAS如此短。
There is only one SAS value computed per call. That is the SAS value for the first media stream established, which is calculated in Section 4.5.2. This SAS applies to all media streams for the same session.
每次调用只计算一个SAS值。这是建立的第一个媒体流的SAS值，在第4.5.2节中计算。此SAS适用于同一会话的所有媒体流。
The SAS SHOULD be rendered to the user for authentication. The rendering of the SAS value through the user interface at both endpoints depends on the SAS Type agreed upon in the Commit message. See Section 5.1.6 for a description of how the SAS is rendered to the user.
SAS应呈现给用户进行身份验证。通过两个端点的用户界面呈现SAS值取决于提交消息中约定的SAS类型。有关如何向用户呈现SAS的说明，请参见第5.1.6节。
The SAS is not treated as a secret value, but it must be compared to see if it matches at both ends of the communications channel. The two users verbally compare it using their human voices, human ears, and human judgement. If it doesn't match, it indicates the presence of a MiTM attack.
SAS不被视为机密值，但必须对其进行比较，以查看其在通信信道两端是否匹配。这两位用户用他们的人声、人耳和人的判断口头比较。如果不匹配，则表示存在MiTM攻击。
It is worse than useless and absolutely unsafe to rely on a robot voice from the remote endpoint to compare the SAS, because a robot voice can be trivially forged by a MiTM. The SAS verbal comparison can only be done with a real live human at the remote endpoint.
依靠来自远程端点的机器人语音来比较SAS比无用和绝对不安全更糟糕，因为机器人语音可以被MiTM轻易伪造。SAS语言比较只能在远程端点与真实的人类进行。
The SAS Verified flag (V) is set based on the user indicating that SAS comparison has been successfully performed. The SAS Verified flag is exchanged securely in the Confirm1 and Confirm2 messages (Figure 10) of the next session. In other words, each party sends the SAS Verified flag from the previous session in the Confirm message of the current session. It is perfectly reasonable to have a ZRTP endpoint that never sets the SAS Verified flag, because it would require adding complexity to the user interface to allow the user to set it. The SAS Verified flag is not required to be set, but if it is available to the client software, it allows for the possibility that the client software could render to the user that the SAS verify procedure was carried out in a previous session.
SAS验证标志（V）根据指示已成功执行SAS比较的用户设置。SAS Verified标志在下一个会话的Confirm1和Confirm2消息（图10）中安全地交换。换句话说，各方在当前会话的确认消息中发送来自上一会话的SAS Verified标志。拥有一个从不设置SAS验证标志的ZRTP端点是完全合理的，因为它需要增加用户界面的复杂性以允许用户设置它。不需要设置SAS Verified（SAS验证）标志，但如果客户机软件可用，则允许客户机软件向用户显示SAS验证过程是在前一个会话中执行的。
Regardless of whether there is a user interface element to allow the user to set the SAS Verified flag, it is worth caching a shared secret, because doing so reduces opportunities for an attacker in the next call.
无论是否存在允许用户设置SAS验证标志的用户界面元素，缓存共享机密都是值得的，因为这样做会减少攻击者在下一次调用中的机会。
If at any time the users carry out the SAS comparison procedure, and it actually fails to match, then this means there is a very resourceful MiTM. If this is the first call, the MiTM was there on the first call, which is impressive enough. If it happens in a later call, it also means the MiTM must also know the cached shared secret, because you could not have carried out any voice traffic at all unless the session key was correctly computed and is also known to the attacker. This implies the MiTM must have been present in all the previous sessions, since the initial establishment of the first shared secret. This is indeed a resourceful attacker. It also means that if at any time he ceases his participation as a MiTM on one of your calls, the protocol will detect that the cached shared secret is no longer valid -- because it was really two different shared secrets all along, one of them between Alice and the attacker, and the other between the attacker and Bob. The continuity of the cached shared secrets makes it possible for us to detect the MiTM when he inserts himself into the ongoing relationship, as well as when he leaves. Also, if the attacker tries to stay with a long lineage of calls, but fails to execute a DH MiTM attack for even one missed call, he is permanently excluded. He can no longer resynchronize with the chain of cached shared secrets.
如果用户在任何时候执行SAS比较过程，但实际上不匹配，则这意味着有一个非常灵活的MiTM。如果这是第一次呼叫，那么MiTM在第一次呼叫时就在那里，这已经足够令人印象深刻了。如果发生在以后的呼叫中，这也意味着MiTM必须知道缓存的共享机密，因为除非会话密钥计算正确并且攻击者也知道，否则您根本无法执行任何语音通信。这意味着，自第一个共享秘密最初建立以来，MiTM必须已出现在之前的所有会话中。这的确是一个足智多谋的攻击者。这还意味着，如果他在任何时候停止作为MiTM参与您的一个呼叫，协议将检测到缓存的共享机密不再有效——因为它实际上一直是两个不同的共享机密，一个在Alice和攻击者之间，另一个在攻击者和Bob之间。缓存的共享秘密的连续性使我们能够在MiTM将自己插入正在进行的关系以及离开时检测到他。此外，如果攻击者试图保留一长串呼叫，但即使错过一个呼叫也无法执行DH MiTM攻击，则他将被永久排除在外。他无法再与缓存的共享机密链重新同步。
A user interface element (i.e., a checkbox or button) is needed to allow the user to tell the software the SAS verify was successful, causing the software to set the SAS Verified flag (V), which (together with our cached shared secret) obviates the need to perform the SAS procedure in the next call. An additional user interface element can be provided to let the user tell the software he detected an actual SAS mismatch, which indicates a MiTM attack. The software can then take appropriate action, clearing the SAS Verified flag, and erase the cached shared secret from this session. It is up to the implementer to decide if this added user interface complexity is warranted.
需要一个用户界面元素（即复选框或按钮）来允许用户告知软件SAS验证成功，从而使软件设置SAS验证标志（V），该标志（连同缓存的共享机密）无需在下一次调用中执行SAS过程。可以提供一个额外的用户界面元素，让用户告诉软件他检测到了实际的SAS不匹配，这表示MiTM攻击。然后，软件可以采取适当的操作，清除SAS验证标志，并从此会话中删除缓存的共享机密。这取决于实现者来决定是否需要增加用户界面的复杂性。
If the SAS matches, it means there is no MiTM, which also implies it is now safe to trust a cached shared secret for later calls. If inattentive users don't bother to check the SAS, it means we don't know whether there is or is not a MiTM, so even if we do establish a new cached shared secret, there is a risk that our potential attacker may have a subsequent opportunity to continue inserting himself in the call, until we finally get around to checking the SAS. If the SAS matches, it means no attacker was present for any previous session since we started propagating cached shared secrets, because this session and all the previous sessions were also authenticated with a continuous lineage of shared secrets.
如果SAS匹配，则意味着没有MiTM，这也意味着现在可以安全地信任缓存的共享机密以供以后调用。如果漫不经心的用户懒得检查SAS，这意味着我们不知道是否存在MiTM，因此即使我们确实建立了一个新的缓存共享机密，我们潜在的攻击者也有可能有机会继续在呼叫中插入自己，直到我们最终开始检查SAS。如果SAS匹配，则意味着自从我们开始传播缓存的共享机密以来，任何以前的会话都不存在攻击者，因为此会话和所有以前的会话也使用连续的共享机密血统进行了身份验证。
In most applications, it is desirable to avoid the added complexity of a PKI-backed digital signature, which is why ZRTP is designed not to require it. Nonetheless, in some applications, it may be hard to arrange for two human users to verbally compare the SAS. Or, an application may already be using an existing PKI and wants to use it to augment ZRTP.
在大多数应用中，希望避免PKI支持的数字签名增加复杂性，这就是ZRTP设计不需要它的原因。尽管如此，在某些应用程序中，可能很难安排两个人类用户口头比较SAS。或者，应用程序可能已经在使用现有的PKI，并希望使用它来扩充ZRTP。
To handle these cases, ZRTP allows for an OPTIONAL signature feature, which allows the SAS to be checked without human participation. The SAS MAY be signed and the signature sent inside the Confirm1, Confirm2 (Figure 10), or SASrelay (Figure 16) messages. The signature type (Section 5.1.7), length of the signature, and the key used to create the signature (or a link to it) are all sent along with the signature. The signature is calculated across the entire SAS hash result (sashash), from which the sasvalue was derived. The signatures exchanged in the encrypted Confirm1, Confirm2, or SASrelay messages MAY be used to authenticate the ZRTP exchange. A signature may be sent only in the initial media stream in a DH or ECDH ZRTP exchange, not in Multistream mode.
为了处理这些情况，ZRTP允许一个可选的签名功能，它允许在没有人参与的情况下检查SAS。可以对SAS进行签名，并在Confirm1、Confirm2（图10）或SASrelay（图16）消息中发送签名。签名类型（第5.1.7节）、签名长度和用于创建签名（或签名链接）的密钥都随签名一起发送。签名是在整个SAS哈希结果（sashash）中计算的，sashash值是从中派生的。在加密的Confirm1、Confirm2或SASrelay消息中交换的签名可用于认证ZRTP交换。签名只能在DH或ECDH ZRTP交换中的初始媒体流中发送，而不能在多流模式下发送。
Although the signature is sent, the material that is signed, the sashash, is not sent with it in the Confirm message, since both parties have already independently calculated the sashash. That is not the case for the SASrelay message, which must relay the sashash. To avoid unnecessary signature calculations, a signature SHOULD NOT be sent if the other ZRTP endpoint did not set the (S) flag in the Hello message (Section 5.2).
虽然签名已发送，但已签名的材料，即sashash，不会在确认消息中随签名一起发送，因为双方已独立计算sashash。SASrelay消息的情况并非如此，它必须中继sashash。为了避免不必要的签名计算，如果其他ZRTP端点未在Hello消息中设置（S）标志，则不应发送签名（第5.2节）。
Note that the choice of hash algorithm used in the digital signature is independent of the hash used in the sashash. The sashash is determined by the negotiated Hash Type (Section 5.1.2), while the hash used by the digital signature is separately defined by the digital signature algorithm. For example, the sashash may be based on SHA-256, while the digital signature might use SHA-384, if an ECDSA P-384 key is used.
请注意，数字签名中使用的哈希算法的选择与sashash中使用的哈希无关。sashash由协商的哈希类型确定（第5.1.2节），而数字签名使用的哈希由数字签名算法单独定义。例如，sashash可以基于SHA-256，而如果使用ECDSA P-384密钥，则数字签名可以使用SHA-384。
If the sashash (which is always truncated to 256 bits) is shorter than the signature hash, the security is not weakened because the hash commitment precludes the attacker from searching for sashash collisions.
如果sashash（总是被截断为256位）比签名散列短，则安全性不会减弱，因为散列承诺阻止攻击者搜索sashash冲突。
ECDSA algorithms may be used with either OpenPGP-formatted keys, or X.509v3 certificates. If the ZRTP key exchange is ECDH, and the SAS is signed, then the signature SHOULD be ECDSA, and SHOULD use the same size curve as the ECDH exchange if an ECDSA key of that size is available.
ECDSA算法可以与OpenPGP格式的密钥或X.509v3证书一起使用。如果ZRTP密钥交换为ECDH，且SAS已签名，则签名应为ECDSA，并且应使用与ECDH交换相同的大小曲线（如果该大小的ECDSA密钥可用）。
If a ZRTP endpoint supports incoming signatures (evidenced by setting the (S) flag in the Hello message), it SHOULD be able to parse signatures from the other endpoint in OpenPGP format and MUST be able to parse them in X.509v3 format. If the incoming signature is in an unsupported format, or the trust model does not lead to a trusted introducer or a trusted certificate authority (CA), another authentication method may be used if available, such as the SAS compare, or a cached shared secret from a previous session. If none of these methods are available, it is up to the ZRTP user agent and the user to decide whether to proceed with the call, after the user is informed.
如果ZRTP端点支持传入签名（通过在Hello消息中设置（S）标志来证明），那么它应该能够以OpenPGP格式解析来自其他端点的签名，并且必须能够以X.509v3格式解析它们。如果传入签名的格式不受支持，或者信任模型不会导致受信任的介绍人或受信任的证书颁发机构（CA），则可以使用另一种身份验证方法（如果可用），例如SAS比较，或来自上一会话的缓存共享机密。如果这些方法都不可用，则在通知用户后，由ZRTP用户代理和用户决定是否继续调用。
Both ECDSA and DSA [FIPS-186-3] have a feature that allows most of the signature calculation to be done in advance of the session, reducing latency during call setup. This is useful for low-power mobile handsets.
ECDSA和DSA[FIPS-186-3]都有一个功能，允许在会话之前完成大部分签名计算，从而减少呼叫设置过程中的延迟。这对于低功耗手机非常有用。
ECDSA is preferred because it has compact keys as well as compact signatures. If the signature along with its public key certificate are insufficiently compact, the Confirm message may become too long for the maximum transmission unit (MTU) size, and UDP fragmentation
ECDSA是首选，因为它具有紧凑的密钥和紧凑的签名。如果签名及其公钥证书不够紧凑，则确认消息对于最大传输单元（MTU）大小和UDP碎片可能会变得太长
may result. Some firewalls and NATs may discard fragmented UDP packets, which would cause the ZRTP exchange to fail. It is RECOMMENDED that a ZRTP endpoint avoid sending signatures if they would cause UDP fragmentation. For a discussion on MTU size and PMTU discovery, see [RFC1191] and [RFC1981].
可能会有结果。一些防火墙和NAT可能会丢弃分段的UDP数据包，这将导致ZRTP交换失败。如果签名会导致UDP碎片，建议ZRTP端点避免发送签名。有关MTU大小和PMTU发现的讨论，请参阅[RFC1191]和[RFC1981]。
From a packet-size perspective, ECDSA and DSA both produce equally compact signatures for a given signature strength. DSA keys are much bigger than ECDSA keys, but in the case of OpenPGP signatures, the public key is not sent along with the signature.
从数据包大小的角度来看，ECDSA和DSA都为给定的签名强度生成同样紧凑的签名。DSA密钥比ECDSA密钥大得多，但在OpenPGP签名的情况下，公钥不会与签名一起发送。
All signatures generated MUST use only NIST-approved hash algorithms, and MUST avoid using SHA1. This applies to both OpenPGP and X.509v3 signatures. NIST-approved hash algorithms are found in [FIPS-180-3] or its SHA-3 successor. All ECDSA curves used throughout this spec are over prime fields, drawn from Appendix D.1.2 of [FIPS-186-3].
生成的所有签名必须仅使用NIST批准的哈希算法，并且必须避免使用SHA1。这适用于OpenPGP和X.509v3签名。NIST批准的哈希算法见[FIPS-180-3]或其SHA-3后续版本。本规范中使用的所有ECDSA曲线均在基本字段上，从[FIPS-186-3]的附录D.1.2中绘制。
If the SAS Signature Type (Section 5.1.7) specifies an OpenPGP signature ("PGP "), the signature-related fields are arranged as follows.
如果SAS签名类型（第5.1.7节）指定了OpenPGP签名（“PGP”），则签名相关字段的排列如下。
The first field after the 4-octet Signature Type Block is the OpenPGP signature. The format of this signature and the algorithms that create it are specified by [RFC4880]. The signature is comprised of a complete OpenPGP version 4 signature in binary form (not Radix-64), as specified in RFC 4880, Section 5.2.3, enclosed in the full OpenPGP packet syntax. The length of the OpenPGP signature is parseable from the signature, and depends on the type and length of the signing key.
4-octet签名类型块之后的第一个字段是OpenPGP签名。[RFC4880]指定了该签名的格式和创建该签名的算法。该签名由完整的OpenPGP第4版二进制签名（非基数64）组成，如RFC 4880第5.2.3节所述，包含在完整的OpenPGP数据包语法中。OpenPGP签名的长度可以从签名中解析，并且取决于签名密钥的类型和长度。
If OpenPGP signatures are supported, an implementation SHOULD NOT generate signatures using any other signature algorithm except DSA or ECDSA (ECDSA is a reserved algorithm type in RFC 4880), but MAY accept other signature types from the other party. DSA signatures with keys shorter than 2048 bits or longer than 3072 bits MUST NOT be generated.
如果支持OpenPGP签名，则实现不应使用DSA或ECDSA以外的任何其他签名算法生成签名（ECDSA是RFC 4880中的保留算法类型），但可以接受来自另一方的其他签名类型。不得生成密钥小于2048位或大于3072位的DSA签名。
Implementers should be aware that ECDSA signatures for OpenPGP are expected to become available when the work in progress [ECC-OpenPGP] becomes an RFC. Any use of ECDSA signatures in ZRTP SHOULD NOT generate signatures using ECDSA key sizes other than P-224, P-256, and P-384, as defined in [FIPS-186-3].
实施者应该意识到，当正在进行的工作[ECC OpenPGP]成为RFC时，OpenPGP的ECDSA签名有望变得可用。ZRTP中ECDSA签名的任何使用都不应使用[FIPS-186-3]中定义的P-224、P-256和P-384以外的ECDSA密钥大小生成签名。
RFC 4880, Section 5.2.3.18, specifies a way to embed, in an OpenPGP signature, a URI of the preferred key server. The URI should be fully specified to obtain the public key of the signing key that created the signature. This URI MUST be present. It is up to the
RFC 4880第5.2.3.18节规定了在OpenPGP签名中嵌入首选密钥服务器URI的方法。应该完全指定URI以获取创建签名的签名密钥的公钥。此URI必须存在。这取决于
recipient of the signature to obtain the public key of the signing key and determine its validity status using the OpenPGP trust model discussed in [RFC4880].
签名接收者获取签名密钥的公钥，并使用[RFC4880]中讨论的OpenPGP信任模型确定其有效性状态。
The contents of Figure 20 lie inside the encrypted region of the Confirm message (Figure 10) or the SASrelay message (Figure 16).
图20的内容位于确认消息（图10）或SASrelay消息（图16）的加密区域内。
The total length of all the material in Figure 20, including the key server URI, must not exceed 511 32-bit words (2044 octets). This length, in words, is stored in the signature length field in the Confirm or SASrelay message containing the signature. It is desirable to avoid UDP fragmentation, so the URI should be kept short.
图20中所有材料（包括密钥服务器URI）的总长度不得超过511个32位字（2044个八位字节）。该长度（大写）存储在包含签名的确认或SASRepay消息中的签名长度字段中。希望避免UDP碎片，因此URI应该保持简短。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Type Block = "PGP " (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| OpenPGP signature |
| (variable length) |
| . . . |
| |
+===============================================================+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Type Block = "PGP " (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| OpenPGP signature |
| (variable length) |
| . . . |
| |
+===============================================================+
Figure 20: OpenPGP Signature Format
图20:OpenPGP签名格式
If the SAS Signature Type (Section 5.1.7) is "X509", the ECDSA signature-related fields are arranged as follows.
如果SAS签名类型（第5.1.7节）为“X509”，则ECDSA签名相关字段的排列如下。
The first field after the 4-octet Signature Type Block is the DER encoded X.509v3 certificate (the signed public key) of the ECDSA signing key that created the signature. The format of this certificate is specified by the NSA's Suite B Certificate and CRL Profile [RFC5759].
4-octet签名类型块后的第一个字段是创建签名的ECDSA签名密钥的DER编码的X.509v3证书（签名公钥）。此证书的格式由NSA的套件B证书和CRL配置文件[RFC5759]指定。
Following the X.509v3 certificate at the next word boundary is the ECDSA signature itself. The size of this field depends on the size and type of the public key in the aforementioned certificate. The format of this signature and the algorithms that create it are specified by [FIPS-186-3]. The signature is comprised of the ECDSA signature output parameters (r, s) in binary form, concatenated, in network byte order, with no truncation of leading zeros. The first half of the signature is r and the second half is s. If ECDSA P-256
在下一个字边界的X.509v3证书后面是ECDSA签名本身。此字段的大小取决于上述证书中公钥的大小和类型。[FIPS-186-3]规定了该签名的格式和生成该签名的算法。签名由二进制形式的ECDSA签名输出参数（r，s）组成，以网络字节顺序连接，不截断前导零。签名的前半部分是r，后半部分是s。如果ECDSA P-256
is specified, the signature fills 16 words (64 octets), 32 octets each for r and s. If ECDSA P-384 is specified, the signature fills 24 words (96 octets), 48 octets each for r and s.
如果指定，签名将填充16个字（64个八位字节），r和s各32个八位字节。如果指定了ECDSA P-384，签名将填充24个字（96个八位字节），r和s分别为48个八位字节。
It is up to the recipient of the signature to use information in the certificate and path discovery mechanisms to trace the chain back to the root CA. It is recommended that end user certificates issued for secure telephony should contain appropriate path discovery links to facilitate this.
由签名的接收者使用证书和路径发现机制中的信息将链追溯到根CA。建议为安全电话颁发的最终用户证书应包含适当的路径发现链接，以促进这一点。
Figure 21 shows a certificate and an ECDSA signature. All this material lies inside the encrypted region of the Confirm message (Figure 10) or the SASrelay message (Figure 16).
图21显示了证书和ECDSA签名。所有这些内容都位于确认消息（图10）或SASrelay消息（图16）的加密区域内。
The total length of all the material in Figure 21, including the X.509v3 certificate, must not exceed 511 32-bit words (2044 octets). This length, in words, is stored in the signature length field in the Confirm or SASrelay message containing the signature. It is desirable to avoid UDP fragmentation, so the certificate material should be kept to a much smaller size than this. End user certs issued for this purpose should minimize the size of extraneous material such as legal notices.
图21中所有材料（包括X.509v3证书）的总长度不得超过511个32位字（2044个八位字节）。该长度（大写）存储在包含签名的确认或SASRepay消息中的签名长度字段中。我们希望避免UDP碎片，因此证书材料的大小应该比这个小得多。为此目的颁发的最终用户证书应尽量减少法律通知等无关材料的大小。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Type Block = "X509" (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Signing key's X.509v3 certificate |
| (variable length) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ECDSA P-256 or P-384 signature |
| (16 words or 24 words) |
| . . . |
| |
+===============================================================+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Type Block = "X509" (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Signing key's X.509v3 certificate |
| (variable length) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ECDSA P-256 or P-384 signature |
| (16 words or 24 words) |
| . . . |
| |
+===============================================================+
Figure 21: X.509v3 ECDSA Signature Format
图21:X.509v3 ECDSA签名格式
It's not strictly necessary to use a PKI to back the public key that signs the SAS. For example, it is possible to use a self-signed X.509v3 certificate or an OpenPGP key that is not signed by any other
严格来说，没有必要使用PKI来支持为SAS签名的公钥。例如，可以使用自签名的X.509v3证书或未经任何其他人签名的OpenPGP密钥
key. In this scenario, the same key continuity technique used by SSH [RFC4251] may be used. The public key is cached locally the first time it is encountered, and when the same public key is encountered again in subsequent sessions, it's deemed not to be a MiTM attack. If there is no MiTM attack in the first session, there cannot be a MiTM attack in any subsequent session. This is exactly how SSH does it.
钥匙在此场景中，可以使用SSH[RFC4251]使用的相同密钥连续性技术。第一次遇到公钥时，它会在本地缓存，当在后续会话中再次遇到相同的公钥时，它不会被视为MiTM攻击。如果在第一个会话中没有MiTM攻击，则在任何后续会话中都不能有MiTM攻击。SSH就是这样做的。
Of course, the security rests on the assumption that the MiTM did not attack in the first session. That assumption seems to work most of the time in the SSH world. The user would have to be warned the first time a public key is encountered, just as in SSH. If possible, the SAS should be checked before the user consents to caching the new public key. If the SAS matches in the first session, there is no MiTM, and it's safe to cache the public key. If no SAS comparison is possible, it's up to the user, or up to the application, to decide whether to take a leap of faith and proceed. That's how SSH works most of the time, because SSH users don't have the chance to verbally compare an SAS with anyone.
当然，安全性建立在假设MiTM在第一次会话中没有攻击的基础上。在SSH世界中，这种假设似乎在大多数情况下都有效。第一次遇到公钥时，必须向用户发出警告，就像在SSH中一样。如果可能，应在用户同意缓存新公钥之前检查SAS。如果SAS在第一个会话中匹配，则不存在MiTM，可以安全地缓存公钥。如果不可能进行SAS比较，则由用户或应用程序决定是否进行信心飞跃并继续。这就是SSH在大多数情况下的工作方式，因为SSH用户没有机会口头将SAS与任何人进行比较。
For a phone that is SIP-registered to a PBX, it may be provisioned with the public key of the PBX, using a trusted automated provisioning process. Even without a PKI, the phone knows that the public key is the correct one, since it was provisioned into the phone by a trusted provisioning mechanism. This makes it easy for the phone to access several automated services commonly offered by a PBX, such as voice mail or a conference bridge, where there is no human at the PBX to do a verbal SAS compare. The same provisioning may be used to preload the pbxsecret into the phone, which is discussed in Section 7.3.1.
对于SIP注册到PBX的电话，可以使用受信任的自动配置过程，使用PBX的公钥对其进行配置。即使没有PKI，手机也知道公钥是正确的，因为它是通过可信的配置机制配置到手机中的。这使得手机可以轻松访问PBX通常提供的几种自动化服务，如语音邮件或会议桥，PBX没有人进行口头SAS比较。相同的配置可用于将PBX加密预加载到手机中，这将在第7.3.1节中讨论。
ZRTP is designed to use end-to-end encryption. The two parties' verbal comparison of the short authentication string (SAS) depends on this assumption. But in some PBX environments, such as Asterisk, there are usage scenarios that have the PBX acting as a trusted MiTM, which means there are two back-to-back ZRTP connections with separate session keys and separate SASs.
ZRTP设计为使用端到端加密。双方对短认证字符串（SAS）的口头比较取决于这一假设。但在某些PBX环境中，如Asterisk，存在将PBX用作受信任的MiTM的使用场景，这意味着有两个背对背的ZRTP连接，具有单独的会话密钥和单独的SAS。
For example, imagine that Bob has a ZRTP-enabled VoIP phone that has been registered with his company's PBX, so that it is regarded as an extension of the PBX. Alice, whose phone is not associated with the PBX, might dial the PBX from the outside, and a ZRTP connection is negotiated between her phone and the PBX. She then selects Bob's extension from the company directory in the PBX. The PBX makes a call to Bob's phone (which might be offsite, many miles away from the PBX through the Internet) and a separate ZRTP connection is
例如，假设Bob拥有一部支持ZRTP的VoIP电话，该电话已在其公司的PBX上注册，因此它被视为PBX的扩展。Alice的电话与PBX没有关联，她可能会从外部拨打PBX，她的电话和PBX之间会协商ZRTP连接。然后，她从PBX中的公司目录中选择Bob的扩展名。PBX拨打Bob的电话（可能在异地，通过互联网与PBX相距数英里），需要单独的ZRTP连接
negotiated between the PBX and Bob's phone. The two ZRTP sessions have different session keys and different SASs, which would render the SAS useless for verbal comparison between Alice and Bob. They might even mistakenly believe that a wiretapper is present because of the SAS mismatch, causing undue alarm.
在PBX和鲍勃的电话之间协商。这两个ZRTP会话具有不同的会话密钥和不同的SAS，这将使SAS无法用于Alice和Bob之间的口头比较。他们甚至可能错误地认为，由于SAS不匹配，存在窃听器，从而导致过度报警。
ZRTP has a mechanism for solving this problem by having the PBX relay the Alice/PBX SAS to Bob, sending it through to Bob in a special SASrelay message as defined in Section 5.13, which is sent after the PBX/Bob ZRTP negotiation is complete, after the Confirm messages. Only the PBX, acting as a special trusted MiTM (trusted by the recipient of the SASrelay message), will relay the SAS. The SASrelay message protects the relayed SAS from tampering via an included MAC, similar to how the Confirm message is protected. Bob's ZRTP-enabled phone accepts the relayed SAS for rendering only because Bob's phone had previously been configured to trust the PBX. This special trusted relationship with the PBX can be established through a special security enrollment procedure (Section 7.3.1). After that enrollment procedure, the PBX is treated by Bob as a special trusted MiTM. This results in Alice's SAS being rendered to Bob, so that Alice and Bob may verbally compare them and thus prevent a MiTM attack by any other untrusted MiTM.
ZRTP有一种解决此问题的机制，通过PBX将Alice/PBX SAS中继到Bob，并在第5.13节中定义的特殊SASLepay消息中发送给Bob，该消息在PBX/Bob ZRTP协商完成后，在确认消息后发送。只有PBX作为特殊的受信任MiTM（受SASrelay消息接收者的信任）将中继SAS。SASrelay消息通过包含的MAC保护中继SAS免受篡改，这与确认消息的保护方式类似。Bob的启用ZRTP的手机只接受中继SAS进行渲染，因为Bob的手机之前已配置为信任PBX。可通过特殊安全注册程序（第7.3.1节）建立与PBX的特殊信任关系。在该注册过程之后，Bob将PBX视为一个特殊的受信任的MiTM。这将导致Alice的SA呈现给Bob，以便Alice和Bob可以口头比较它们，从而防止任何其他不受信任的MiTM进行MiTM攻击。
A real "bad-guy" MiTM cannot exploit this protocol feature to mount a MiTM attack and relay Alice's SAS to Bob, because Bob has not previously carried out a special registration ritual with the bad guy. The relayed SAS would not be rendered by Bob's phone, because it did not come from a trusted PBX. The recognition of the special trust relationship is achieved with the prior establishment of a special shared secret between Bob and his PBX, which is called pbxsecret (defined in Section 7.3.1), also known as the trusted MiTM key.
真正的“坏家伙”MiTM不能利用此协议功能发起MiTM攻击并将Alice的SAS中继给Bob，因为Bob之前没有与坏家伙进行过特殊的注册仪式。中继SAS不会由Bob的手机呈现，因为它不是来自受信任的PBX。特殊信任关系的识别是通过在Bob和他的PBX之间预先建立一个特殊的共享秘密来实现的，该秘密称为pbxsecret（定义见第7.3.1节），也称为受信任的MiTM密钥。
The trusted MiTM key can be stored in a special cache at the time of the initial enrollment (which is carried out only once for Bob's phone), and Bob's phone associates this key with the ZID of the PBX, while the PBX associates it with the ZID of Bob's phone. After the enrollment has established and stored this trusted MiTM key, it can be detected during subsequent ZRTP session negotiations between the PBX and Bob's phone, because the PBX and the phone MUST pass the hash of the trusted MiTM key in the DH message. It is then used as part of the key agreement to calculate s0.
受信任的MiTM密钥可以在初始注册时存储在特殊缓存中（对于Bob的手机只执行一次），Bob的手机将此密钥与PBX的ZID关联，而PBX将其与Bob手机的ZID关联。注册建立并存储此受信任的MiTM密钥后，由于PBX和电话必须在DH消息中传递受信任的MiTM密钥的哈希，因此在PBX和Bob的电话之间的后续ZRTP会话协商期间可以检测到该密钥。然后将其用作密钥协议的一部分，以计算s0。
The PBX can determine whether it is trusted by the ZRTP user agent of a phone. The presence of a shared trusted MiTM key in the key negotiation sequence indicates that the phone has been enrolled with this PBX and therefore trusts it to act as a trusted MiTM. During a key agreement with two other ZRTP endpoints, the PBX may have a
PBX可以确定电话的ZRTP用户代理是否信任它。密钥协商序列中存在共享的受信任的MiTM密钥表示手机已注册到此PBX，因此信任它充当受信任的MiTM。在与其他两个ZRTP端点的密钥协议期间，PBX可能具有
shared trusted MiTM key with both endpoints, only one endpoint, or neither endpoint. If the PBX has a shared trusted MiTM key with neither endpoint, the PBX MUST NOT relay the SAS. If the PBX has a shared trusted MiTM key with only one endpoint, the PBX MUST relay the SAS from one party to the other by sending an SASrelay message to the endpoint with which it shares a trusted MiTM key. If the PBX has a (separate) shared trusted MiTM key with each of the endpoints, the PBX MUST relay the SAS to only one endpoint, not both endpoints.
与两个端点、仅一个端点或两个端点都不共享受信任的MiTM密钥。如果PBX有一个共享的受信任的MiTM密钥，且没有端点，则PBX不得中继SAS。如果PBX只有一个端点具有共享的受信任MiTM密钥，则PBX必须通过向与之共享受信任MiTM密钥的端点发送SASLepay消息，将SAS从一方中继到另一方。如果PBX与每个端点具有（单独的）共享受信任MiTM密钥，则PBX必须仅将SAS中继到一个端点，而不是两个端点。
Note: In the case of a PBX sharing trusted MiTM keys with both endpoints, it does not matter which endpoint receives the relayed SAS as long as only one endpoint receives it.
注意：在PBX与两个端点共享受信任的MiTM密钥的情况下，哪一个端点接收中继SA并不重要，只要只有一个端点接收它。
The relayed SAS fields contain the SAS rendering type and the complete sashash. The receiver absolutely MUST NOT render the relayed SAS if it does not come from a specially trusted ZRTP endpoint. The security of the ZRTP protocol depends on not rendering a relayed SAS from an untrusted MiTM, because it may be relayed by a MiTM attacker. See the SASrelay message definition (Figure 16) for further details.
中继SAS字段包含SAS渲染类型和完整的sashash。如果中继SA不是来自特别受信任的ZRTP端点，则接收器绝对不能呈现中继SA。ZRTP协议的安全性取决于不呈现来自不受信任的MiTM的中继SAS，因为它可能由MiTM攻击者中继。有关更多详细信息，请参见SASrelay消息定义（图16）。
To ensure that both Alice and Bob will use the same SAS rendering scheme after the keys are negotiated, the PBX also sends the SASrelay message to the unenrolled party (which does not regard this PBX as a trusted MiTM), conveying the SAS rendering scheme, but not the sashash, which it sets to zero. The unenrolled party will ignore the relayed SAS field, but will use the specified SAS rendering scheme.
为了确保Alice和Bob在协商密钥后使用相同的SAS呈现方案，PBX还将SASrelay消息发送给未注册方（未注册方不将此PBX视为受信任的MiTM），传递SAS呈现方案，但不传递sashash，它将sashash设置为零。未滚动方将忽略中继SAS字段，但将使用指定的SAS呈现方案。
It is possible to route a call through two ZRTP-enabled PBXs using this scheme. Assume Alice is a ZRTP endpoint who trusts her local PBX in Atlanta, and Bob is a ZRTP endpoint who trusts his local PBX in Biloxi. The call is routed from Alice to the Atlanta PBX to the Biloxi PBX to Bob. Atlanta would relay the Atlanta-Biloxi SAS to Alice because Alice is enrolled with Atlanta, and Biloxi would relay the Atlanta-Biloxi SAS to Bob because Bob is enrolled with Biloxi. The two PBXs are not assumed to be enrolled with each other in this example. Both Alice and Bob would view and verbally compare the same relayed SAS, the Atlanta-Biloxi SAS. No more than two trusted MiTM nodes can be traversed with this relaying scheme. This behavior is extended to two PBXs that are enrolled with each other, via this rule: In the case of a PBX sharing trusted MiTM keys with both endpoints (i.e., both enrolled with this PBX), one of which is another PBX (evidenced by the M-flag) and one of which is a non-PBX, the MiTM PBX must always relay the PBX-to-PBX SAS to the non-PBX endpoint.
使用此方案可以通过两个启用ZRTP的PBX路由呼叫。假设Alice是信任亚特兰大本地PBX的ZRTP端点，Bob是信任Biloxi本地PBX的ZRTP端点。呼叫从Alice转接至亚特兰大PBX，再转接至Biloxi PBX，再转接至Bob。亚特兰大将亚特兰大比洛克西SAS转播给爱丽丝，因为爱丽丝在亚特兰大注册，而比洛克西将亚特兰大比洛克西SAS转播给鲍勃，因为鲍勃在比洛克西注册。在本例中，不假设两个PBX彼此注册。Alice和Bob都会查看和口头比较相同的中继SAS，亚特兰大比洛克西SAS。使用此中继方案最多可以遍历两个受信任的MiTM节点。通过此规则，此行为扩展到相互注册的两个PBX：在PBX与两个端点共享受信任的MiTM密钥的情况下（即，都与此PBX注册），其中一个是另一个PBX（由M标志证明），另一个是非PBX，MiTM PBX必须始终将PBX到PBX SAS中继到非PBX端点。
A ZRTP endpoint phone that trusts a PBX to act as a trusted MiTM is effectively delegating its own policy decisions of algorithm negotiation to the PBX.
信任PBX充当受信任MiTM的ZRTP端点电话有效地将其自己的算法协商策略决策委托给PBX。
When a PBX is between two ZRTP endpoints and is terminating their media streams at the PBX, the PBX presents its own ZID to the two parties, eclipsing the ZIDs of the two parties from each other. For example, if several different calls are routed through such a PBX to several different ZRTP-enabled phones behind the PBX, only a single ZID is presented to the calling party in every case -- the ZID of the PBX itself.
当PBX位于两个ZRTP端点之间并且在PBX处终止其媒体流时，PBX向双方呈现其自己的ZID，使双方的ZID相互重叠。例如，如果几个不同的呼叫通过这样的PBX路由到PBX后面的几个不同的支持ZRTP的电话，那么在每种情况下，只有一个ZID呈现给主叫方——PBX本身的ZID。
The next section describes the initial enrollment procedure that establishes a special shared secret, a trusted MiTM key, between a PBX and a phone, so that the phone will learn to recognize the PBX as a trusted MiTM.
下一节将描述初始注册过程，该过程在PBX和电话之间建立一个特殊的共享密钥，即可信的MiTM密钥，以便电话将学习将PBX识别为可信的MiTM。
Both the PBX and the endpoint need to know when enrollment is taking place. One way of doing this is to set up an enrollment extension on the PBX that a newly configured endpoint would call and establish a ZRTP session. The PBX would then play audio media that offers the user an opportunity to configure his phone to trust this PBX as a trusted MiTM. The PBX calculates and stores the trusted MiTM shared secret in its cache and associates it with this phone, indexed by the phone's ZID. The trusted MiTM PBX shared secret is derived from ZRTPSess via the ZRTP key derivation function (Section 4.5.1) in this manner:
PBX和端点都需要知道何时进行注册。一种方法是在PBX上设置注册扩展，新配置的端点将调用该扩展并建立ZRTP会话。然后，PBX将播放音频媒体，用户有机会将其手机配置为信任此PBX作为受信任的MiTM。PBX计算并将受信任的MiTM共享机密存储在其缓存中，并将其与此手机关联，该手机的ZID为其编制索引。受信任的MiTM PBX共享密钥通过ZRTP密钥派生函数（第4.5.1节）以以下方式从ZRTPSES派生：
pbxsecret = KDF(ZRTPSess, "Trusted MiTM key", (ZIDi || ZIDr), 256)
pbxsecret=KDF（Zrtpses，“可信的MiTM密钥”（ZIDi | | ZIDr），256）
The pbxsecret is calculated for the whole ZRTP session, not for each stream within a session, thus the KDF Context field in this case does not include any stream-specific nonce material.
pbxsecret是为整个ZRTP会话计算的，而不是为会话中的每个流计算的，因此本例中的KDF上下文字段不包括任何特定于流的nonce材料。
The PBX signals the enrollment process by setting the PBX Enrollment flag (E) in the Confirm message (Figure 10). This flag is used to trigger the ZRTP endpoint's user interface to prompt the user to see if it wants to trust this PBX and calculate and store the pbxsecret in the cache. If the user decides to respond by activating the appropriate user interface element (a menu item, checkbox, or button), his ZRTP user agent calculates pbxsecret using the same formula, and saves it in a special cache entry associated with this PBX.
PBX通过在确认消息中设置PBX注册标志（E）来向注册过程发送信号（图10）。此标志用于触发ZRTP端点的用户界面，以提示用户是否希望信任此PBX，并计算pbxsecret并将其存储在缓存中。如果用户决定通过激活相应的用户界面元素（菜单项、复选框或按钮）进行响应，则其ZRTP用户代理将使用相同的公式计算pbxsecret，并将其保存在与此PBX关联的特殊缓存条目中。
During a PBX enrollment, the GoClear features are disabled. If the (E) flag is set by the PBX, the PBX MUST NOT set the Allow Clear (A) flag. Thus, (E) implies not (A). If a received Confirm message has the (E) flag set, the (A) flag MUST be disregarded and treated as false.
在PBX注册期间，GoClear功能被禁用。如果PBX设置了（E）标志，则PBX不得设置允许清除（A）标志。因此，（E）并不意味着（A）。如果收到的确认消息设置了（E）标志，则必须忽略（a）标志并将其视为false。
If the user elects not to enroll, perhaps because he dialed a wrong number or does not yet feel comfortable with this PBX, he can simply hang up and not save the pbxsecret in his cache. The PBX will have it saved in the PBX cache, but that will do no harm. The SASrelay scheme does not depend on the PBX trusting the phone. It only depends on the phone trusting the PBX. It is the phone (the user) who is at risk if the PBX abuses its MiTM privileges.
如果用户选择不注册，可能是因为他拨错了号码，或者对这个PBX感到不舒服，他可以简单地挂断电话，而不将PBX密钥保存在缓存中。PBX会将其保存在PBX缓存中，但这不会造成任何伤害。SASrelay方案不依赖于PBX信任手机。这只取决于电话是否信任PBX。如果PBX滥用其MiTM特权，则手机（用户）将面临风险。
An endpoint MUST NOT store the pbxsecret in the cache without explicit user authorization.
未经明确的用户授权，端点不得将pbxsecret存储在缓存中。
After this enrollment process, the PBX and the ZRTP-enabled phone both share a secret that enables the phone to recognize the PBX as a trusted MiTM in future calls. This means that when a future call from an outside ZRTP-enabled caller is relayed through the PBX to this phone, the phone will render a relayed SAS from the PBX. If the SASrelay message comes from a MiTM that does not know the pbxsecret, the phone treats it as a bad-guy MiTM, and refuses to render the relayed SAS. Regardless of which party initiates any future phone calls through the PBX, the enrolled phone or the outside phone, the PBX will relay the SAS to the enrolled phone.
在此注册过程之后，PBX和启用ZRTP的手机都共享一个秘密，使手机能够在未来的通话中将PBX识别为受信任的MiTM。这意味着，当来自支持ZRTP的外部呼叫方的未来呼叫通过PBX中继到此电话时，电话将呈现来自PBX的中继SAS。如果SASrelay消息来自不知道PBX机密的MiTM，则手机会将其视为坏人MiTM，并拒绝呈现中继的SAS。无论哪一方通过PBX、注册电话或外部电话发起任何未来的电话呼叫，PBX都会将SAS中继到注册电话。
This enrollment procedure is designed primarily for phones that are already associated with the PBX -- enterprise phones that are "behind" the PBX. It is not intended for the countless outside phones that are not registered to this PBX's SIP server. It should be regarded as part of the installation and provisioning process for a new phone in the organization.
此注册过程主要设计用于已与PBX关联的电话，即“在”PBX后面的企业电话。它不适用于无数未注册到此PBX SIP服务器的外部电话。应将其视为组织中新电话安装和配置过程的一部分。
There are more streamlined methods to configure ZRTP user agents to trust a PBX. In large scale deployments, the pbxsecret may be configured into the phone by an automated provisioning process, which may be less burdensome for the users and less error prone. This specification does not require a manual enrollment process. Any process that results in a pbxsecret to be computed and shared between the PBX and the phone will suffice, as long as the user is made aware that this puts the PBX in a position to wiretap the calls.
有更多优化的方法来配置ZRTP用户代理以信任PBX。在大规模部署中，可以通过自动资源调配过程将PBX加密配置到手机中，这可能会减少用户负担，也不容易出错。本规范不需要手动注册过程。只要用户意识到这会使PBX处于窃听呼叫的位置，任何导致PBX秘密在PBX和手机之间被计算和共享的过程就足够了。
It is recommended that a ZRTP client not proceed with the PBX enrollment procedure without evidence that a MiTM attack is not taking place during the enrollment session. It would be especially damaging if a MiTM tricks the client into enrolling with the wrong
如果没有证据表明注册会话期间未发生MiTM攻击，建议ZRTP客户端不要继续PBX注册过程。如果MiTM欺骗客户以错误的方式注册，这将特别有害
PBX. That would enable the malevolent MiTM to wiretap all future calls without arousing suspicion, because he would appear to be trusted.
PBX。这将使恶意的MiTM能够在不引起怀疑的情况下窃听所有未来的电话，因为他看起来是可信的。
This section discusses how ZRTP, SIP, and SDP work together.
本节讨论ZRTP、SIP和SDP如何协同工作。
Note that ZRTP may be implemented without coupling with the SIP signaling. For example, ZRTP can be implemented as a "bump in the wire" or as a "bump in the stack" in which RTP sent by the SIP User Agent (UA) is converted to ZRTP. In these cases, the SIP UA will have no knowledge of ZRTP. As a result, the signaling path discovery mechanisms introduced in this section should not be definitive -- they are a hint. Despite the absence of an indication of ZRTP support in an offer or answer, a ZRTP endpoint SHOULD still send Hello messages.
注意，ZRTP可以在不与SIP信令耦合的情况下实现。例如，ZRTP可以实现为“线路中的凹凸”或“堆栈中的凹凸”，其中由SIP用户代理（UA）发送的RTP被转换为ZRTP。在这些情况下，SIP UA将不了解ZRTP。因此，本节介绍的信令路径发现机制不应该是确定的——它们只是一个提示。尽管在报价或应答中没有ZRTP支持的指示，ZRTP端点仍应发送Hello消息。
ZRTP endpoints that have control over the signaling path include a ZRTP SDP attributes in their SDP offers and answers. The ZRTP attribute, a=zrtp-hash, is used to indicate support for ZRTP and to convey a hash of the Hello message. The hash is computed according to Section 8.1.
控制信令路径的ZRTP端点在其SDP提供和应答中包括ZRTP SDP属性。ZRTP属性a=ZRTP散列用于表示对ZRTP的支持，并传递Hello消息的散列。散列根据第8.1节计算。
Aside from the advantages described in Section 8.1, there are a number of potential uses for this attribute. It is useful when signaling elements would like to know when ZRTP may be utilized by endpoints. It is also useful if endpoints support multiple methods of SRTP key management. The ZRTP attribute can be used to ensure that these key management approaches work together instead of against each other. For example, if only one endpoint supports ZRTP, but both support another method to key SRTP, then the other method will be used instead. When used in parallel, an SRTP secret carried in an a=keymgt [RFC4567] or a=crypto [RFC4568] attribute can be used as a shared secret for the srtps computation defined in Section 8.2. The ZRTP attribute is also used to signal to an intermediary ZRTP device not to act as a ZRTP endpoint, as discussed in Section 10.
除了第8.1节所述的优点外，该属性还有许多潜在用途。当信令元素希望知道端点何时可以使用ZRTP时，这是有用的。如果端点支持多种SRTP密钥管理方法，那么它也很有用。ZRTP属性可用于确保这些密钥管理方法协同工作，而不是相互对抗。例如，如果只有一个端点支持ZRTP，但两个端点都支持另一个方法来为SRTP设置密钥，那么将使用另一个方法。当并行使用时，a=keymgt[RFC4567]或a=crypto[RFC4568]属性中携带的SRTP秘密可以用作第8.2节中定义的srtps计算的共享秘密。如第10节所述，ZRTP属性还用于向中间ZRTP设备发出不充当ZRTP端点的信号。
The a=zrtp-hash attribute can only be included in the SDP at the media level since Hello messages sent in different media streams will have unique hashes.
a=zrtp散列属性只能包含在SDP的媒体级别，因为在不同媒体流中发送的Hello消息将具有唯一的散列。
The ABNF for the ZRTP attribute is as follows:
ZRTP属性的ABNF如下所示：
zrtp-attribute = "a=zrtp-hash:" zrtp-version zrtp-hash-value
zrtp-attribute = "a=zrtp-hash:" zrtp-version zrtp-hash-value
zrtp-version = token
zrtp-version = token
zrtp-hash-value = 1*(HEXDIG)
zrtp-hash-value = 1*(HEXDIG)
Here's an example of the ZRTP attribute in an initial SDP offer or answer used at the media level, using the <allOneLine> convention defined in RFC 4475, Section 2.1 [RFC4475]:
以下是使用RFC 4475第2.1节[RFC4475]中定义的<allOneLine>约定在媒体级别使用的初始SDP报价或应答中的ZRTP属性示例：
v=0
o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
s=
c=IN IP4 client.biloxi.example.com
t=0 0
m=audio 3456 RTP/AVP 97 33
a=rtpmap:97 iLBC/8000
a=rtpmap:33 no-op/8000
<allOneLine>
a=zrtp-hash:1.10 fe30efd02423cb054e50efd0248742ac7a52c8f91bc2
df881ae642c371ba46df
</allOneLine>
v=0
o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
s=
c=IN IP4 client.biloxi.example.com
t=0 0
m=audio 3456 RTP/AVP 97 33
a=rtpmap:97 iLBC/8000
a=rtpmap:33 no-op/8000
<allOneLine>
a=zrtp-hash:1.10 fe30efd02423cb054e50efd0248742ac7a52c8f91bc2
df881ae642c371ba46df
</allOneLine>
A mechanism for carrying this same zrtp-hash information in the Jingle signaling protocol is defined in [XEP-0262].
[XEP-0262]中定义了在叮当信令协议中承载相同zrtp哈希信息的机制。
It should be safe to send ZRTP messages even when there is no evidence in the signaling that the other party supports it, because ZRTP has been designed to be clearly different from RTP, having a similar structure to STUN packets sent during an ICE exchange.
即使在信令中没有证据表明另一方支持ZRTP消息，发送ZRTP消息也应该是安全的，因为ZRTP的设计明显不同于RTP，具有类似于在ICE交换期间发送的STUN数据包的结构。
Tying the media stream to the signaling channel can help prevent a third party from inserting false media packets. If the signaling layer contains information that ties it to the media stream, false media streams can be rejected.
将媒体流绑定到信令信道有助于防止第三方插入虚假媒体分组。如果信令层包含将其绑定到媒体流的信息，则可以拒绝虚假媒体流。
To accomplish this, the entire Hello message (Figure 3) is hashed, using the hash algorithm defined in Section 5.1.2.2. The ZRTP packet framing from Figure 2 is not included in the hash. The resulting hash image is made available without truncation to the signaling layer, where it is transmitted as a hexadecimal value in the SIP channel using the SDP attribute a=zrtp-hash, defined in this specification. Assuming Section 5.1.2.2 defines a 256-bit hash length, the a=zrtp-hash field in the SDP attribute carries 64
为此，使用第5.1.2.2节中定义的散列算法对整个Hello消息（图3）进行散列。散列中不包括图2中的ZRTP数据包帧。生成的散列图像在不截断信令层的情况下可用，在信令层中，它使用本规范中定义的SDP属性a＝zrtp散列作为十六进制值在SIP信道中传输。假设第5.1.2.2节定义了256位哈希长度，则SDP属性中的a=zrtp哈希字段携带64位
hexadecimal digits. Each media stream (audio or video) will have a separate Hello message, and thus will require a separate a=zrtp-hash in an SDP attribute. The recipient of the SIP/SDP message can then use this hash image to detect and reject false Hello messages in the media channel, as well as identify which media stream is associated with this SIP call. Each Hello message hashes uniquely, because it contains the H3 field derived from a random nonce, defined in Section 9.
十六进制数字。每个媒体流（音频或视频）将有一个单独的Hello消息，因此需要在SDP属性中有一个单独的a=zrtp散列。然后，SIP/SDP消息的接收者可以使用该散列图像来检测和拒绝媒体信道中的虚假Hello消息，以及识别与该SIP呼叫相关联的媒体流。每个Hello消息都会唯一地散列，因为它包含从第9节中定义的随机nonce派生的H3字段。
The Hello Hash as an SDP attribute is not a REQUIRED feature, because some ZRTP endpoints do not have the ability to add SDP attributes to the signaling. For example, if ZRTP is implemented in a hardware bump-in-the-wire device, it might only have the ability to modify the media packets, not the SIP packets, especially if the SIP packets are integrity protected and thus cannot be modified on the wire. If the SDP has no hash image of the ZRTP Hello message, the recipient's ZRTP user agent cannot check it, and thus will not be able to reject Hello messages based on this hash.
Hello散列作为SDP属性不是必需的功能，因为某些ZRTP端点不具备向信令添加SDP属性的能力。例如，如果ZRTP在有线设备中的硬件bump中实现，则它可能只能修改媒体分组，而不能修改SIP分组，特别是如果SIP分组受到完整性保护，因此不能在有线上修改。如果SDP没有ZRTP Hello消息的哈希图像，则收件人的ZRTP用户代理无法检查它，因此将无法基于此哈希拒绝Hello消息。
After the Hello Hash is used to properly identify the ZRTP Hello message as belonging to this particular SIP call, the rest of the ZRTP message sequence is protected from false packet injection by other protection mechanisms, such as the hash chaining mechanism defined in Section 9.
在Hello散列被用于正确地识别属于该特定SIP呼叫的ZRTP Hello消息之后，ZRTP消息序列的其余部分被其他保护机制（例如第9节中定义的散列链机制）保护，以防止虚假分组注入。
An attacker who controls only the signaling layer, such as an uncooperative VoIP service provider, may be able to deny service by corrupting the hash of the Hello message in the SDP attribute, which would force ZRTP to reject perfectly good Hello messages. If there is reason to believe this is happening, the ZRTP endpoint MAY allow Hello messages to be accepted that do not match the hash image in the SDP attribute.
仅控制信令层（如不合作的VoIP服务提供商）的攻击者可能通过破坏SDP属性中Hello消息的哈希来拒绝服务，这将迫使ZRTP拒绝完美的Hello消息。如果有理由相信发生了这种情况，ZRTP端点可能会允许接受与SDP属性中的哈希图像不匹配的Hello消息。
Even in the absence of SIP integrity protection, the inclusion of the a=zrtp-hash SDP attribute, when coupled with the hash chaining mechanism defined in Section 9, meets the R-ASSOC requirement in the Media Security Requirements [RFC5479], which requires:
即使在没有SIP完整性保护的情况下，当与第9节中定义的哈希链机制结合时，包含a=zrtp哈希SDP属性也满足媒体安全要求[RFC5479]中的R-ASSOC要求，这要求：
...a mechanism for associating key management messages with both the signaling traffic that initiated the session and with protected media traffic. It is useful to associate key management messages with call signaling messages, as this allows the SDP offerer to avoid performing CPU-consuming operations (e.g., Diffie-Hellman or public key operations) with attackers that have not seen the signaling messages.
…一种将密钥管理消息与启动会话的信令通信量和受保护的媒体通信量相关联的机制。将密钥管理消息与呼叫信令消息相关联非常有用，因为这允许SDP提供方避免与未看到信令消息的攻击者执行CPU消耗操作（例如Diffie Hellman或公钥操作）。
The a=zrtp-hash SDP attribute becomes especially useful if the SDP is integrity-protected end-to-end by SIP Identity [RFC4474] or better still, Dan Wing's SIP Identity using Media Path [SIP-IDENTITY]. This leads to an ability to stop MiTM attacks independent of ZRTP's SAS mechanism, as explained in Section 8.1.1.
如果SDP是通过SIP标识[RFC4474]或更好的方式（Dan Wing的SIP标识使用媒体路径[SIP-Identity]）进行端到端完整性保护的，则a=zrtp哈希SDP属性变得特别有用。如第8.1.1节所述，这使得能够独立于ZRTP的SAS机制阻止MiTM攻击。
8.1.1. Integrity-Protected Signaling Enables Integrity-Protected DH Exchange
8.1.1. 完整性保护信令支持完整性保护DH交换
If and only if the signaling path and the SDP is protected by some form of end-to-end integrity protection, such as one of the abovementioned mechanisms, so that it can guarantee delivery of the a=zrtp-hash attribute without any tampering by a third party, and if there is good reason to trust the signaling layer to protect the interests of the end user, it is possible to authenticate the key exchange and prevent a MiTM attack. This can be done without requiring the users to verbally compare the SAS, by using the hash chaining mechanism defined in Section 9 to provide a series of MAC keys that protect the entire ZRTP key exchange. Thus, an end-to-end integrity-protected signaling layer automatically enables an integrity-protected Diffie-Hellman exchange in ZRTP, which in turn means immunity from a MiTM attack. Here's how it works.
如果且仅当信令路径和SDP受到某种形式的端到端完整性保护（例如上述机制之一）的保护，以便其能够保证a＝zrtp散列属性的传递而不被第三方篡改，并且，如果有充分的理由信任信令层以保护最终用户的利益，则可以认证密钥交换并防止MiTM攻击。通过使用第9节中定义的散列链机制来提供一系列保护整个ZRTP密钥交换的MAC密钥，无需用户口头比较SA即可实现这一点。因此，端到端完整性保护的信令层在ZRTP中自动启用完整性保护的Diffie-Hellman交换，这反过来意味着免受MiTM攻击。下面是它的工作原理。
The integrity-protected SIP SDP contains a hash commitment to the entire Hello message. The Hello message contains H3, which provides a hash commitment for the rest of the hash chain H0-H2 (Section 9). The Hello message is protected by a 64-bit MAC, keyed by H2. The Commit message is protected by a 64-bit MAC, keyed by H1. The DHPart1 or DHPart2 messages are protected by a 64-bit MAC, keyed by H0. The MAC protecting the Confirm messages is computed by a different MAC key derived from the resulting key agreement. Each message's MAC is checked when the MAC key is received in the next message. If a bad MAC is discovered, it MUST be treated as a security exception indicating a MiTM attack, perhaps by logging or alerting the user, and MUST NOT be treated as a random error. Random errors are already discovered and quietly rejected by bad CRCs (Figure 2).
完整性保护的SIP SDP包含对整个Hello消息的哈希承诺。Hello消息包含H3，它为散列链H0-H2的其余部分提供散列承诺（第9节）。Hello消息由64位MAC保护，由H2键控。提交消息由64位MAC保护，由H1键控。DHPart1或DHPart2消息由64位MAC保护，由H0键控。保护确认消息的MAC由从结果密钥协议派生的不同MAC密钥计算。在下一条消息中收到MAC密钥时，将检查每条消息的MAC。如果发现坏MAC，则必须将其视为指示MiTM攻击的安全异常（可能通过记录或提醒用户），并且不得将其视为随机错误。随机错误已经被发现，并被坏的CRC悄悄地拒绝（图2）。
The Hello message must be assembled before any hash algorithms are negotiated, so an implicit predetermined hash algorithm and MAC algorithm (both defined in Section 5.1.2.2) must be used. All of the aforementioned MACs keyed by the hashes in the aforementioned hash chain MUST be computed with the MAC algorithm defined in Section 5.1.2.2, with the MAC truncated to 64 bits.
在协商任何哈希算法之前，必须组装Hello消息，因此必须使用隐式预定哈希算法和MAC算法（均在第5.1.2.2节中定义）。必须使用第5.1.2.2节中定义的MAC算法计算上述哈希链中由哈希键控的所有MAC，MAC截断为64位。
The Media Security Requirements [RFC5479] R-EXISTING requirement can be fully met by leveraging a certificate-backed PKI in the signaling layer to integrity protect the delivery of the a=zrtp-hash SDP
媒体安全要求[RFC5479]R现有要求可以通过在信令层利用证书支持的PKI来完整性保护a=zrtp哈希SDP的交付来完全满足
attribute. This would thereby protect ZRTP against a MiTM attack, without requiring the user to check the SAS, without adding any explicit signatures or signature keys to the ZRTP key exchange and without any extra public key operations or extra packets.
属性因此，这将保护ZRTP免受MiTM攻击，而无需用户检查SAS，无需向ZRTP密钥交换添加任何显式签名或签名密钥，也无需任何额外的公钥操作或额外的数据包。
Without an end-to-end integrity-protection mechanism in the signaling layer to guarantee delivery of the a=zrtp-hash SDP attribute without modification by a third party, these MACs alone will not prevent a MiTM attack. In that case, ZRTP's built-in SAS mechanism will still have to be used to authenticate the key exchange. At the time of this writing, very few deployed VoIP clients offer a fully implemented SIP stack that provides end-to-end integrity protection for the delivery of SDP attributes. Also, end-to-end signaling integrity becomes more problematic if E.164 numbers [RFC3824] are used in SIP. Thus, real-world implementations of ZRTP endpoints will continue to depend on SAS authentication for quite some time. Even after there is widespread availability of SIP user agents that offer integrity protected delivery of SDP attributes, many users will still be faced with the fact that the signaling path may be controlled by institutions that do not have the best interests of the end user in mind. In those cases, SAS authentication will remain the gold standard for the prudent user.
如果在信令层中没有端到端完整性保护机制来保证a=zrtp hash SDP属性的传递而无需第三方修改，这些mac本身将无法防止MiTM攻击。在这种情况下，ZRTP的内置SAS机制仍然必须用于验证密钥交换。在撰写本文时，很少有部署的VoIP客户端提供完全实现的SIP堆栈，为SDP属性的交付提供端到端完整性保护。此外，如果在SIP中使用E.164编号[RFC3824]，则端到端信令完整性将变得更加困难。因此，ZRTP端点的实际实现将在相当长的一段时间内继续依赖于SAS身份验证。即使在提供完整性保护的SDP属性交付的SIP用户代理广泛可用之后，许多用户仍将面临这样一个事实，即信令路径可能由不考虑最终用户最佳利益的机构控制。在这些情况下，SAS身份验证仍然是谨慎用户的黄金标准。
Even without SIP integrity protection, the Media Security Requirements [RFC5479] R-ACT-ACT requirement can be met by ZRTP's SAS mechanism. Although ZRTP may benefit from an integrity-protected SIP layer, it is fortunate that ZRTP's self-contained MiTM defenses do not actually require an integrity-protected SIP layer. ZRTP can bypass the delays and problems that SIP integrity faces, such as E.164 number usage, and the complexity of building and maintaining a PKI.
即使没有SIP完整性保护，ZRTP的SAS机制也可以满足媒体安全要求[RFC5479]R-ACT-ACT要求。尽管ZRTP可能受益于完整性保护的SIP层，但幸运的是，ZRTP自包含的MiTM防御实际上并不需要完整性保护的SIP层。ZRTP可以绕过SIP完整性所面临的延迟和问题，例如E.164号码的使用，以及构建和维护PKI的复杂性。
In contrast, DTLS-SRTP [RFC5764] appears to depend heavily on end-to-end integrity protection in the SIP layer. Further, DTLS-SRTP must bear the additional cost of a signature calculation of its own, in addition to the signature calculation the SIP layer uses to achieve its integrity protection. ZRTP needs no signature calculation of its own to leverage the signature calculation carried out in the SIP layer.
相比之下，DTLS-SRTP[RFC5764]似乎严重依赖于SIP层中的端到端完整性保护。此外，除了SIP层用于实现其完整性保护的签名计算之外，DTLS-SRTP还必须承担其自身签名计算的额外成本。ZRTP不需要自己的签名计算来利用SIP层中执行的签名计算。
The shared secret calculations defined in Section 4.3 make use of the SRTP secret (srtps), if it is provided by the signaling layer.
第4.3节中定义的共享秘密计算使用SRTP秘密（srtps），如果它是由信令层提供的。
It is desirable for only one SRTP key negotiation protocol to be used, and that protocol should be ZRTP. But in the event the signaling layer negotiates its own SRTP master key and salt, using
最好只使用一个SRTP密钥协商协议，该协议应为ZRTP。但如果信令层协商自己的SRTP主密钥和salt，则使用
the SDP Security Descriptions (SDES [RFC4568]) or [RFC4567], it can be passed from the signaling to the ZRTP layer and mixed into ZRTP's own shared secret calculations, without compromising security by creating a dependency on the signaling for media encryption.
SDP安全描述（SDE[RFC4568]）或[RFC4567]可以从信令传递到ZRTP层，并混合到ZRTP自己的共享秘密计算中，而不会因为创建对媒体加密信令的依赖而损害安全性。
ZRTP computes srtps from the SRTP master key and salt parameters provided by the signaling layer in this manner, truncating the result to 256 bits:
ZRTP以这种方式从信令层提供的SRTP主密钥和salt参数计算srtps，将结果截断为256位：
srtps = KDF(SRTP master key, "SRTP Secret", (ZIDi || ZIDr || SRTP master salt), 256)
srtps=KDF（SRTP主密钥，“SRTP秘密”（ZIDi | | ZIDr | SRTP主密钥），256）
It is expected that the srtps parameter will be rarely computed or used in typical ZRTP endpoints, because it is likely and desirable that ZRTP will be the sole means of negotiating SRTP keys, needing no help from [RFC4568] or [RFC4567]. If srtps is computed, it will be stored in the auxiliary shared secret auxsecret, defined in Section 4.3 and used in Section 4.3.1.
预计在典型的ZRTP端点中很少计算或使用srtps参数，因为ZRTP可能是协商SRTP密钥的唯一方式，不需要[RFC4568]或[RFC4567]的帮助。如果计算了srtps，它将存储在第4.3节定义并在第4.3.1节中使用的辅助共享机密auxsecret中。
Codec selection is negotiated in the signaling layer. If the signaling layer determines that ZRTP is supported by both endpoints, this should provide guidance in codec selection to avoid variable bitrate (VBR) codecs that leak information.
编解码器选择在信令层协商。如果信令层确定两个端点都支持ZRTP，则应在编解码器选择中提供指导，以避免泄漏信息的可变比特率（VBR）编解码器。
When voice is compressed with a VBR codec, the packet lengths vary depending on the types of sounds being compressed. This leaks a lot of information about the content even if the packets are encrypted, regardless of what encryption protocol is used [Wright1]. It is RECOMMENDED that VBR codecs be avoided in encrypted calls. It is not a problem if the codec adapts the bitrate to the available channel bandwidth. The vulnerable codecs are the ones that change their bitrate depending on the type of sound being compressed.
当使用VBR编解码器压缩语音时，数据包的长度根据被压缩的声音类型而变化。即使对数据包进行了加密，也会泄露大量内容信息，无论使用何种加密协议[Wright1]。建议在加密调用中避免使用VBR编解码器。如果编解码器根据可用的信道带宽调整比特率，这不是问题。易受攻击的编解码器是根据被压缩的声音类型更改比特率的编解码器。
It also appears that voice activity detection (VAD) leaks information about the content of the conversation, but to a lesser extent than VBR. This effect can be mitigated by lengthening the VAD hangover time by a random amount between 1 and 2 seconds, if this is feasible in your application. Only short bursts of speech would benefit from lengthening the VAD hangover time.
语音活动检测（VAD）似乎也泄露了有关对话内容的信息，但程度低于VBR。如果在您的应用中可行，可以通过将VAD滞留时间随机延长1到2秒来缓解此影响。延长VAD的宿醉时间只会使短时间的言语爆发受益。
The security problems of VBR and VAD are addressed in detail by the guidelines in [VBR-AUDIO]. It is RECOMMENDED that ZRTP endpoints follow these guidelines.
[VBR-AUDIO]中的指南详细说明了VBR和VAD的安全问题。建议ZRTP端点遵循这些指南。
An attacker who is not in the media path may attempt to inject false ZRTP protocol packets, possibly to effect a denial-of-service attack or to inject his own media stream into the call. VoIP, by its nature, invites various forms of denial-of-service attacks and requires protocol features to reject such attacks. While bogus SRTP packets may be easily rejected via the SRTP auth tag field, that can only be applied after a key agreement is completed. During the ZRTP key negotiation phase, other false packet rejection mechanisms are needed. One such mechanism is the use of the total_hash in the final shared secret calculation, but that can only detect false packets after performing the computationally expensive Diffie-Hellman calculation.
不在媒体路径中的攻击者可能会尝试注入虚假的ZRTP协议数据包，可能会实施拒绝服务攻击或将自己的媒体流注入呼叫。VoIP本质上会引发各种形式的拒绝服务攻击，并需要协议功能来拒绝此类攻击。虽然通过SRTP auth tag字段很容易拒绝伪造的SRTP数据包，但只有在密钥协议完成后才能应用该字段。在ZRTP密钥协商阶段，需要其他错误包拒绝机制。一种这样的机制是在最终共享秘密计算中使用total_散列，但它只能在执行计算代价高昂的Diffie-Hellman计算后检测假分组。
A lot of work has been done on the analysis of denial-of-service attacks, especially from attackers who are not in the media path. Such an attacker might inject false ZRTP packets to force a ZRTP endpoint to engage in an endless series of pointless and expensive DH calculations. To detect and reject false packets cheaply and rapidly as soon as they are received, ZRTP uses a one-way hash chain, which is a series of successive hash images. Before each session, the following values are computed:
在分析拒绝服务攻击方面已经做了大量工作，尤其是来自不在媒体路径中的攻击者。这样的攻击者可能会注入虚假的ZRTP数据包，迫使ZRTP端点进行一系列无意义且昂贵的DH计算。为了在收到虚假数据包后立即廉价快速地检测和拒绝它们，ZRTP使用单向散列链，这是一系列连续的散列图像。在每次会话之前，将计算以下值：
H0 = 256-bit random nonce (different for each party)
H0=256位随机nonce（各方不同）
H1 = hash (H0)
H1=散列（H0）
H2 = hash (H1)
H2=散列（H1）
H3 = hash (H2)
H3=散列（H2）
This one-way hash chain MUST use the hash algorithm defined in Section 5.1.2.2, truncated to 256 bits. Each 256-bit hash image is the preimage of the next, and the sequence of images is sent in reverse order in the ZRTP packet sequence. The hash image H3 is sent in the Hello message, H2 is sent in the Commit message, H1 is sent in the DHPart1 or DHPart2 messages, and H0 is sent in the Confirm1 or Confirm2 messages. The initial random H0 nonces that each party generates MUST be unpredictable to an attacker and unique within a ZRTP session, which thereby forces the derived hash images H1-H3 to also be unique and unpredictable.
该单向散列链必须使用第5.1.2.2节中定义的散列算法，该算法被截断为256位。每个256位哈希图像是下一个的前图像，图像序列在ZRTP数据包序列中以相反顺序发送。散列图像H3在Hello消息中发送，H2在Commit消息中发送，H1在DHPart1或DHPart2消息中发送，H0在Confirm1或Confirm2消息中发送。每一方生成的初始随机H0 nonce对于攻击者来说必须是不可预测的，并且在ZRTP会话中是唯一的，从而强制派生的散列图像H1-H3也是唯一的和不可预测的。
The recipient checks if the packet has the correct hash preimage, by hashing it and comparing the result with the hash image for the preceding packet. Packets that contain an incorrect hash preimage MUST NOT be used by the recipient, but they MAY be processed as security exceptions, perhaps by logging or alerting the user. As
收件人通过对数据包进行散列并将结果与前一个数据包的散列图像进行比较，检查数据包是否具有正确的散列前图像。收件人不得使用包含不正确哈希前映像的数据包，但可能会将其作为安全异常进行处理，方法可能是记录或提醒用户。像
long as these bogus packets are not used, and correct packets are still being received, the protocol SHOULD be allowed to run to completion, thereby rendering ineffective this denial-of-service attack.
只要不使用这些伪造的数据包，并且仍在接收正确的数据包，就应该允许协议运行到完成，从而使拒绝服务攻击无效。
Note that since H2 is sent in the Commit message, and the initiator does not receive a Commit message, the initiator computes the responder's missing H2 by hashing the responder's H1. An analogous interpolation is performed by both parties to handle the skipped DHPart1 and DHPart2 messages in Preshared (Section 3.1.2) or Multistream (Section 3.1.3) modes.
注意，由于H2在提交消息中发送，并且启动器没有收到提交消息，因此启动器通过散列响应程序的H1来计算响应程序缺少的H2。双方执行类似的插值，以预共享（第3.1.2节）或多流（第3.1.3节）模式处理跳过的DHPart1和DHPart2消息。
Because these hash images alone do not protect the rest of the contents of the packet they reside in, this scheme assumes the attacker cannot modify the packet contents from a legitimate party, which is a reasonable assumption for an attacker who is not in the media path. This covers an important range of denial-of-service attacks. For dealing with the remaining set of attacks that involve packet modification, other mechanisms are used, such as the total_hash in the final shared secret calculation, and the hash commitment in the Commit message.
由于这些散列图像本身并不能保护其所在数据包的其余内容，因此该方案假设攻击者无法修改来自合法方的数据包内容，这对于不在媒体路径中的攻击者来说是合理的假设。这涵盖了一系列重要的拒绝服务攻击。为了处理涉及数据包修改的其余攻击集，还使用了其他机制，例如最终共享秘密计算中的total_散列，以及提交消息中的散列承诺。
Hello messages injected by an attacker may be detected and rejected by the inclusion of a hash of the Hello message in the signaling, as described in Section 8. This mechanism requires that each Hello message be unique, and the inclusion of the H3 hash image meets that requirement.
如第8节所述，通过在信令中包含Hello消息的散列，可以检测并拒绝攻击者注入的Hello消息。该机制要求每个Hello消息都是唯一的，并且H3哈希映像的包含满足该要求。
If and only if an integrity-protected signaling channel is available, the MACs that are keyed by this hash chaining scheme can be used to authenticate the entire ZRTP key exchange, and thereby prevent a MiTM attack, without relying on the users verbally comparing the SAS. See Section 8.1.1 for details.
当且仅当完整性保护的信令信道可用时，由该散列链方案设置密钥的mac可用于认证整个ZRTP密钥交换，从而防止MiTM攻击，而无需依赖用户口头比较sa。详见第8.1.1节。
Some ZRTP user agents allow the user to manually switch to clear mode (via the GoClear message) in the middle of a secure call, and then later initiate secure mode again. Many consumer client products will omit this feature, but those that allow it may return to secure mode again in the same media stream. Although the same chain of hash images will be reused and thus rendered ineffective the second time, no real harm is done because the new SRTP session keys will be derived in part from a cached shared secret, which was safely protected from the MiTM in the previous DH exchange earlier in the same session.
一些ZRTP用户代理允许用户在安全呼叫的中间手动切换到清除模式（通过GOCURE消息），然后再启动安全模式。许多消费客户机产品将省略此功能，但那些允许此功能的产品可能会在同一媒体流中再次返回到安全模式。虽然相同的散列映像链将被重用，从而在第二次时变得无效，但不会造成真正的伤害，因为新的SRTP会话密钥将部分来自缓存的共享密钥，该密钥在同一会话的早期DH exchange中受到MiTM的安全保护。
This section discusses the operation of a ZRTP endpoint that is actually an intermediary. For example, consider a device that proxies both signaling and media between endpoints. There are three possible ways in which such a device could support ZRTP.
本节讨论实际上是中介的ZRTP端点的操作。例如，考虑一种在端点之间代理信令和媒体的设备。这种设备支持ZRTP的方式有三种。
An intermediary device can act transparently to the ZRTP protocol. To do this, a device MUST pass non-RTP protocols multiplexed on the same port as RTP (to allow ZRTP and STUN). This is the RECOMMENDED behavior for intermediaries as ZRTP and SRTP are best when done end-to-end.
中间设备可以对ZRTP协议透明地进行操作。为此，设备必须在与RTP相同的端口上通过多路复用的非RTP协议（以允许ZRTP和STUN）。这是中介机构的推荐行为，因为ZRTP和SRTP在端到端完成时是最好的。
An intermediary device could implement the ZRTP protocol and act as a ZRTP endpoint on behalf of non-ZRTP endpoints behind the intermediary device. The intermediary could determine on a call-by-call basis whether the endpoint behind it supports ZRTP based on the presence or absence of the ZRTP SDP attribute flag (a=zrtp-hash). For non-ZRTP endpoints, the intermediary device could act as the ZRTP endpoint using its own ZID and cache. This approach SHOULD only be used when there is some other security method protecting the confidentiality of the media between the intermediary and the inside endpoint, such as IPsec or physical security.
中间设备可以实现ZRTP协议，并代表中间设备后面的非ZRTP端点充当ZRTP端点。中介可以根据ZRTP SDP属性标志（a=ZRTP哈希）的存在与否，逐个调用地确定其背后的端点是否支持ZRTP。对于非ZRTP端点，中间设备可以使用自己的ZID和缓存充当ZRTP端点。只有当存在保护中介和内部端点之间的媒体机密性的其他安全方法（如IPsec或物理安全）时，才应使用此方法。
The third mode, which is NOT RECOMMENDED, is for the intermediary device to attempt to back-to-back the ZRTP protocol. The only exception to this case is where the intermediary device is a trusted element providing services to one of the endpoints -- e.g., a Private Branch Exchange or PBX. In this mode, the intermediary would attempt to act as a ZRTP endpoint towards both endpoints of the media session. This approach MUST NOT be used except as described in Section 7.3 as it will always result in a detected MiTM attack and will generate alarms on both endpoints and likely result in the immediate termination of the session. The PBX MUST uses a single ZID for all endpoints behind it.
第三种模式（不建议使用）是中间设备尝试背对背使用ZRTP协议。这种情况的唯一例外是，中间设备是一个可信任的元素，向其中一个端点（例如，专用分支交换机或PBX）提供服务。在此模式下，中介将尝试充当媒体会话的两个端点的ZRTP端点。除非如第7.3节所述，否则不得使用此方法，因为它将始终导致检测到的MiTM攻击，并将在两个端点上生成警报，并可能导致会话立即终止。PBX必须对其后面的所有端点使用单个ZID。
In cases where centralized media mixing is taking place, the SAS will not match when compared by the humans. This situation can sometimes be known in the SIP signaling by the presence of the isfocus feature tag [RFC4579]. As a result, when the isfocus feature tag is present, the DH exchange can be authenticated by the mechanism defined in Section 8.1.1 or by validating signatures (Section 7.2) in the Confirm or SASrelay messages. For example, consider an audio conference call with three participants Alice, Bob, and Carol hosted on a conference bridge in Dallas. There will be three ZRTP encrypted media streams, one encrypted stream between each participant and Dallas. Each will have a different SAS. Each participant will be able to validate their SAS with the conference bridge by using
在进行集中媒体混合的情况下，SAS在与人比较时将不匹配。这种情况有时可以通过isfocus功能标签[RFC4579]的存在在SIP信令中知道。因此，当isfocus功能标签存在时，DH交换可以通过第8.1.1节中定义的机制或通过验证确认或SASRepay消息中的签名（第7.2节）进行身份验证。例如，在达拉斯的一个会议桥上，有三位参与者爱丽丝、鲍伯和卡罗尔主持了一个音频电话会议。将有三个ZRTP加密媒体流，每个参与者和达拉斯之间有一个加密流。每个都有不同的SAS。每位参与者将能够通过使用会议桥验证其SAS
signatures optionally present in the Confirm messages (described in Section 7.2). Or, if the signaling path has end-to-end integrity protection, each DH exchange will have automatic MiTM protection by using the mechanism in Section 8.1.1.
确认消息中可选存在的签名（如第7.2节所述）。或者，如果信令路径具有端到端完整性保护，则通过使用第8.1.1节中的机制，每个DH交换机将具有自动MiTM保护。
SIP feature tags can also be used to detect if a session is established with an automaton such as an Interactive Voice Response (IVR), voicemail system, or speech recognition system. The display of SAS strings to users should be disabled in these cases.
SIP功能标签还可用于检测会话是否由诸如交互式语音应答（IVR）、语音邮件系统或语音识别系统等自动机建立。在这些情况下，应禁用向用户显示SAS字符串。
It is possible that an intermediary device acting as a ZRTP endpoint might still receive ZRTP Hello and other messages from the inside endpoint. This could occur if there is another inline ZRTP device that does not include the ZRTP SDP attribute flag. An intermediary acting as a ZRTP endpoint receiving ZRTP Hello and other messages from the inside endpoint MUST NOT pass these ZRTP messages.
作为ZRTP端点的中间设备可能仍然从内部端点接收ZRTP Hello和其他消息。如果存在另一个不包含ZRTP SDP属性标志的内联ZRTP设备，则可能发生这种情况。充当从内部端点接收ZRTP Hello和其他消息的ZRTP端点的中介体不得传递这些ZRTP消息。
There are no back doors defined in the ZRTP protocol specification. The designers of ZRTP would like to discourage back doors in ZRTP-enabled products. However, despite the lack of back doors in the actual ZRTP protocol, it must be recognized that a ZRTP implementer might still deliberately create a rogue ZRTP-enabled product that implements a back door outside the scope of the ZRTP protocol. For example, they could create a product that discloses the SRTP session key generated using ZRTP out-of-band to a third party. They may even have a legitimate business reason to do this for some customers.
ZRTP协议规范中没有定义后门。ZRTP的设计者希望阻止ZRTP产品的后门。然而，尽管在实际的ZRTP协议中缺少后门，但必须认识到ZRTP实现者仍然可能故意创建一个支持ZRTP的流氓产品，该产品实现ZRTP协议范围之外的后门。例如，他们可以创建一个产品，向第三方公开使用ZRTP带外生成的SRTP会话密钥。他们甚至有正当的商业理由为某些客户这样做。
For example, some environments have a need to monitor or record calls, such as stock brokerage houses who want to discourage insider trading, or special high-security environments with special needs to monitor their own phone calls. We've all experienced automated messages telling us that "This call may be monitored for quality assurance". A ZRTP endpoint in such an environment might unilaterally disclose the session key to someone monitoring the call. ZRTP-enabled products that perform such out-of-band disclosures of the session key can undermine public confidence in the ZRTP protocol, unless we do everything we can in the protocol to alert the other user that this is happening.
例如，某些环境需要监控或记录通话，例如希望阻止内幕交易的股票经纪公司，或者需要监控自己通话的特殊高安全环境。我们都经历过自动消息，告诉我们“此呼叫可能会被监控以确保质量”。在这样的环境中，ZRTP端点可能会单方面将会话密钥透露给监控呼叫的人。启用ZRTP的产品执行会话密钥的带外披露可能会破坏公众对ZRTP协议的信心，除非我们在协议中尽一切可能提醒其他用户正在发生这种情况。
If one of the parties is using a product that is designed to disclose their session key, ZRTP requires them to confess this fact to the other party through a protocol message to the other party's ZRTP client, which can properly alert that user, perhaps by rendering it in a graphical user interface. The disclosing party does this by sending a Disclosure flag (D) in Confirm1 and Confirm2 messages as described in Section 5.7.
如果一方使用的产品旨在公开其会话密钥，ZRTP要求他们通过向另一方的ZRTP客户端发送协议消息向另一方承认这一事实，该客户端可能通过在图形用户界面中呈现该消息来正确提醒该用户。披露方通过在第5.7节所述的Confirm1和Confirm2消息中发送披露标志（D）来实现这一点。
Note that the intention here is to have the Disclosure flag identify products that are designed to disclose their session keys, not to identify which particular calls are compromised on a call-by-call basis. This is an important legal distinction, because most government sanctioned wiretap regulations require a VoIP service provider to not reveal which particular calls are wiretapped. But there is nothing illegal about revealing that a product is designed to be wiretap-friendly. The ZRTP protocol mandates that such a product "out" itself.
请注意，此处的意图是让披露标志标识设计用于披露其会话密钥的产品，而不是标识在逐个呼叫的基础上泄露的特定呼叫。这是一个重要的法律区别，因为大多数政府批准的窃听法规要求VoIP服务提供商不得透露窃听的特定呼叫。但透露一款产品的设计是为了便于窃听，这并不违法。ZRTP协议要求这样一个产品“脱离”自身。
You might be using a ZRTP-enabled product with no back doors, but if your own graphical user interface tells you the call is (mostly) secure, except that the other party is using a product that is designed in such a way that it may have disclosed the session key for monitoring purposes, you might ask him what brand of secure telephone he is using, and make a mental note not to purchase that brand yourself. If we create a protocol environment that requires such back-doored phones to confess their nature, word will spread quickly, and the "invisible hand" of the free market will act. The free market has effectively dealt with this in the past.
您可能正在使用支持ZRTP且没有后门的产品，但如果您自己的图形用户界面告诉您通话（大部分）是安全的，但另一方使用的产品的设计方式可能会泄露会话密钥以进行监控，您可能会问他使用的是什么品牌的安全电话，记住不要自己购买那个品牌。如果我们创造一个协议环境，要求这些后门手机承认它们的性质，消息就会迅速传播，自由市场的“看不见的手”就会采取行动。自由市场在过去有效地解决了这一问题。
Of course, a ZRTP implementer can lie about his product having a back door, but the ZRTP standard mandates that ZRTP-compliant products MUST adhere to the requirement that a back door be confessed by sending the Disclosure flag to the other party.
当然，ZRTP实现者可以谎称其产品有后门，但ZRTP标准要求符合ZRTP的产品必须遵守向另一方发送披露标志以承认后门的要求。
There will be inevitable comparisons to Steve Bellovin's 2003 April fool joke, when he submitted RFC 3514 [RFC3514], which defined the "Evil bit" in the IPv4 header, for packets with "evil intent". But we submit that a similar idea can actually have some merit for securing VoIP. Sure, one can always imagine that some implementer will not be fazed by the rules and will lie, but they would have lied anyway even without the Disclosure flag. There are good reasons to believe that it will improve the overall percentage of implementations that at least tell us if they put a back door in their products, and may even get some of them to decide not to put in a back door at all. From a civic hygiene perspective, we are better off with having the Disclosure flag in the protocol.
史蒂夫·贝洛文（Steve Bellovin）在2003年的愚人节玩笑中提交了RFC 3514[RFC3514]，定义了IPv4报头中的“邪恶比特”，这不可避免地会与之进行比较，因为其中包含“邪恶意图”的数据包。但我们认为，类似的想法实际上对保护VoIP有一些好处。当然，我们可以想象，一些实现者不会被规则所困扰，会撒谎，但即使没有披露标志，他们也会撒谎。有充分的理由相信，这将提高实施的总体百分比，至少可以告诉我们他们是否在产品中设置了后门，甚至可能让一些人决定根本不设置后门。从公民卫生的角度来看，我们最好在协议中加入披露标志。
If an endpoint stores or logs SRTP keys or information that can be used to reconstruct or recover SRTP keys after they are no longer in use (i.e., the session is active), or otherwise discloses or passes SRTP keys or information that can be used to reconstruct or recover SRTP keys to another application or device, the Disclosure flag D MUST be set in the Confirm1 or Confirm2 message.
如果端点存储或记录SRTP密钥或信息，这些密钥或信息可用于在SRTP密钥不再使用（即会话处于活动状态）后重建或恢复SRTP密钥，或者以其他方式向另一应用程序或设备披露或传递可用于重建或恢复SRTP密钥的SRTP密钥或信息，必须在Confirm1或Confirm2消息中设置披露标志D。
Some implementers have asked for guidance on implementing the Disclosure flag. Some people have incorrectly thought that a connection secured with ZRTP cannot be used in a call center, with voluntary voice recording, or even with a voicemail system. Similarly, some potential users of ZRTP have over considered the protection that ZRTP can give them. These guidelines clarify both concerns.
一些实施者要求提供关于实施披露标志的指导。有些人错误地认为，ZRTP安全连接不能用于呼叫中心、自愿录音，甚至不能用于语音邮件系统。类似地，ZRTP的一些潜在用户过度考虑了ZRTP可以为他们提供的保护。这些指导方针澄清了这两个问题。
The ZRTP Disclosure flag only governs the ZRTP/SRTP stream itself. It does not govern the underlying RTP media stream, nor the actual media itself. Consequently, a PBX that uses ZRTP may provide conference calls, call monitoring, call recording, voicemail, or other PBX features and still say that it does not disclose the ZRTP key material. A video system may provide DVR features and still say that it does not disclose the ZRTP key material. The ZRTP Disclosure flag, when not set, means only that the ZRTP cryptographic key material stays within the bounds of the ZRTP subsystem.
ZRTP公开标志仅控制ZRTP/SRTP流本身。它不控制底层RTP媒体流，也不控制实际媒体本身。因此，使用ZRTP的PBX可能会提供会议通话、通话监控、通话录音、语音邮件或其他PBX功能，但仍表示不会披露ZRTP密钥材料。视频系统可能会提供DVR功能，但仍然表示不会公开ZRTP密钥材料。未设置ZRTP公开标志时，仅表示ZRTP加密密钥材料保持在ZRTP子系统的范围内。
If an application has a need to disclose the ZRTP cryptographic key material, the easiest way to comply with the protocol is to set the flag to the proper value. The next easiest way is to overestimate disclosure. For example, a call center that commonly records calls might choose to set the Disclosure flag even though all recording is an analog recording of a call (and thus outside the ZRTP scope) because it sets an expectation with clients that their calls might be recorded.
如果应用程序需要公开ZRTP加密密钥材料，遵守协议的最简单方法是将标志设置为适当的值。第二个最简单的方法是高估披露。例如，通常记录呼叫的呼叫中心可能会选择设置披露标志，即使所有记录都是呼叫的模拟记录（因此不在ZRTP范围内），因为它为客户端设置了可能记录其呼叫的期望。
Note also that the ZRTP Disclosure Flag does not require an implementation to preclude hacking or malware. Malware that leaks ZRTP cryptographic key material does not create a liability for the implementer from non-compliance with the ZRTP specification.
还要注意的是，ZRTP公开标志不需要实现来排除黑客或恶意软件。泄漏ZRTP加密密钥材料的恶意软件不会因实施者不遵守ZRTP规范而产生责任。
A user of ZRTP should note that ZRTP is not a panacea against unauthorized recording. ZRTP does not and cannot protect against an untrustworthy partner who holds a microphone up to the speaker. It does not protect against someone else being in the room. It does not protect against analog wiretaps in the phone or in the room. It does not mean your partner has not been hacked with spyware. It does not mean that the software has no flaws. It means that the ZRTP subsystem is not knowingly leaking ZRTP cryptographic key material.
ZRTP的用户应该注意，ZRTP并不是防止未经授权录制的灵丹妙药。ZRTP不能也不能防止不值得信任的合作伙伴将麦克风举向扬声器。它不能防止其他人在房间里。它不能防止电话或房间中的模拟窃听。这并不意味着你的伴侣没有被间谍软件入侵。这并不意味着软件没有缺陷。这意味着ZRTP子系统没有故意泄漏ZRTP加密密钥材料。
The role of the ZID in the management of the local cache of shared secrets is explained in Section 4.9. A particular ZID is associated with a particular ZRTP endpoint, typically a VoIP client. A single
第4.9节解释了ZID在共享机密本地缓存管理中的作用。特定的ZID与特定的ZRTP端点相关联，通常是VoIP客户端。单人间
SIP URI (also known as an Address-of-Record, or AOR) may be hosted on several different soft VoIP clients, desktop phones, and mobile handsets, and each of them will have a different ZID. Further, a single VoIP client may have several SIP URIs configured into its profiles, but only one ZID. There is not a one-to-one mapping between a ZID and a SIP URI. A single SIP URI may be associated with several ZIDs, and a single ZID may be associated with several SIP URIs on the same client.
SIP URI（也称为记录地址，或AOR）可以托管在几个不同的软VoIP客户端、桌面电话和移动手机上，并且每个客户端都有不同的ZID。此外，单个VoIP客户端可能在其配置文件中配置了多个SIP URI，但只有一个ZID。ZID和SIPURI之间没有一对一的映射。单个SIP URI可以与多个ZID相关联，并且单个ZID可以与同一客户端上的多个SIP URI相关联。
Not only that, but ZRTP is independent of which signaling protocol is used. It works equally well with SIP, Jingle, H.323, or any proprietary signaling protocol. Thus, a ZRTP ZID has little to do with SIP, per se, which means it has little to do with a SIP URI.
不仅如此，ZRTP独立于所使用的信令协议。它同样适用于SIP、叮当、H.323或任何专有信令协议。因此，ZRTPZID本身与SIP关系不大，这意味着它与SIPURI关系不大。
Even though a ZID is associated with a device, not a human, it is often the case that a ZRTP endpoint is controlled mainly by a particular human. For example, it may be a mobile phone. To get the full benefit of the key continuity features, a local cache entry (and thus a ZID) should be associated with some sort of name of the remote party. That name could be a human name, or it could be made more precise by specifying which ZRTP endpoint he's using. For example "Jon Callas", or "Jon Callas on his iPhone", or "Jon on his iPad", or "Alice on her office phone". These name strings can be stored in the local cache, indexed by ZID, and may have been initially provided by the local user by hand. Or the local cache entry may contain a pointer to an entry in the local address book. When a secure session is established, if a prior session has established a cache entry, and the new session has a matching cache entry indexed by the same ZID, and the SAS has been previously verified, the person's name stored in that cache entry should be displayed.
即使ZID与设备关联，而不是与人关联，但ZRTP端点通常主要由特定的人控制。例如，它可能是一部移动电话。为了充分利用关键的连续性特性，本地缓存条目（因此是一个ZID）应该与远程方的某种名称相关联。该名称可以是人名，也可以通过指定他使用的ZRTP端点来更加精确。例如“Jon Callas”，或“Jon Callas在他的iPhone上”，或“Jon在他的iPad上”，或“Alice在她的办公室电话上”。这些名称字符串可以存储在本地缓存中，由ZID索引，并且可能最初由本地用户手动提供。或者，本地缓存条目可能包含指向本地地址簿中条目的指针。建立安全会话时，如果先前会话已建立缓存项，且新会话具有由相同ZID索引的匹配缓存项，且SAS先前已验证，则应显示存储在该缓存项中的人员姓名。
If the remote ZID originates from a PBX, the displayed name would be the name of that PBX, which might be the name of the company who owns that PBX.
如果远程ZID来自某个PBX，则显示的名称将是该PBX的名称，该名称可能是拥有该PBX的公司的名称。
If it is desirable to associate some key material with a particular AOR, digital signatures (Section 7.2) may be used, with public key certificates that associate the signature key with an AOR. If more than one ZRTP endpoint shares the same AOR, they may all use the same signature key and provide the same public key certificate with their signatures.
如果希望将某些密钥材料与特定AOR关联，则可以使用数字签名（第7.2节）以及将签名密钥与AOR关联的公钥证书。如果多个ZRTP端点共享同一AOR，则它们可能都使用相同的签名密钥，并提供具有其签名的相同公钥证书。
This specification defines a new SDP [RFC4566] attribute in Section 8.
本规范在第8节中定义了一个新的SDP[RFC4566]属性。
Contact name: Philip Zimmermann <prz@mit.edu>
Contact name: Philip Zimmermann <prz@mit.edu>
Attribute name: "zrtp-hash"
属性名称：“zrtp哈希”
Type of attribute: Media level
属性类型：媒体级别
Subject to charset: Not
以字符集为准：不
Purpose of attribute: The 'zrtp-hash' indicates that a UA supports the ZRTP protocol and provides a hash of the ZRTP Hello message. The ZRTP protocol version number is also specified.
属性用途：“zrtp哈希”表示UA支持zrtp协议，并提供zrtp Hello消息的哈希。还指定了ZRTP协议版本号。
Allowed attribute values: Hex
允许的属性值：十六进制
This section discuses how ZRTP meets all RTP security requirements discussed in the Media Security Requirements [RFC5479] document without any dependencies on other protocols or extensions, unlike DTLS-SRTP [RFC5764] which requires additional protocols and mechanisms.
本节讨论ZRTP如何满足媒体安全要求[RFC5479]文档中讨论的所有RTP安全要求，而不依赖于其他协议或扩展，这与DTLS-SRTP[RFC5764]不同，后者需要额外的协议和机制。
R-FORK-RETARGET is met since ZRTP is a media path key agreement protocol.
由于ZRTP是媒体路径密钥协商协议，因此满足R-FORK-RETARGET。
R-DISTINCT is met since ZRTP uses ZIDs and allows multiple independent ZRTP exchanges to proceed.
由于ZRTP使用ZID并允许进行多个独立的ZRTP交换，因此满足R-DISTINCT。
R-HERFP is met since ZRTP is a media path key agreement protocol.
满足R-HERFP，因为ZRTP是媒体路径密钥协商协议。
R-REUSE is met using the Multistream and Preshared modes.
使用多流和预共享模式满足R重用。
R-AVOID-CLIPPING is met since ZRTP is a media path key agreement protocol.
由于ZRTP是一种媒体路径密钥协商协议，因此满足R-AVOID-CLIPPING要求。
R-RTP-CHECK is met since the ZRTP packet format does not pass the RTP validity check.
满足R-RTP-CHECK，因为ZRTP数据包格式未通过RTP有效性检查。
R-ASSOC is met using the a=zrtp-hash SDP attribute in INVITEs and responses (Section 8.1).
在邀请和响应（第8.1节）中使用a=zrtp哈希SDP属性满足R-ASSOC。
R-NEGOTIATE is met using the Commit message.
使用提交消息满足R协商。
R-PSTN is met since ZRTP can be implemented in Gateways.
由于ZRTP可以在网关中实现，因此满足R-PSTN的要求。
R-PFS is met using ZRTP Diffie-Hellman key agreement methods.
使用ZRTP Diffie-Hellman密钥协商方法满足R-PFS要求。
R-COMPUTE is met using the Hello/Commit ZRTP exchange.
使用Hello/Commit-ZRTP交换满足R-COMPUTE。
R-CERTS is met using the verbal comparison of the SAS.
使用SAS的口头比较满足R-CERTS要求。
R-FIPS is met since ZRTP uses only FIPS-approved algorithms in all relevant categories. The authors believe ZRTP is compliant with [NIST-SP800-56A], [NIST-SP800-108], [FIPS-198-1], [FIPS-180-3], [NIST-SP800-38A], [FIPS-197], and [NSA-Suite-B], which should meet the FIPS-140 validation requirements set by [FIPS-140-2-Annex-A] and [FIPS-140-2-Annex-D].
由于ZRTP仅在所有相关类别中使用FIPS批准的算法，因此符合R-FIPS。作者认为，ZRTP符合[NIST-SP800-56A]、[NIST-SP800-108]、[FIPS-198-1]、[FIPS-180-3]、[NIST-SP800-38A]、[FIPS-197]和[NSA-Suite-B]，应满足[FIPS-140-2-附录A]和[FIPS-140-2-附录D]规定的FIPS-140验证要求。
R-DOS is met since ZRTP does not introduce any new denial-of-service attacks.
由于ZRTP不会引入任何新的拒绝服务攻击，因此满足R-DOS要求。
R-EXISTING is met since ZRTP can support the use of certificates or keys.
满足R-EXISTING，因为ZRTP可以支持证书或密钥的使用。
R-AGILITY is met since the set of hash, cipher, SRTP authentication tag type, key agreement method, SAS type, and signature type can all be extended and negotiated.
由于哈希、密码、SRTP身份验证标记类型、密钥协商方法、SAS类型和签名类型的集合都可以扩展和协商，因此满足了R-AGILITY的要求。
R-DOWNGRADE is met since ZRTP has protection against downgrade attacks.
由于ZRTP具有针对降级攻击的保护，因此满足R降级要求。
R-PASS-MEDIA is met since ZRTP prevents a passive adversary with access to the media path from gaining access to keying material used to protect SRTP media packets.
满足R-PASS-MEDIA，因为ZRTP可防止访问媒体路径的被动对手访问用于保护SRTP媒体包的密钥材料。
R-PASS-SIG is met since ZRTP prevents a passive adversary with access to the signaling path from gaining access to keying material used to protect SRTP media packets.
满足R-PASS-SIG，因为ZRTP防止能够访问信令路径的被动对手访问用于保护SRTP媒体分组的密钥材料。
R-SIG-MEDIA is met using the a=zrtp-hash SDP attribute in INVITEs and responses.
在邀请和响应中使用a=zrtp hash SDP属性满足R-SIG-MEDIA。
R-ID-BINDING is met using the a=zrtp-hash SDP attribute (Section 8.1).
使用a=zrtp哈希SDP属性（第8.1节）满足R-ID-BINDING要求。
R-ACT-ACT is met using the a=zrtp-hash SDP attribute in INVITEs and responses.
在邀请和响应中使用a=zrtp hash SDP属性满足R-ACT-ACT。
R-BEST-SECURE is met since ZRTP utilizes the RTP/AVP profile and hence best effort SRTP in every case.
由于ZRTP利用RTP/AVP配置文件，因此在任何情况下都能满足R-BEST-SECURE要求。
R-OTHER-SIGNALING is met since ZRTP can utilize modes in which there is no dependency on the signaling path.
满足R-OTHER-SIGNALING，因为ZRTP可以利用不依赖于信令路径的模式。
R-RECORDING is met using the ZRTP Disclosure flag.
使用ZRTP公开标志满足R记录要求。
R-TRANSCODER is met if the transcoder operates as a trusted MitM (i.e., a PBX).
如果转码器作为受信任的MitM（即PBX）运行，则满足R-转码器的要求。
R-ALLOW-RTP is met due to ZRTP's best effort encryption.
由于ZRTP的尽力而为加密，满足了R-ALLOW-RTP的要求。
This document is all about securely keying SRTP sessions. As such, security is discussed in every section.
本文档是关于安全地键入SRTP会话的。因此，每一节都讨论安全性。
Most secure phones rely on a Diffie-Hellman exchange to agree on a common session key. But since DH is susceptible to a MiTM attack, it is common practice to provide a way to authenticate the DH exchange. In some military systems, this is done by depending on digital signatures backed by a centrally managed PKI. A decade of industry experience has shown that deploying centrally managed PKIs can be a painful and often futile experience. PKIs are just too messy and require too much activation energy to get them started. Setting up a PKI requires somebody to run it, which is not practical for an equipment provider. A service provider, like a carrier, might venture down this path, but even then you have to deal with cross-carrier authentication, certificate revocation lists, and other complexities. It is much simpler to avoid PKIs altogether, especially when developing secure commercial products. It is therefore more common for commercial secure phones in the PSTN world to augment the DH exchange with a Short Authentication String (SAS) combined with a hash commitment at the start of the key exchange, to shorten the length of SAS material that must be read aloud. No PKI is required for this approach to authenticating the DH exchange. The AT&T TSD 3600, Eric Blossom's COMSEC secure phones [comsec], [PGPfone], and the GSMK CryptoPhone are all examples of products that took this simpler lightweight approach. The main problem with this approach is inattentive users who may not execute the voice authentication procedure.
大多数安全的手机依靠Diffie-Hellman交换来商定一个公共会话密钥。但由于DH容易受到MiTM攻击，因此通常的做法是提供一种对DH交换进行身份验证的方法。在一些军事系统中，这是通过依赖由中央管理的PKI支持的数字签名来实现的。十年的行业经验表明，部署集中管理的PKI可能是一种痛苦且往往徒劳的经历。PKI太混乱，需要太多的激活能才能启动。建立PKI需要有人来运行，这对于设备提供商来说是不现实的。服务提供商（如运营商）可能会沿着这条道路冒险，但即使这样，您也必须处理跨运营商身份验证、证书吊销列表和其他复杂性。完全避免使用PKI要简单得多，尤其是在开发安全的商业产品时。因此，对于PSTN世界中的商用安全电话来说，更常见的是在密钥交换开始时使用短认证字符串（SAS）和哈希承诺来增强DH交换，以缩短必须大声读出的SAS材料的长度。这种验证DH exchange的方法不需要PKI。AT&T TSD 3600、Eric Blossom的COMSEC安全电话[COMSEC]、[PGPfone]和GSMK加密电话都是采用这种更简单的轻量级方法的产品示例。这种方法的主要问题是注意力不集中的用户可能不会执行语音身份验证过程。
Some questions have been raised about voice spoofing during the short authentication string (SAS) comparison. But it is a mistake to think this is simply an exercise in voice impersonation (perhaps this could be called the "Rich Little" attack). Although there are digital signal processing techniques for changing a person's voice, that does not mean a MiTM attacker can safely break into a phone conversation and inject his own SAS at just the right moment. He doesn't know exactly when or in what manner the users will choose to read aloud
在短验证字符串（SAS）比较期间，出现了一些有关语音欺骗的问题。但是，如果认为这仅仅是一种语音模拟练习，那就大错特错了（也许这可以被称为“富小”攻击）。虽然有数字信号处理技术可以改变一个人的声音，但这并不意味着MiTM攻击者可以安全地进入电话对话，并在适当的时候注入自己的SAS。他不知道用户何时或以何种方式大声朗读
the SAS, or in what context they will bring it up or say it, or even which of the two speakers will say it, or if indeed they both will say it. In addition, some methods of rendering the SAS involve using a list of words such as the PGP word list[Juola2], in a manner analogous to how pilots use the NATO phonetic alphabet to convey information. This can make it even more complicated for the attacker, because these words can be worked into the conversation in unpredictable ways. If the session also includes video (an increasingly common usage scenario), the MiTM may be further deterred by the difficulty of making the lips sync with the voice-spoofed SAS. The PGP word list is designed to make each word phonetically distinct, which also tends to create distinctive lip movements. Remember that the attacker places a very high value on not being detected, and if he makes a mistake, he doesn't get to do it over.
SAS，或者他们将在什么样的背景下提出或说出来，甚至两位发言人中的哪一位会说出来，或者如果他们确实都会说出来。此外，一些呈现SAS的方法涉及使用诸如PGP单词列表[Juola2]之类的单词列表，其方式类似于飞行员使用北约语音字母表传达信息的方式。这会使攻击者更加复杂，因为这些话可能以不可预测的方式进入对话。如果会话还包括视频（一种越来越常见的使用场景），那么MiTM可能会因为难以使嘴唇与语音欺骗SAS同步而进一步受到阻碍。PGP单词表的设计目的是使每个单词在语音上不同，这也有助于创造独特的嘴唇运动。记住，攻击者非常重视未被发现，如果他犯了错误，他就不会再犯错误。
A question has been raised regarding the safety of the SAS procedure for people who don't know each other's voices, because it may allow an attack from a MiTM even if he lacks voice impersonation capabilities. This is not as much of a problem as it seems, because it isn't necessary that users recognize each other by their voice. It is only necessary that they detect that the voice used for the SAS procedure doesn't match the voice in the rest of the phone conversation.
有人提出了一个关于SAS程序对于不知道对方声音的人的安全性的问题，因为它可能允许来自MiTM的攻击，即使他缺乏声音模拟功能。这并不像看上去那样是个问题，因为用户没有必要通过自己的声音来识别对方。他们只需要检测到SAS过程中使用的语音与其余通话中的语音不匹配。
Special consideration must be given to secure phone calls with automated systems that cannot perform a verbal SAS comparison between two humans (e.g., a voice mail system). If a well-functioning PKI is available to all parties, it is recommended that credentials be provisioned at the automated system sufficient to use one of the automatic MiTM detection mechanisms from Section 8.1.1 or Section 7.2. Or rely on a previously established cached shared secret (pbxsecret or rs1 or both), backed by a human-executed SAS comparison during an initial call. Note that it is worse than useless and absolutely unsafe to rely on a robot voice from the remote endpoint to compare the SAS, because a robot voice can be trivially forged by a MiTM. However, a robot voice may be safe to use strictly locally for a different purpose. A ZRTP user agent may render its locally computed SAS to the local user via a robot voice if no visual display is available, provided the user can readily determine that the robot voice is generated locally, not from the remote endpoint.
必须特别注意使用不能在两个人之间进行口头SAS比较的自动系统（例如语音邮件系统）进行的安全电话呼叫。如果各方都可以使用功能良好的PKI，建议在自动化系统中提供足够的凭证，以使用第8.1.1节或第7.2节中的一种自动MiTM检测机制。或者依赖先前建立的缓存共享机密（pbxsecret或rs1或两者），在初始调用期间由人工执行的SAS比较支持。请注意，依靠来自远程端点的机器人语音来比较SAS比无用和绝对不安全更糟糕，因为MiTM可以轻易伪造机器人语音。然而，机器人的声音可以安全地用于不同的目的。如果没有可视显示可用，ZRTP用户代理可以通过机器人语音将其本地计算的SA呈现给本地用户，前提是用户可以容易地确定机器人语音是本地生成的，而不是从远程端点生成的。
A popular and field-proven approach to MiTM protection is used by SSH (Secure Shell) [RFC4251], which Peter Gutmann likes to call the "baby duck" security model. SSH establishes a relationship by exchanging public keys in the initial session, when we assume no attacker is present, and this makes it possible to authenticate all subsequent sessions. A successful MiTM attacker has to have been present in all
SSH（Secure Shell）[RFC4251]使用了一种流行且经过现场验证的MiTM保护方法，Peter Gutmann喜欢将其称为“baby duck”安全模型。SSH通过在初始会话中交换公钥建立了一种关系，而我们假设没有攻击者存在，这使得对所有后续会话进行身份验证成为可能。成功的MiTM攻击者必须在所有
sessions all the way back to the first one, which is assumed to be difficult for the attacker. ZRTP's key continuity features are actually better than SSH, at least for VoIP, for reasons described in Section 15.1. All this is accomplished without resorting to a centrally managed PKI.
会话一直返回到第一个会话，这对攻击者来说是很困难的。ZRTP的关键连续性特性实际上比SSH好，至少对于VoIP来说是这样，原因如第15.1节所述。所有这些都是在不借助中央管理的PKI的情况下实现的。
We use an analogous baby duck security model to authenticate the DH exchange in ZRTP. We don't need to exchange persistent public keys, we can simply cache a shared secret and re-use it to authenticate a long series of DH exchanges for secure phone calls over a long period of time. If we verbally compare just one SAS, and then cache a shared secret for later calls to use for authentication, no new voice authentication rituals need to be executed. We just have to remember we did one already.
我们使用一个类似的baby duck安全模型来验证ZRTP中的DH交换。我们不需要交换持久的公钥，我们可以简单地缓存一个共享的秘密，然后重新使用它来验证一长串DH交换，以便在很长一段时间内进行安全电话呼叫。如果我们只是口头比较一个SA，然后缓存一个共享的秘密以供以后的呼叫用于身份验证，则不需要执行新的语音身份验证仪式。我们只需要记住我们已经做过一次了。
If one party ever loses this cached shared secret, it is no longer available for authentication of DH exchanges. This cache mismatch situation is easy to detect by the party that still has a surviving shared secret cache entry. If it fails to match, either there is a MiTM attack or one side has lost their shared secret cache entry. The user agent that discovers the cache mismatch must alert the user that a cache mismatch has been detected, and that he must do a verbal comparison of the SAS to distinguish if the mismatch is because of a MiTM attack or because of the other party losing her cache (normative language is in Section 4.3.2). Voice confirmation is absolutely essential in this situation. From that point on, the two parties start over with a new cached shared secret. Then, they can go back to omitting the voice authentication on later calls.
如果一方丢失了这个缓存的共享秘密，它将不再可用于DH交换的身份验证。这种缓存不匹配的情况很容易被仍然有幸存共享秘密缓存项的一方检测到。如果不匹配，则表示存在MiTM攻击，或者一方丢失了共享秘密缓存条目。发现缓存不匹配的用户代理必须提醒用户已检测到缓存不匹配，并且他必须对SAS进行口头比较，以区分不匹配是因为MiTM攻击还是因为另一方丢失了缓存（规范性语言见第4.3.2节）。在这种情况下，语音确认是绝对必要的。从那时起，双方开始使用一个新的缓存共享秘密。然后，他们可以在以后的通话中省略语音认证。
Precautions must be observed when using a trusted MiTM device such as a trusted PBX, as described in Section 7.3. Make sure you really trust that this PBX will never be compromised before establishing it as a trusted MiTM, because it is in a position to wiretap calls for any phone that trusts it. It is "licensed" to be in a position to wiretap. You are safer to try to arrange the connection topology to route the media directly between the two ZRTP peers, not through a trusted PBX. Real end-to-end encryption is preferred.
如第7.3节所述，使用受信任的MiTM设备（如受信任的PBX）时，必须遵守预防措施。确保您真正相信，在将此PBX建立为受信任的MiTM之前，它将永远不会受到危害，因为它可以对任何信任它的电话进行窃听。它被“授权”可以进行窃听。您可以更安全地尝试安排连接拓扑，以便直接在两个ZRTP对等方之间路由媒体，而不是通过受信任的PBX。首选真正的端到端加密。
The security of the SAS mechanism depends on the user verifying it verbally with his peer at the other endpoint. There is some risk the user will not be so diligent and may ignore the SAS. For a discussion on how users become habituated to security warnings in the PKI certificate world, see [Sunshine]. Part of the problems discussed in that paper are from the habituation syndrome common to most warning messages, and part of them are from the fact that users simply don't understand trust models. Fortunately, ZRTP doesn't need a trust model to use the SAS mechanism, so it's easier for the user to grasp the idea of comparing the SAS verbally with the other party;
SAS机制的安全性取决于用户与另一个端点的对等方进行口头验证。存在一些风险，用户可能不会如此勤奋，可能会忽略SAS。有关用户如何习惯于PKI证书世界中的安全警告的讨论，请参阅[Sunshine]。论文中讨论的部分问题来自于大多数警告消息中常见的习惯化综合症，部分问题来自用户根本不理解信任模型这一事实。幸运的是，ZRTP不需要信任模型来使用SAS机制，因此用户更容易掌握口头比较SAS与另一方的想法；
it's easier than understanding a trust model, at least. Also, the verbal comparison of the SAS gets both users involved, and they will notice a mismatch of the SAS. Also, the ZRTP user agent will know when the SAS has been previously verified because of the SAS verified flag (V) (Section 7.1), and only ask the user to verify it when needed. After it has been verified once, the key continuity features make it unnecessary to verify it again.
至少，这比理解信任模型容易。此外，SAS的口头比较会让两个用户都参与进来，他们会注意到SAS不匹配。此外，由于SAS验证标志（V）（第7.1节），ZRTP用户代理将知道SAS之前何时已验证，并且仅在需要时要求用户验证。在对其进行一次验证后，关键连续性特征使得无需再次验证。
The key continuity features of ZRTP are analogous to those provided by SSH (Secure Shell) [RFC4251], but they differ in one respect. SSH caches public signature keys that never change, and uses a permanent private signature key that must be guarded from disclosure. If someone steals your SSH private signature key, they can impersonate you in all future sessions and can mount a successful MiTM attack any time they want.
ZRTP的关键连续性特性类似于SSH（安全Shell）[RFC4251]提供的特性，但它们在一个方面有所不同。SSH缓存永不更改的公共签名密钥，并使用必须防止泄露的永久私有签名密钥。如果有人窃取了您的SSH私有签名密钥，他们可以在将来的所有会话中模拟您，并可以随时成功地发起MiTM攻击。
ZRTP caches symmetric key material used to compute secret session keys, and these values change with each session. If someone steals your ZRTP shared secret cache, they only get one chance to mount a MiTM attack, in the very next session. If they miss that chance, the retained shared secret is refreshed with a new value, and the window of vulnerability heals itself, which means they are locked out of any future opportunities to mount a MiTM attack. This gives ZRTP a "self-healing" feature if any cached key material is compromised.
ZRTP缓存用于计算秘密会话密钥的对称密钥材料，并且这些值随每个会话而变化。如果有人窃取了你的ZRTP共享秘密缓存，他们只有一次机会在下一个会话中发起MiTM攻击。如果他们错过了这个机会，保留的共享机密将被刷新为一个新值，漏洞窗口将自行修复，这意味着他们将被锁定在未来任何发动MiTM攻击的机会之外。这为ZRTP提供了一个“自我修复”功能，如果任何缓存的密钥材料被破坏。
A MiTM attacker must always be in the media path. This presents a significant operational burden for the attacker in many VoIP usage scenarios, because being in the media path for every call is often harder than being in the signaling path. This will likely create coverage gaps in the attacker's opportunities to mount a MiTM attack. ZRTP's self-healing key continuity features are better than SSH at exploiting any temporary gaps in MiTM attack opportunities. Thus, ZRTP quickly recovers from any disclosure of cached key material.
MiTM攻击者必须始终位于媒体路径中。在许多VoIP使用场景中，这给攻击者带来了巨大的操作负担，因为每次呼叫都在媒体路径中通常比在信令路径中更难。这可能会在攻击者发起MiTM攻击的机会中造成覆盖率差距。ZRTP的自愈密钥连续性功能在利用MiTM攻击机会中的任何临时漏洞方面都优于SSH。因此，ZRTP可以从任何缓存密钥材料的泄漏中快速恢复。
In systems that use a persistent private signature key, such as SSH, the stored signature key is usually protected from disclosure by encryption that requires a user-supplied high-entropy passphrase. This arrangement may be acceptable for a diligent user with a desktop computer sitting in an office with a full ASCII keyboard. But it would be prohibitively inconvenient and unsafe to type a high-entropy passphrase on a mobile phone's numeric keypad while driving a car. Users will reject any scheme that requires the use of a passphrase on such a platform, which means mobile phones carry an elevated risk of compromise of stored key material, and thus would especially benefit from the self-healing aspects of ZRTP's key continuity features.
在使用持久私有签名密钥（如SSH）的系统中，存储的签名密钥通常通过需要用户提供的高熵密码短语的加密进行保护，以防泄露。对于勤勉的用户来说，这种安排可能是可以接受的，他们在办公室里坐着一台台式计算机，拥有完整的ASCII键盘。但在开车时，在手机的数字键盘上键入高熵密码短语将非常不方便和不安全。用户将拒绝任何要求在此类平台上使用密码短语的方案，这意味着移动电话对存储的密钥材料具有较高的泄露风险，因此将特别受益于ZRTP关键连续性功能的自我修复方面。
The infamous Debian OpenSSL weak key vulnerability [dsa-1571] (discovered and patched in May 2008) offers a real-world example of why ZRTP's self-healing scheme is a good way to do key continuity. The Debian bug resulted in the production of a lot of weak SSH (and TLS/SSL) keys, which continued to compromise security even after the bug had been patched. In contrast, ZRTP's key continuity scheme adds new entropy to the cached key material with every call, so old deficiencies in entropy are washed away with each new session.
臭名昭著的Debian OpenSSL弱密钥漏洞[dsa-1571]（2008年5月发现并修补）提供了一个真实的例子，说明了为什么ZRTP的自愈方案是实现密钥连续性的好方法。Debian缺陷导致产生了大量弱SSH（和TLS/SSL）密钥，即使在缺陷被修补之后，这些密钥仍然会损害安全性。相比之下，ZRTP的密钥连续性方案在每次调用时都会向缓存的密钥材料添加新的熵，因此每次新会话都会消除熵中的旧缺陷。
It should be noted that the addition of shared secret entropy from previous sessions can extend the strength of the new session key to AES-256 levels, even if the new session uses Diffie-Hellman keys no larger than DH-3072 or ECDH-256, provided the cached shared secrets were initially established when the wiretapper was not present. This is why AES-256 MAY be used with the smaller DH key sizes in Section 5.1.5, despite the key strength comparisons in Table 2 of [NIST-SP800-57-Part1].
应该注意的是，添加以前会话的共享秘密熵可以将新会话密钥的强度扩展到AES-256级别，即使新会话使用的Diffie-Hellman密钥不大于DH-3072或ECDH-256，前提是缓存的共享秘密最初是在Wiretaper不存在时建立的。这就是为什么尽管[NIST-SP800-57-Part1]表2中有键强度比较，但AES-256可用于第5.1.5节中较小的DH键尺寸。
Caching shared symmetric key material is also less CPU intensive compared with using digital signatures, which may be important for low-power mobile platforms.
与使用数字签名相比，缓存共享对称密钥材料的CPU占用更少，这对于低功耗移动平台可能很重要。
Unlike the long-lived non-updated key material used by SSH, the dynamically updated shared secrets of ZRTP may lose sync if traditional backup/restore mechanisms are used. This limitation is a consequence of the otherwise beneficial aspects of this approach to key continuity, and it is partially mitigated by ZRTP's built-in cache backup logic (Section 4.6.1).
与SSH使用的长期未更新的密钥材料不同，如果使用传统的备份/恢复机制，动态更新的ZRTP共享机密可能会失去同步。这种限制是这种密钥连续性方法在其他方面有益的结果，ZRTP的内置缓存备份逻辑（第4.6.1节）部分缓解了这种限制。
The authors would like to thank Bryce "Zooko" Wilcox-O'Hearn and Colin Plumb for their contributions to the design of this protocol. Also, thanks to Hal Finney, Viktor Krikun, Werner Dittmann, Dan Wing, Sagar Pai, David McGrew, Colin Perkins, Dan Harkins, David Black, Tim Polk, Richard Harris, Roni Even, Jon Peterson, and Robert Sparks for their helpful comments and suggestions. Thanks to Lily Chen at NIST for her assistance in ensuring compliance with NIST SP800-56A and SP800-108.
作者要感谢Bryce“Zooko”Wilcox-O'Hearn和Colin Plumb对本协议设计的贡献。此外，还要感谢哈尔·芬尼、维克托·克里昆、沃纳·迪特曼、丹·温、萨加尔·派、大卫·麦克格雷夫、科林·帕金斯、丹·哈金斯、大卫·布莱克、蒂姆·波尔克、理查德·哈里斯、甚至罗尼、乔恩·彼得森和罗伯特·斯帕克斯，感谢他们提供了有益的意见和建议。感谢NIST的Lily Chen协助确保遵守NIST SP800-56A和SP800-108。
The use of one-way hash chains to key HMACs in ZRTP is similar to Adrian Perrig's TESLA protocol [TESLA].
在ZRTP中使用单向散列链对HMAC进行键控类似于Adrian Perrig的TESLA协议[TESLA]。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
[RFC3526]Kivinen，T.和M.Kojo，“互联网密钥交换（IKE）的更多模指数（MODP）Diffie-Hellman群”，RFC 3526，2003年5月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC 4231, December 2005.
[RFC4231]Nystrom，M.“HMAC-SHA-224、HMAC-SHA-256、HMAC-SHA-384和HMAC-SHA-512的标识符和测试向量”，RFC 42312005年12月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[RFC4880]Callas，J.，Donnerhacke，L.，Finney，H.，Shaw，D.，和R.Thayer，“OpenPGP消息格式”，RFC 48802007年11月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，“流控制传输协议”，RFC 49602007年9月。
[RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman Groups for Use with IETF Standards", RFC 5114, January 2008.
[RFC5114]Lepinski，M.和S.Kent，“与IETF标准一起使用的其他Diffie-Hellman组”，RFC 5114，2008年1月。
[RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, "Requirements and Analysis of Media Security Management Protocols", RFC 5479, April 2009.
[RFC5479]Wing，D.，Fries，S.，Tschofenig，H.，和F.Audet，“媒体安全管理协议的要求和分析”，RFC 5479，2009年4月。
[RFC5759] Solinas, J. and L. Zieglar, "Suite B Certificate and Certificate Revocation List (CRL) Profile", RFC 5759, January 2010.
[RFC5759]Solinas，J.和L.Zieglar，“套件B证书和证书撤销列表（CRL）配置文件”，RFC 5759，2010年1月。
[RFC6188] McGrew, D., "The Use of AES-192 and AES-256 in Secure RTP", RFC 6188, March 2011.
[RFC6188]McGrew，D.“AES-192和AES-256在安全RTP中的使用”，RFC 6188，2011年3月。
[FIPS-140-2-Annex-A] "Annex A: Approved Security Functions for FIPS PUB 140-2", NIST FIPS PUB 140-2 Annex A, January 2011.
[FIPS-140-2-附件A]“附件A：经批准的FIPS PUB 140-2安全功能”，NIST FIPS PUB 140-2附件A，2011年1月。
[FIPS-140-2-Annex-D] "Annex D: Approved Key Establishment Techniques for FIPS PUB 140-2", NIST FIPS PUB 140-2 Annex D, January 2011.
[FIPS-140-2-附件D]“附件D：经批准的FIPS PUB 140-2关键设施技术”，NIST FIPS PUB 140-2附件D，2011年1月。
[FIPS-180-3] "Secure Hash Standard (SHS)", NIST FIPS PUB 180-3, October 2008.
[FIPS-180-3]“安全哈希标准（SHS）”，NIST FIPS PUB 180-3，2008年10月。
[FIPS-186-3] "Digital Signature Standard (DSS)", NIST FIPS PUB 186- 3, June 2009.
[FIPS-186-3]“数字签名标准（DSS）”，NIST FIPS PUB 186-3，2009年6月。
[FIPS-197] "Advanced Encryption Standard (AES)", NIST FIPS PUB 197, November 2001.
[FIPS-197]“高级加密标准（AES）”，NIST FIPS PUB 197，2001年11月。
[FIPS-198-1] "The Keyed-Hash Message Authentication Code (HMAC)", NIST FIPS PUB 198-1, July 2008.
[FIPS-198-1]“密钥散列消息认证码（HMAC）”，NIST FIPS PUB 198-12008年7月。
[NIST-SP800-38A] Dworkin, M., "Recommendation for Block Cipher Modes of Operation", NIST Special Publication 800-38A, 2001 Edition.
[NIST-SP800-38A]德沃金，M.，“分组密码操作模式建议”，NIST特别出版物800-38A，2001年版。
[NIST-SP800-56A] Barker, E., Johnson, D., and M. Smid, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography", NIST Special Publication 800- 56A Revision 1, March 2007.
[NIST-SP800-56A]Barker，E.，Johnson，D.和M.Smid，“使用离散对数加密的成对密钥建立方案的建议”，NIST特别出版物800-56A第1版，2007年3月。
[NIST-SP800-90] Barker, E. and J. Kelsey, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators", NIST Special Publication 800-90 (Revised), March 2007.
[NIST-SP800-90]Barker，E.和J.Kelsey，“使用确定性随机位生成器生成随机数的建议”，NIST特别出版物800-90（修订版），2007年3月。
[NIST-SP800-108] Chen, L., "Recommendation for Key Derivation Using Pseudorandom Functions", NIST Special Publication 800- 108, October 2009.
[NIST-SP800-108]Chen，L.“使用伪随机函数进行密钥推导的建议”，NIST特别出版物800-108，2009年10月。
[NSA-Suite-B] "NSA Suite B Cryptography", NSA Information Assurance Directorate, NSA Suite B Cryptography.
[NSA-Suite-B]“NSA套件B加密”，NSA信息保障局，NSA套件B加密。
[NSA-Suite-B-Guide-56A] "Suite B Implementer's Guide to NIST SP 800-56A", Suite B Implementer's Guide to NIST SP 800-56A, 28 July 2009.
[NSA-Suite-B-Guide-56A]“NIST SP 800-56A B套件实施者指南”，NIST SP 800-56A B套件实施者指南，2009年7月28日。
[TwoFish] Schneier, B., Kelsey, J., Whiting, D., Hall, C., and N. Ferguson, "Twofish: A 128-Bit Block Cipher", June 1998, <http://www.schneier.com/paper-twofish-paper.html>.
[TwoFish]Schneier，B.，Kelsey，J.，Whiting，D.，Hall，C.，和N.Ferguson，“TwoFish:128位分组密码”，1998年6月<http://www.schneier.com/paper-twofish-paper.html>.
[Skein] Ferguson, N., Lucks, S., Schneier, B., Whiting, D., Bellare, M., Kohno, T., Callas, J., and J. Walker, "The Skein Hash Function Family, Version 1.3 - 1 Oct 2010", <ht tp://www.skein-hash.info/sites/default/files/ skein1.3.pdf>.
[Skein]Ferguson，N.，Lucks，S.，Schneier，B.，Whiting，D.，Bellare，M.，Kohno，T.，Callas，J.，和J.Walker，“Skein哈希函数族，版本1.3-2010年10月1日”，<ht-tp://www.Skein-Hash.info/sites/default/files/skein1.3.pdf>。
[pgpwordlist] "PGP Word List", December 2010, <http://en.wikipedia.org/ w/index.php?title=PGP_word_list&oldid=400752943>.
[PGP词汇表]“PGP词汇表”，2010年12月<http://en.wikipedia.org/ w/index.php？title=PGP\u word\u list&oldid=400752943>。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]McCann，J.，Deering，S.，和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3514] Bellovin, S., "The Security Flag in the IPv4 Header", RFC 3514, April 1 2003.
[RFC3514]Bellovin，S.，“IPv4报头中的安全标志”，RFC 3514，2003年4月1日。
[RFC3824] Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using E.164 numbers with the Session Initiation Protocol (SIP)", RFC 3824, June 2004.
[RFC3824]Peterson，J.，Liu，H.，Yu，J.，和B.Campbell，“在会话启动协议（SIP）中使用E.164号码”，RFC 38242004年6月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[RFC4251]Ylonen，T.和C.Lonvick，“安全外壳（SSH）协议架构”，RFC 4251，2006年1月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474]Peterson，J.和C.Jennings，“会话启动协议（SIP）中身份验证管理的增强”，RFC 4474，2006年8月。
[RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, May 2006.
[RFC4475]Sparks，R.，Hawrylyshen，A.，Johnston，A.，Rosenberg，J.，和H.Schulzrinne，“会话启动协议（SIP）酷刑测试消息”，RFC 4475，2006年5月。
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. Carrara, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, July 2006.
[RFC4567]Arkko，J.，Lindholm，F.，Naslund，M.，Norrman，K.，和E.Carrara，“会话描述协议（SDP）和实时流协议（RTSP）的密钥管理扩展”，RFC 4567，2006年7月。
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
[RFC4568]Andreasen，F.，Baugher，M.和D.Wing，“媒体流的会话描述协议（SDP）安全描述”，RFC 4568，2006年7月。
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, August 2006.
[RFC4579]Johnston，A.和O.Levin，“会话发起协议（SIP）呼叫控制-用户代理会议”，BCP 119，RFC 4579，2006年8月。
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008.
[RFC5117]Westerlund，M.和S.Wenger，“RTP拓扑”，RFC 51172008年1月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 52452010年4月。
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC5764]McGrew，D.和E.Rescorla，“为安全实时传输协议（SRTP）建立密钥的数据报传输层安全（DTLS）扩展”，RFC 5764，2010年5月。
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, May 2010.
[RFC5869]Krawczyk，H.和P.Eronen，“基于HMAC的提取和扩展密钥派生函数（HKDF）”，RFC 5869，2010年5月。
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011.
[RFC6090]McGrew，D.，Igoe，K.，和M.Salter，“基本椭圆曲线密码算法”，RFC 60902011年2月。
[SRTP-AES-GCM] McGrew, D., "AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP)", Work in Progress, January 2011.
[SRTP-AES-GCM]McGrew，D.，“安全RTP（SRTP）中的AES-GCM和AES-CCM认证加密”，正在进行的工作，2011年1月。
[ECC-OpenPGP] Jivsov, A., "ECC in OpenPGP", Work in Progress, March 2011.
[ECC OpenPGP]Jivsov，A.，“OpenPGP中的ECC”，正在进行的工作，2011年3月。
[VBR-AUDIO] Perkins, C. and J. Valin, "Guidelines for the use of Variable Bit Rate Audio with Secure RTP", Work in Progress, December 2010.
[VBR-AUDIO]Perkins，C.和J.Valin，“带安全RTP的可变比特率音频使用指南”，正在进行的工作，2010年12月。
[SIP-IDENTITY] Wing, D. and H. Kaplan, "SIP Identity using Media Path", Work in Progress, February 2008.
[SIP-IDENTITY]Wing，D.和H.Kaplan，“使用媒体路径的SIP身份”，正在进行的工作，2008年2月。
[NIST-SP800-57-Part1] Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, "Recommendation for Key Management - Part 1: General (Revised)", NIST Special Publication 800-57 - Part 1 Revised March 2007.
[NIST-SP800-57-第1部分]Barker，E.，Barker，W.，Burr，W.，Polk，W.，和M.Smid，“关键管理建议-第1部分：概述（修订）”，NIST特别出版物800-57-第1部分，2007年3月修订。
[NIST-SP800-131A] Barker, E. and A. Roginsky, "Recommendation for the Transitioning of Cryptographic Algorithms and Key Lengths", NIST Special Publication 800-131A January 2011.
[NIST-SP800-131A]Barker，E.和A.Roginsky，“密码算法和密钥长度转换建议”，NIST特别出版物800-131A，2011年1月。
[SHA-3] "Cryptographic Hash Algorithm Competition", NIST Computer Security Resource Center Cryptographic Hash Project.
[SHA-3]“加密哈希算法竞赛”，NIST计算机安全资源中心加密哈希项目。
[Skein1] "The Skein Hash Function Family - Web site", <http://www.skein-hash.info/>.
[Skein1]“Skein哈希函数系列-网站”<http://www.skein-hash.info/>.
[XEP-0262] Saint-Andre, P., "Use of ZRTP in Jingle RTP Sessions", XSF XEP 0262, August 2010.
[XEP-0262]圣安德烈，P.，“ZRTP在叮当乐RTP会议中的使用”，XSF XEP 0262，2010年8月。
[Ferguson] Ferguson, N. and B. Schneier, "Practical Cryptography", Wiley Publishing, 2003.
[Ferguson]Ferguson，N.和B.Schneier，“实用密码学”，威利出版社，2003年。
[Juola1] Juola, P. and P. Zimmermann, "Whole-Word Phonetic Distances and the PGPfone Alphabet", Proceedings of the International Conference of Spoken Language Processing (ICSLP-96), 1996.
[Juola1]Juola，P.和P.Zimmermann，“全词语音距离和PGPfone字母表”，国际口语处理会议记录（ICSLP-96），1996年。
[Juola2] Juola, P., "Isolated Word Confusion Metrics and the PGPfone Alphabet", Proceedings of New Methods in Language Processing, 1996.
[Juola2]Juola，P.，“孤立词混淆度量和PGPfone字母表”，语言处理新方法学报，1996年。
[PGPfone] Zimmermann, P., "PGPfone", July 1996, <http://philzimmermann.com/docs/pgpfone10b7.pdf>.
[PGPfone]齐默尔曼，P.，“PGPfone”，1996年7月<http://philzimmermann.com/docs/pgpfone10b7.pdf>.
[Zfone] Zimmermann, P., "Zfone Project", 2006, <http://www.philzimmermann.com/zfone>.
[Zfone]Zimmermann，P.，“Zfone项目”，2006年<http://www.philzimmermann.com/zfone>.
[Byzantine] "The Two Generals' Problem", March 2011, <http:// en.wikipedia.org/w/ index.php?title=Two_Generals%27_Problem&oldid=417855753>.
[拜占庭]“两位将军的问题”，2011年3月，<http://en.wikipedia.org/w/index.php？title=Two_Generals%27_Problem&oldid=417855753>。
[TESLA] Perrig, A., Canetti, R., Tygar, J., and D. Song, "The TESLA Broadcast Authentication Protocol", October 2002, <h ttp://www.ece.cmu.edu/~adrian/projects/tesla-cryptobytes/ tesla-cryptobytes.pdf>.
[TESLA]Perrig，A.，Canetti，R.，Tygar，J.，和D.Song，“特斯拉广播认证协议”，2002年10月，<http://www.ece.cmu.edu/~adrian/projects/tesla cryptobytes/tesla cryptobytes.pdf>。
[comsec] Blossom, E., "The VP1 Protocol for Voice Privacy Devices Version 1.2", <http://www.comsec.com/vp1-protocol.pdf>.
[comsec]Blossom，E.，“语音隐私设备的VP1协议版本1.2”<http://www.comsec.com/vp1-protocol.pdf>.
[Wright1] Wright, C., Ballard, L., Coull, S., Monrose, F., and G. Masson, "Spot me if you can: Uncovering spoken phrases in encrypted VoIP conversations", Proceedings of the 2008 IEEE Symposium on Security and Privacy 2008, <http://cs.jhu.edu/~cwright/oakland08.pdf>.
[Wright 1]Wright，C.，Ballard，L.，Coull，S.，Monrose，F.，和G.Masson，“如果可以的话发现我：在加密的VoIP对话中发现口语短语”，2008年IEEE安全和隐私研讨会论文集2008<http://cs.jhu.edu/~cwright/oakland08.pdf>。
[Sunshine] Sunshine, J., Egelman, S., Almuhimedi, H., Atri, N., and L. Cranor, "Crying Wolf: An Empirical Study of SSL Warning Effectiveness", USENIX Security Symposium 2009, <http://lorrie.cranor.org/pubs/sslwarnings.pdf>.
[Sunshine]Sunshine，J.，Egelman，S.，Almuhimedi，H.，Atri，N.，和L.Cranor，“狼来了：SSL警告有效性的实证研究”，USENIX安全研讨会2009<http://lorrie.cranor.org/pubs/sslwarnings.pdf>.
[dsa-1571] "Debian Security Advisory - OpenSSL predictable random number generator", May 2008, <http://www.debian.org/security/2008/dsa-1571>.
[dsa-1571]“Debian安全咨询-OpenSSL可预测随机数生成器”，2008年5月<http://www.debian.org/security/2008/dsa-1571>.
Authors' Addresses
作者地址
Philip Zimmermann Zfone Project Santa Cruz, California
Philip Zimmermann Zfone项目加利福尼亚州圣克鲁斯
EMail: prz@mit.edu
URI: http://philzimmermann.com
EMail: prz@mit.edu
URI: http://philzimmermann.com
Alan Johnston (editor) Avaya St. Louis, MO 63124
艾伦·约翰斯顿（编辑）密苏里州圣路易斯阿瓦亚63124
EMail: alan.b.johnston@gmail.com
EMail: alan.b.johnston@gmail.com
Jon Callas Apple, Inc.
乔恩·卡拉斯苹果公司。
EMail: jon@callas.org
EMail: jon@callas.org