Internet Engineering Task Force (IETF) S. Yoon
Request for Comments: 5669 J. Kim
Category: Standards Track H. Park
ISSN: 2070-1721 H. Jeong
Y. Won
Korea Internet & Security Agency
August 2010
Internet Engineering Task Force (IETF) S. Yoon
Request for Comments: 5669 J. Kim
Category: Standards Track H. Park
ISSN: 2070-1721 H. Jeong
Y. Won
Korea Internet & Security Agency
August 2010
The SEED Cipher Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP)
种子密码算法及其在安全实时传输协议（SRTP）中的应用
Abstract
摘要
This document describes the use of the SEED block cipher algorithm in the Secure Real-time Transport Protocol (SRTP) for providing confidentiality for Real-time Transport Protocol (RTP) traffic and for the control traffic for RTP, the Real-time Transport Control Protocol (RTCP).
本文档描述了在安全实时传输协议（SRTP）中使用种子分组密码算法为实时传输协议（RTP）流量和实时传输控制协议（RTCP）的控制流量提供保密性。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc5669.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5669.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
1.1. SEED .......................................................3
1.2. Terminology ................................................3
1.3. Definitions ................................................3
2. Cryptographic Transforms ........................................4
2.1. Counter ....................................................4
2.1.1. Message Authentication/Integrity: HMAC-SHA1 .........4
2.2. Counter with CBC-MAC (CCM) .................................4
2.3. Galois/Counter Mode (GCM) ..................................6
3. Nonce Format for CCM and GCM ....................................6
3.1. Nonce for SRTP .............................................6
3.2. Nonce for SRTCP ............................................6
4. Key Derivation: SEED-CTR PRF ....................................7
5. Mandatory-to-Implement Transforms ...............................7
6. Security Considerations .........................................7
7. IANA Considerations .............................................8
8. Acknowledgements ................................................8
9. References ......................................................8
9.1. Normative References .......................................8
9.2. Informative References .....................................9
Appendix A. Test Vectors ..........................................10
A.1. SEED-CTR Test Vectors .....................................10
A.2. SEED-CCM Test Vectors .....................................11
A.3. SEED-GCM Test Vectors .....................................12
1. Introduction ....................................................3
1.1. SEED .......................................................3
1.2. Terminology ................................................3
1.3. Definitions ................................................3
2. Cryptographic Transforms ........................................4
2.1. Counter ....................................................4
2.1.1. Message Authentication/Integrity: HMAC-SHA1 .........4
2.2. Counter with CBC-MAC (CCM) .................................4
2.3. Galois/Counter Mode (GCM) ..................................6
3. Nonce Format for CCM and GCM ....................................6
3.1. Nonce for SRTP .............................................6
3.2. Nonce for SRTCP ............................................6
4. Key Derivation: SEED-CTR PRF ....................................7
5. Mandatory-to-Implement Transforms ...............................7
6. Security Considerations .........................................7
7. IANA Considerations .............................................8
8. Acknowledgements ................................................8
9. References ......................................................8
9.1. Normative References .......................................8
9.2. Informative References .....................................9
Appendix A. Test Vectors ..........................................10
A.1. SEED-CTR Test Vectors .....................................10
A.2. SEED-CCM Test Vectors .....................................11
A.3. SEED-GCM Test Vectors .....................................12
This document describes the use of the SEED [RFC4269] block cipher algorithm in the Secure Real-time Transport Protocol (SRTP) [RFC3711] for providing confidentiality for Real-time Transport Protocol (RTP) [RFC3550] traffic and for the control traffic for RTP, the Real-time Transport Control Protocol (RTCP) [RFC3550].
本文档描述了在安全实时传输协议（SRTP）[RFC3711]中使用SEED[RFC4269]分组密码算法，为实时传输协议（RTP）[RFC3550]通信量和RTP的控制通信量（实时传输控制协议（RTCP）[RFC3550]提供保密性。
SEED is a symmetric encryption algorithm that was developed by the Korea Information Security Agency (KISA) and a group of experts, beginning in 1998. The input/output block size of SEED is 128-bit and the key length is also 128-bit. SEED has the 16-round Feistel structure. A 128-bit input is divided into two 64-bit blocks and the right 64-bit block is an input to the round function with a 64-bit subkey generated from the key scheduling.
SEED是一种对称加密算法，由韩国信息安全局（KISA）和一组专家从1998年开始开发。种子的输入/输出块大小为128位，密钥长度也为128位。种子具有16个圆形的Feistel结构。128位输入被分为两个64位块，右64位块是round函数的输入，具有从密钥调度生成的64位子密钥。
SEED is easily implemented in various software and hardware because it is designed to increase the efficiency of memory storage and the simplicity of generating keys without degrading the security of the algorithm. In particular, it can be effectively adopted in a computing environment that has restricted resources such as mobile devices, smart cards, and so on.
SEED易于在各种软件和硬件中实现，因为它旨在提高内存存储的效率和生成密钥的简单性，而不会降低算法的安全性。特别是，它可以有效地应用于资源受限的计算环境，如移动设备、智能卡等。
SEED is a national industrial association standard [TTASSEED] and is widely used in South Korea for electronic commerce and financial services operated on wired and wireless PKI.
SEED是一项国家工业协会标准[TTASSEED]，在韩国广泛用于基于有线和无线PKI的电子商务和金融服务。
The algorithm specification and object identifiers are described in [RFC4269]. The SEED homepage, http://seed.kisa.or.kr/eng/main.jsp, contains a wealth of information about SEED, including detailed specification, evaluation report, test vectors, and so on.
[RFC4269]中描述了算法规范和对象标识符。种子主页，http://seed.kisa.or.kr/eng/main.jsp，包含有关种子的丰富信息，包括详细的规格说明、评估报告、测试向量等。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
|| concatenation XOR exclusive or
||级联异或异或异或
All symmetric block cipher algorithms share common characteristics, including mode, key size, weak keys, and block size. The following sections contain descriptions of the relevant characteristics of SEED.
所有对称分组密码算法都具有共同的特征，包括模式、密钥大小、弱密钥和块大小。以下各节包含种子相关特性的说明。
SEED does not have any restrictions for modes of operation that are used with this block cipher. We define three modes of running SEED: (1) SEED in counter mode, (2) SEED in counter mode with CBC-MAC (CCM), and (3) SEED in Galois/Counter Mode (GCM).
SEED对此分组密码使用的操作模式没有任何限制。我们定义了三种运行种子的模式：（1）计数器模式下的种子，（2）CBC-MAC（CCM）计数器模式下的种子，（3）Galois/计数器模式下的种子（GCM）。
Section 4.1.1 of [RFC3711] defines AES counter mode encryption, which that document refers to as AES-CM. SEED counter mode is defined in a similar manner and is denoted as SEED-CTR. The plaintext inputs to the block cipher are formed as in AES-CM, and the block cipher outputs are processed as in AES-CM. The only difference in the processing is that SEED-CTR uses SEED as the underlying encryption primitive. When SEED-CTR is used, it MUST be used only in conjunction with an authentication function.
[RFC3711]第4.1.1节定义了AES计数器模式加密，该文件称之为AES-CM。种子计数器模式以类似方式定义，并表示为SEED-CTR。分组密码的明文输入按AES-CM格式形成，分组密码输出按AES-CM格式处理。处理过程中唯一的区别是SEED-CTR使用SEED作为底层加密原语。使用SEED-CTR时，它只能与身份验证功能结合使用。
HMAC-SHA1 [RFC2104], as defined in Section 4.2.1 of [RFC3711], SHALL be the default message-authentication code to be used with SEED-CTR. The default session-authentication key length SHALL be 160 bits, the default authentication tag length SHALL be 80 bits, and the SRTP_PREFIX_LENGTH SHALL be zero for HMAC-SHA1. For SRTP, smaller values are NOT RECOMMENDED but MAY be used after careful consideration of the issues discussed in Sections 7.5 and 9.5 of [RFC3711].
[RFC3711]第4.2.1节中定义的HMAC-SHA1[RFC2104]应为SEED-CTR使用的默认消息认证码。HMAC-SHA1的默认会话认证密钥长度应为160位，默认认证标签长度应为80位，SRTP_前缀_长度应为零。对于SRTP，不建议使用较小的值，但可在仔细考虑[RFC3711]第7.5节和第9.5节中讨论的问题后使用。
CCM [RFC3610] is a generic authenticate-and-encrypt block cipher mode. In this specification, CCM used with the SEED block cipher is denoted as SEED-CCM.
CCM[RFC3610]是一种通用的身份验证和加密分组密码模式。在本规范中，与SEED分组密码一起使用的CCM表示为SEED-CCM。
Section 3.3 of [RFC3711] defines procedures to construct or to authenticate and decrypt SRTP packets. For SEED-CCM, however, the sender performs Step 7 before Step 5 and the receiver performs the second half of Step 5 (verification) after Step 6. This means that authentication is performed on the plaintext rather than the ciphertext. This applies equally to SRTCP.
[RFC3711]第3.3节定义了构造或验证和解密SRTP数据包的程序。然而，对于SEED-CCM，发送方在步骤5之前执行步骤7，接收方在步骤6之后执行步骤5（验证）的后半部分。这意味着认证是在明文而不是密文上执行的。这同样适用于SRTCP。
All SRTP packets MUST be authenticated and encrypted. Unlike SRTP, Secure Real-time Transport Control Protocol (SRTCP) packet encryption is optional (but authentication is mandatory). A sender can select which packets to encrypt and indicates this choice with a 1-bit encryption flag (located in the leftmost bit of the 32-bit word that contains the SRTCP index).
所有SRTP数据包必须经过身份验证和加密。与SRTP不同，安全实时传输控制协议（SRTCP）数据包加密是可选的（但身份验证是强制性的）。发送方可以选择要加密的数据包，并使用1位加密标志（位于包含SRTCP索引的32位字的最左位）指示此选择。
SEED-CCM has two parameters:
SEED-CCM有两个参数：
M M indicates the size of the authentication tag. In SRTP, a full 80-bit authentication tag SHOULD be used and implementation of this specification MUST support M values of 10 octets.
M表示身份验证标记的大小。在SRTP中，应使用完整的80位身份验证标签，并且该规范的实现必须支持10个八位字节的M值。
L L indicates the size of the length field in octets. The number of octets in the nonce MUST be 12, i.e., L is 3.
L表示长度字段的大小（以八位字节为单位）。当前值中的八位字节数必须为12，即L为3。
SEED-CCM has four inputs:
SEED-CCM有四个输入：
Key
钥匙
A single key is used to calculate the authentication tag (using CBC-MAC) and to perform payload encryption using counter mode. SEED only supports a key size of 128 bits.
单个密钥用于计算身份验证标签（使用CBC-MAC）并使用计数器模式执行有效负载加密。种子仅支持128位的密钥大小。
Nonce
暂时
The size of the nonce depends on the value selected for the parameter L. It is 15-L octets. L equals 3, and hence the nonce size equals 12 octets.
nonce的大小取决于为参数L选择的值。它是15-L八位字节。L等于3，因此nonce大小等于12个八位字节。
Plaintext
明文
In the case of SRTP, the payload of the RTP packet, the RTP padding, and the RTP pad count field (if the latter two fields are present) are treated as plaintext.
在SRTP的情况下，RTP分组的有效载荷、RTP填充和RTP填充计数字段（如果后两个字段存在）被视为纯文本。
In the case of SRTCP, when the encryption flag is set to 1, the Encrypted Portion described in Fig.2 of [RFC3711] is treated as plaintext. When the encryption flag is set to 0, the plaintext is zero-length.
在SRTCP的情况下，当加密标志设置为1时，[RFC3711]的图2中描述的加密部分被视为明文。当加密标志设置为0时，明文长度为零。
Additional Authentication Data (AAD)
附加身份验证数据（AAD）
In the case of SRTP, the header of the RTP packet, including the contributing source (CSRC) identifier (if present) and the RTP header extension (if present), is considered AAD.
在SRTP的情况下，RTP分组的报头，包括贡献源（csc）标识符（如果存在）和RTP报头扩展（如果存在），被认为是AAD。
In the case of SRTCP, when the encryption flag is set to 0, the Authentication Portion described in Fig.2 of [RFC3711] is treated as AAD. When the encryption flag is set to 1, the first 8 octets, the encryption flag, and the SRTCP index are treated as AAD.
在SRTCP的情况下，当加密标志设置为0时，[RFC3711]的图2中描述的认证部分被视为AAD。当加密标志设置为1时，前8个八位字节、加密标志和SRTCP索引将被视为AAD。
SEED-CCM accepts these four inputs and returns a ciphertext field.
SEED-CCM接受这四个输入并返回一个密文字段。
GCM is a block cipher mode of operation providing both confidentiality and data origin authentication [GCM]. GCM used with the SEED block cipher is denoted as SEED-GCM.
GCM是一种分组密码操作模式，提供机密性和数据源身份验证[GCM]。和SEED分组密码一起使用的GCM表示为SEED-GCM。
SEED-GCM has four inputs: a key, a plaintext, a nonce, and the additional authenticated data (AAD), all described in Section 2.2.
SEED-GCM有四个输入：密钥、明文、nonce和附加认证数据（AAD），所有这些都在第2.2节中描述。
The bit length of the tag, denoted t, is 12, and an authentication tag with a length of 12 octets (96 bits) is used.
标记的位长度（表示为t）为12，并且使用长度为12个八位字节（96位）的认证标记。
The nonce for SRTP SHALL be formed in the following way:
SRTP的nonce应按以下方式形成：
Nonce = (16 bits of zeroes || SSRC || ROC || SEQ) XOR Salt
Nonce = (16 bits of zeroes || SSRC || ROC || SEQ) XOR Salt
The 4-octet SSRC and the 2-octet SEQ SHALL be taken from the RTP header. The 4-octet ROC is from the cryptographic context. The 12-octet Salt SHALL be produced by the SRTP key derivation function.
4-八位组SSRC和2-八位组SEQ应取自RTP标头。4-octet ROC来自加密上下文。12八位组盐应由SRTP密钥派生函数生成。
The nonce for SRTCP SHALL be formed in the following way:
SRTCP的nonce应按以下方式形成：
Nonce = (16 bits of zeroes || SSRC || 16 bits of zeroes ||
SRTCP index) XOR Salt
Nonce = (16 bits of zeroes || SSRC || 16 bits of zeroes ||
SRTCP index) XOR Salt
The 4-octet SSRC SHALL be taken from the RTCP header and the 31-bit SRTCP index (packed zero-filled and right-justified into a 4-octet field) is from each packet. The 12-octet Salt SHALL be produced by the SRTP key derivation function.
4-八位组SSRC应取自RTCP报头，31位SRTCP索引（压缩为零并右对齐为4-八位组字段）取自每个数据包。12八位组盐应由SRTP密钥派生函数生成。
Section 4.3.3 of [RFC3711] defines the AES-128 counter mode key derivation function, which it refers to as "AES-CM PRF". The SEED-CTR PRF is defined in a similar manner, but with each invocation of AES replaced with an invocation of SEED.
[RFC3711]第4.3.3节定义了AES-128计数器模式密钥派生函数，该函数称为“AES-CM PRF”。SEED-CTR PRF以类似的方式定义，但每次调用AES都被调用SEED替换。
The currently defined PRF, keyed by the 128-bit master key, has input block size m = 128 and can produce n-bit outputs for n up to 2^23. SEED-PRF_n(k_master, x) SHALL be SEED in counter mode, as described in Section 2.1; it SHALL be applied to key k_master, have IV equal to (x*2^16), and have the output keystream truncated to the first n (leftmost) bits.
当前定义的PRF由128位主密钥设置密钥，其输入块大小为m=128，可以为n到2^23生成n位输出。SEED-PRF_n（k_master，x）应为计数器模式下的SEED，如第2.1节所述；它应应用于密钥k_master，IV等于（x*2^16），并将输出密钥流截断为前n（最左边）位。
"Mandatory-to-implement" means conformance to this specification, and that Table 1 in this document does not supercede a similar table in Section 5 of [RFC3711]. An RTP implementation that supports SEED MUST implement the modes listed in Table 1 of this document.
“强制实施”指符合本规范，且本文件中的表1不取代[RFC3711]第5节中的类似表。支持SEED的RTP实现必须实现本文档表1中列出的模式。
mandatory-to-implement optional
强制执行可选项
encryption SEED-CTR SEED-CCM,SEED-GCM message integrity HMAC-SHA1 SEED-CCM,SEED-GCM key derivation (PRF) SEED-CTR -
加密SEED-CTR SEED-CCM，SEED-GCM消息完整性HMAC-SHA1 SEED-CCM，SEED-GCM密钥派生（PRF）SEED-CTR-
Table 1: Mandatory-to-implement and optional transforms in SRTP and SRTCP
表1：在SRTP和SRTCP中实现强制转换和可选转换
No security problem has been found on SEED. SEED is secure against all known attacks, including differential cryptanalysis, linear cryptanalysis, and related key attacks. The best known attack is only an exhaustive search for the key. For further security considerations, the reader is encouraged to read [SEED-EVAL].
在SEED上未发现任何安全问题。SEED对所有已知的攻击都是安全的，包括差分密码分析、线性密码分析和相关的密钥攻击。最著名的攻击只是对密钥的彻底搜索。出于进一步的安全考虑，鼓励读者阅读[SEED-EVAL]。
See [RFC3610] and [GCM] for security considerations regarding the CCM and GCM Modes of Operation, respectively. In the context of SRTP, the procedures in [RFC3711] ensure the critical property of non-reuse of counter values.
有关CCM和GCM操作模式的安全注意事项，请分别参见[RFC3610]和[GCM]。在SRTP的上下文中，[RFC3711]中的程序确保计数器值的不重用这一关键属性。
[RFC4568] defines SRTP "crypto suites". In order to allow the Session Description Protocol (SDP) to signal the use of the algorithms defined in this document, IANA has registered the following crypto suites into the subregistry for SRTP crypto suites under the Media Stream Transports of the SDP Security Descriptions:
[RFC4568]定义了SRTP“加密套件”。为了允许会话描述协议（SDP）发出使用本文件中定义的算法的信号，IANA已将以下加密套件注册到SDP安全描述的媒体流传输下的SRTP加密套件子区：
SEED_CTR_128_HMAC_SHA1_80 SEED_128_CCM_80 SEED_128_GCM_96
种子中心128 HMAC SHA1 80种子中心128 CCM 80种子中心128 GCM 96
The authors would like to thank David McGrew, Eric Rescorla, Alexey Melnikov, Alfred Hoenes, Colin Perkins, Young-Chan Shin, the AVT WG (in particular, the chairmen Roni Even and Tom Taylor), and the Real-time Applications and Infrastructure Area Directors for their reviews and support.
作者要感谢David McGrew、Eric Rescorla、Alexey Melnikov、Alfred Hoenes、Colin Perkins、Young Chan Shin、AVT工作组（特别是Roni Even和Tom Taylor主席）以及实时应用和基础设施领域总监的审查和支持。
[GCM] Dworkin, M., "NIST Special Publication 800-38D:
Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC", U.S. National
Institute of Standards and Technology,
http://csrc.nist.gov/publications/nistpubs/800-38D/
SP-800-38D.pdf
[GCM] Dworkin, M., "NIST Special Publication 800-38D:
Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC", U.S. National
Institute of Standards and Technology,
http://csrc.nist.gov/publications/nistpubs/800-38D/
SP-800-38D.pdf
[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月。
[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月。
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, September 2003.
[RFC3610]Whiting，D.，Housley，R.，和N.Ferguson，“CBC-MAC（CCM）计数器”，RFC 36102003年9月。
[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月。
[RFC4269] Lee, H., Lee, S., Yoon, J., Cheon, D., and J. Lee, "The SEED Encryption Algorithm", RFC 4269, December 2005.
[RFC4269]Lee，H.，Lee，S.，Yoon，J.，Cheon，D.，和J.Lee，“种子加密算法”，RFC 4269，2005年12月。
[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月。
[TTASSEED] Telecommunications Technology Association (TTA), South Korea, "128-bit Symmetric Block Cipher (SEED)", TTAS.KO-12.0004/R1, December 2005, (In Korean) http://www.tta.or.kr/English/index.jsp.
[TTASSEED]韩国电信技术协会（TTA），“128位对称分组密码（SEED）”，TTAS.KO-12.0004/R1，2005年12月，（韩文）http://www.tta.or.kr/English/index.jsp.
[SEED-EVAL] KISA, "Self Evaluation Report",
http://seed.kisa.or.kr/eng/main.jsp
[SEED-EVAL] KISA, "Self Evaluation Report",
http://seed.kisa.or.kr/eng/main.jsp
All values are in hexadecimal.
所有值均为十六进制。
Session Key: 0c5ffd37a11edc42c325287fc0604f2e
Session Key: 0c5ffd37a11edc42c325287fc0604f2e
Rollover Counter: 00000000
滚动计数器：00000000
Sequence Number: 315e
序号：315e
SSRC: 20e8f5eb
SSRC:20e8f5eb
Authentication Key: f93563311b354748c978913795530631
Authentication Key: f93563311b354748c978913795530631
Session Salt: cd3a7c42c671e0067a2a2639b43a
会议记录：CD3A7C42C671E0067A2639B43A
Initialization Vector: cd3a7c42e69915ed7a2a263985640000
Initialization Vector: cd3a7c42e69915ed7a2a263985640000
RTP Payload: f57af5fd4ae19562976ec57a5a7ad55a
5af5c5e5c5fdf5c55ad57a4a7272d572
62e9729566ed66e97ac54a4a5a7ad5e1
5ae5fdd5fd5ac5d56ae56ad5c572d54a
e54ac55a956afd6aed5a4ac562957a95
16991691d572fd14e97ae962ed7a9f4a
955af572e162f57a956666e17ae1f54a
95f566d54a66e16e4afd6a9f7ae1c5c5
5ae5d56afde916c5e94a6ec56695e14a
fde1148416e94ad57ac5146ed59d1cc5
RTP Payload: f57af5fd4ae19562976ec57a5a7ad55a
5af5c5e5c5fdf5c55ad57a4a7272d572
62e9729566ed66e97ac54a4a5a7ad5e1
5ae5fdd5fd5ac5d56ae56ad5c572d54a
e54ac55a956afd6aed5a4ac562957a95
16991691d572fd14e97ae962ed7a9f4a
955af572e162f57a956666e17ae1f54a
95f566d54a66e16e4afd6a9f7ae1c5c5
5ae5d56afde916c5e94a6ec56695e14a
fde1148416e94ad57ac5146ed59d1cc5
Encrypted RTP Payload: df5a89291e7e383e9beff765e691a737
49c9e33139ad3001cd8da73ad07f69a2
805a70358b5c7c8c60ed359f95cf5e08
f713c53ff7b808250d79a19ccb8d1073
4e3cb72ed1f0a4e85b002b248049ab07
63dbe571bec52cf9153fdf2019e421ef
779cd6f4bd1c8211da8c272e2fce4393
4b9eabb87362510f254149f992599036
f5e43102327db1ac5e78adc4f66546ed
7abfb5a4db320fb7b9c52a61bc554e44
Encrypted RTP Payload: df5a89291e7e383e9beff765e691a737
49c9e33139ad3001cd8da73ad07f69a2
805a70358b5c7c8c60ed359f95cf5e08
f713c53ff7b808250d79a19ccb8d1073
4e3cb72ed1f0a4e85b002b248049ab07
63dbe571bec52cf9153fdf2019e421ef
779cd6f4bd1c8211da8c272e2fce4393
4b9eabb87362510f254149f992599036
f5e43102327db1ac5e78adc4f66546ed
7abfb5a4db320fb7b9c52a61bc554e44
Authentication Tag: a5cdaa4d9edc53763855
认证标签：a5cdaa4d9edc53763855
Key: 974bee725d44fc3992267b284c3c6750
Key: 974bee725d44fc3992267b284c3c6750
Rollover Counter: 00000000
滚动计数器：00000000
Sequence Number: 315e
序号：315e
SSRC: 20e8f5eb
SSRC:20e8f5eb
Nonce: 000020e8f5eb00000000315e
暂时代码：000020e8f5eb00000000315e
Payload: f57af5fd4ae19562976ec57a5a7ad55a
5af5c5e5c5fdf5c55ad57a4a7272d572
62e9729566ed66e97ac54a4a5a7ad5e1
5ae5fdd5fd5ac5d56ae56ad5c572d54a
e54ac55a956afd6aed5a4ac562957a95
16991691d572fd14e97ae962ed7a9f4a
955af572e162f57a956666e17ae1f54a
95f566d54a66e16e4afd6a9f7ae1c5c5
5ae5d56afde916c5e94a6ec56695e14a
fde1148416e94ad57ac5146ed59d1cc5
Payload: f57af5fd4ae19562976ec57a5a7ad55a
5af5c5e5c5fdf5c55ad57a4a7272d572
62e9729566ed66e97ac54a4a5a7ad5e1
5ae5fdd5fd5ac5d56ae56ad5c572d54a
e54ac55a956afd6aed5a4ac562957a95
16991691d572fd14e97ae962ed7a9f4a
955af572e162f57a956666e17ae1f54a
95f566d54a66e16e4afd6a9f7ae1c5c5
5ae5d56afde916c5e94a6ec56695e14a
fde1148416e94ad57ac5146ed59d1cc5
AAD: 8008315ebf2e6fe020e8f5eb
AAD:8008315ebf2e6fe020e8f5eb
Encrypted RTP Payload: 486843a881df215a8574650ddabf5dbb
2650f06f51252bccaeb4012899d6d71e
30c64dad5ead5d8ba65ffe9d79aaf30d
c9e6334490c07e7533d704114a9006ec
b3b3bff59ecf585485bc0bd286ed434c
fd684d19a1ad514ca5f37b71d93288c0
7cf4d5e9b83db8becc8c692a7279b6a9
ac62ba970fc54f46dcc926d434c0b5ad
8678fbf0e7a03037924dae342ef64fa6
5b8eaea260fecb477a57e3919c5dab82
Encrypted RTP Payload: 486843a881df215a8574650ddabf5dbb
2650f06f51252bccaeb4012899d6d71e
30c64dad5ead5d8ba65ffe9d79aaf30d
c9e6334490c07e7533d704114a9006ec
b3b3bff59ecf585485bc0bd286ed434c
fd684d19a1ad514ca5f37b71d93288c0
7cf4d5e9b83db8becc8c692a7279b6a9
ac62ba970fc54f46dcc926d434c0b5ad
8678fbf0e7a03037924dae342ef64fa6
5b8eaea260fecb477a57e3919c5dab82
Authentication Tag: b0a8274cf6a8bb6cc466
认证标签：b0a8274cf6a8bb6cc466
Key: e91e5e75da65554a48181f3846349562
Key: e91e5e75da65554a48181f3846349562
Rollover Counter: 00000000
滚动计数器：00000000
Sequence Number: 315e
序号：315e
SSRC: 20e8f5eb
SSRC:20e8f5eb
Nonce: 000020e8f5eb00000000315e
暂时代码：000020e8f5eb00000000315e
Payload: f57af5fd4ae19562976ec57a5a7ad55a
5af5c5e5c5fdf5c55ad57a4a7272d572
62e9729566ed66e97ac54a4a5a7ad5e1
5ae5fdd5fd5ac5d56ae56ad5c572d54a
e54ac55a956afd6aed5a4ac562957a95
16991691d572fd14e97ae962ed7a9f4a
955af572e162f57a956666e17ae1f54a
95f566d54a66e16e4afd6a9f7ae1c5c5
5ae5d56afde916c5e94a6ec56695e14a
fde1148416e94ad57ac5146ed59d1cc5
Payload: f57af5fd4ae19562976ec57a5a7ad55a
5af5c5e5c5fdf5c55ad57a4a7272d572
62e9729566ed66e97ac54a4a5a7ad5e1
5ae5fdd5fd5ac5d56ae56ad5c572d54a
e54ac55a956afd6aed5a4ac562957a95
16991691d572fd14e97ae962ed7a9f4a
955af572e162f57a956666e17ae1f54a
95f566d54a66e16e4afd6a9f7ae1c5c5
5ae5d56afde916c5e94a6ec56695e14a
fde1148416e94ad57ac5146ed59d1cc5
AAD: 8008315ebf2e6fe020e8f5eb
AAD:8008315ebf2e6fe020e8f5eb
Encrypted RTP Payload: 8a5363682c6b1bbf13c0b09cf747a551
2543cb2f129b8bd0e92dfadf735cda8f
88c4bbf90288f5e58d20c4f1bb0d5844
6ea009103ee57ba99cdeabaaa18d4a9a
05ddb46e7e5290a5a2284fe50b1f6fe9
ad3f1348c354181e85b24f1a552a1193
cf0e13eed5ab95ae854fb4f5b0edb2d3
ee5eb238c8f4bfb136b2eb6cd7876042
0680ce1879100014f140a15e07e70133
ed9cbb6d57b75d574acb0087eefbac99
Encrypted RTP Payload: 8a5363682c6b1bbf13c0b09cf747a551
2543cb2f129b8bd0e92dfadf735cda8f
88c4bbf90288f5e58d20c4f1bb0d5844
6ea009103ee57ba99cdeabaaa18d4a9a
05ddb46e7e5290a5a2284fe50b1f6fe9
ad3f1348c354181e85b24f1a552a1193
cf0e13eed5ab95ae854fb4f5b0edb2d3
ee5eb238c8f4bfb136b2eb6cd7876042
0680ce1879100014f140a15e07e70133
ed9cbb6d57b75d574acb0087eefbac99
Authentication Tag: 36cd9ae602be3ee2cd8d5d9d
认证标签：36cd9ae602be3ee2cd8d5d9d
Authors' Addresses
作者地址
Seokung Yoon Korea Internet & Security Agency IT Venture Tower, Jungdaero 135 Songpa-gu, Seoul, Korea 138-950 EMail: seokung@kisa.or.kr
Seokung Yoon韩国互联网与安全机构IT风险投资大厦，韩国首尔松巴谷正大罗135号138-950电子邮件：seokung@kisa.or.kr
Joongman Kim Korea Internet & Security Agency IT Venture Tower, Jungdaero 135 Songpa-gu, Seoul, Korea 138-950 EMail: seopo@kisa.or.kr
韩国首尔松巴谷正大罗135号韩国互联网与安全局IT创业大厦Joongman Kim 138-950电子邮件：seopo@kisa.or.kr
Haeryong Park Korea Internet & Security Agency IT Venture Tower, Jungdaero 135 Songpa-gu, Seoul, Korea 138-950 EMail: hrpark@kisa.or.kr
韩国首尔松巴谷正大罗135号韩国互联网与安全局IT创业大厦海隆公园138-950电子邮件：hrpark@kisa.or.kr
Hyuncheol Jeong Korea Internet & Security Agency IT Venture Tower, Jungdaero 135 Songpa-gu, Seoul, Korea 138-950 EMail: hcjung@kisa.or.kr
韩国首尔松巴谷正大罗135号韩国互联网与安全局IT创业大厦Hyunchel Jeong 138-950电子邮件：hcjung@kisa.or.kr
Yoojae Won Korea Internet & Security Agency IT Venture Tower, Jungdaero 135 Songpa-gu, Seoul, Korea 138-950 EMail: yjwon@kisa.or.kr
Yoojae-Won韩国互联网和安全机构IT风险投资大厦，韩国首尔松巴谷正大罗135号138-950电子邮件：yjwon@kisa.or.kr