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)
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).
この文書では、リアルタイムトランスポート制御プロトコルをリアルタイムトランスポートプロトコル（RTP）トラフィック用およびRTPのための制御トラフィックの機密性を提供するためのセキュアなリアルタイム転送プロトコル（SRTP）でSEEDのブロック暗号アルゴリズムの使用を記載します（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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さ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
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].
この文書では、SEED [RFC4269]の使用はリアルタイムトランスポートプロトコル（RTP）[RFC3550]トラフィックのためにとのための制御トラフィックの機密性を提供するためのセキュアなリアルタイム転送プロトコル（SRTP）[RFC3711]での暗号アルゴリズムをブロック説明します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）とSEEDの入力/出力ブロックサイズは128ビットで、キーの長さはまた、128ビットである1998年に始まる専門家のグループによって開発された対称暗号化アルゴリズムです。 SEEDは16段のFeistel構造を有しています。 128ビット入力は、2つの64ビットのブロックに分割され、右64ビットのブロックは、鍵スケジュールから生成される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]に記載されています。 SEEDのホームページ、http://seed.kisa.or.kr/eng/main.jspは、これに関する詳細な仕様など、SEED、評価報告書、テストベクトル、との情報が豊富に含まれています。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
|| concatenation XOR exclusive or
||連結XOR排他的論理和
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の関連する特性の説明が含まれています。
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）SEED、CBC-MAC（CCM）とカウンタ・モード（2）SEED、及び（3）SEED /カウンタ・モード（GCM）：我々は、実行中の種子の3つのモードが定義します。
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-CMともいうAESカウンタモードの暗号化を定義します。 SEEDカウンタモードは、同様に定義され、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].
HMAC-SHA1 [RFC2104]は、[RFC3711]のセクション4.2.1で定義されるように、SEED-CTRで使用するデフォルトのメッセージ認証コードでなければなりません。デフォルトセッション認証キーの長さは、デフォルトの認証タグの長さは80ビットでなければならない、とSRTP_PREFIX_LENGTHはHMAC-SHA1はゼロでなければならない、160ビットでなければなりません。 SRTPのために、より小さな値が推奨されないが、セクション7.5と[RFC3711]の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）パケットの暗号化はオプションです（ただし、認証は必須です）。送信者は、暗号化するパケットと（SRTCPインデックスが含まれている32ビット・ワードの左端のビットにある）1ビットの暗号化フラグを使用してこの選択を指示する選択することができます。
SEED-CCM has two parameters:
SEED-CCMは、2つのパラメータがあります。
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 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のLはオクテットの長さフィールドのサイズを示します。ナンスのオクテットの数が12、すなわちなければなりません、Lは3です。
SEED-CCM has four inputs:
SEED-CCMは、4つの入力があります。
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.
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.
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.
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.
暗号化フラグが1にセットされたときSRTCPの場合には、[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.
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.
暗号化フラグが0に設定されている場合SRTCPの場合には、[RFC3711]の図2で説明した認証部は、AADとして扱われます。暗号化フラグが1にセットされたとき、最初の8つのオクテット、暗号化フラグ、およびSRTCPインデックスはAADとして扱われます。
SEED-CCM accepts these four inputs and returns a ciphertext field.
SEED-CCMは、これらの4つの入力を受け入れ、暗号文のフィールドを返します。
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.
鍵、平文、ノンス、および追加の認証データ（AAD）、2.2節に記述されているすべての：SEED-GCMは、4つの入力を有します。
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 = (16 bits of zeroes || SSRC || ROC || SEQ) XOR Salt
ノンス=（SSRC || ROC || SEQ ||ゼロの16ビット）XORソルト
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オクテットの配列は、RTPヘッダから講じなければなりません。 4オクテットROCは暗号の文脈からです。 12オクテット塩はSRTP鍵導出関数によって製造されなければなりません。
The nonce for SRTCP SHALL be formed in the following way:
SRTCPのためのナンスは、次のようにして形成されなければなりません。
Nonce = (16 bits of zeroes || SSRC || 16 bits of zeroes || SRTCP index) XOR Salt
ノンス=（ゼロの16ビットゼロの|| || SSRC 16ビット|| SRTCPインデックス）XORソルト
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ヘッダから取られるものとし（ゼロ充填及び右寄せ4オクテットフィールドにパック）31ビットSRTCPインデックスは、各パケットからのものです。 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-CM PRF」ともいうAES-128カウンタモードキー導出関数を定義します。 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.
128ビットのマスターキーをキーと現在定義されているPRFは、入力ブロックサイズm = 128を有しており、2 ^ 23までのnに対してnビット出力を生成することができます。 SEED-PRF_n（k_master、x）のセクション2.1に記載したように、カウンタモードでSEEDなければなりません。それはキーk_masterに適用しなければならない、（X * 2 ^ 16）にIVが等しい有し、出力キーストリームは、最初の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
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.
著者はデイヴィッドマグリュー、エリックレスコラ、アレクセイ・メルニコフ、アルフレッドHoenes、コリンパーキンス、ヤング・チャン新、AVT WG（特に、議長ロニでも、トム・テイラー）、およびリアルタイムアプリケーションとインフラストラクチャを感謝したいと思います彼らのレビューと支援のためのエリアディレクター。
[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：オペレーションのブロック暗号モードのための推奨事項：ガロア/カウンタモード（GCM）とGMAC"、米国立標準技術研究所は、http：//csrc.nist .GOV /出版/ 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.、ベラー、M.、およびR.カネッティ、 "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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, September 2003.
[RFC3610]ホワイティング、D.、Housley氏、R.、およびN.ファーガソン、 "CBC-MAC（CCM）とカウンター"、RFC 3610、2003年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.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[RFC4269] Lee, H., Lee, S., Yoon, J., Cheon, D., and J. Lee, "The SEED Encryption Algorithm", RFC 4269, December 2005.
[RFC4269]リー、H.、リー、S.、ユン、J.、チョン、D.、およびJ.リー、 "SEED暗号化アルゴリズム"、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]アンドレア、F.、Baugher、M.、およびD.翼、 "メディア・ストリームのセッション記述プロトコル（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 /英語/ index.jspを。
[SEED-EVAL] KISA, "Self Evaluation Report", http://seed.kisa.or.kr/eng/main.jsp
[SEED-EVAL] KISA、 "自己評価報告書"、http://seed.kisa.or.kr/eng/main.jsp
Appendix A. Test Vectors
付録A.テストベクトル
All values are in hexadecimal.
すべての値は16進数です。
A.1. SEED-CTR Test Vectors
A.1。 SEED-CTRテストベクトル
Session Key: 0c5ffd37a11edc42c325287fc0604f2e
セッションキー：0c5ffd37a11edc42c325287fc0604f2e
Rollover Counter: 00000000
ロールオーバーカウンター：00000000
Sequence Number: 315e
シーケンス番号：315E
SSRC: 20e8f5eb
SSRC：20e8f5eb
Authentication Key: f93563311b354748c978913795530631
認証キー：f93563311b354748c978913795530631
Session Salt: cd3a7c42c671e0067a2a2639b43a
セッション塩：cd3a7c42c671e0067a2a2639b43a
Initialization Vector: cd3a7c42e69915ed7a2a263985640000
初期ベクトル：cd3a7c42e69915ed7a2a263985640000
RTP Payload: f57af5fd4ae19562976ec57a5a7ad55a 5af5c5e5c5fdf5c55ad57a4a7272d572 62e9729566ed66e97ac54a4a5a7ad5e1 5ae5fdd5fd5ac5d56ae56ad5c572d54a e54ac55a956afd6aed5a4ac562957a95 16991691d572fd14e97ae962ed7a9f4a 955af572e162f57a956666e17ae1f54a 95f566d54a66e16e4afd6a9f7ae1c5c5 5ae5d56afde916c5e94a6ec56695e14a fde1148416e94ad57ac5146ed59d1cc5
RTPペイロード：f57af5fd4ae19562976ec57a5a7ad55a 5af5c5e5c5fdf5c55ad57a4a7272d572 62e9729566ed66e97ac54a4a5a7ad5e1 5ae5fdd5fd5ac5d56ae56ad5c572d54a e54ac55a956afd6aed5a4ac562957a95 16991691d572fd14e97ae962ed7a9f4a 955af572e162f57a956666e17ae1f54a 95f566d54a66e16e4afd6a9f7ae1c5c5 5ae5d56afde916c5e94a6ec56695e14a fde1148416e94ad57ac5146ed59d1cc5
Encrypted RTP Payload: df5a89291e7e383e9beff765e691a737 49c9e33139ad3001cd8da73ad07f69a2 805a70358b5c7c8c60ed359f95cf5e08 f713c53ff7b808250d79a19ccb8d1073 4e3cb72ed1f0a4e85b002b248049ab07 63dbe571bec52cf9153fdf2019e421ef 779cd6f4bd1c8211da8c272e2fce4393 4b9eabb87362510f254149f992599036 f5e43102327db1ac5e78adc4f66546ed 7abfb5a4db320fb7b9c52a61bc554e44
暗号化されたRTPペイロード：df5a89291e7e383e9beff765e691a737 49c9e33139ad3001cd8da73ad07f69a2 805a70358b5c7c8c60ed359f95cf5e08 f713c53ff7b808250d79a19ccb8d1073 4e3cb72ed1f0a4e85b002b248049ab07 63dbe571bec52cf9153fdf2019e421ef 779cd6f4bd1c8211da8c272e2fce4393 4b9eabb87362510f254149f992599036 f5e43102327db1ac5e78adc4f66546ed 7abfb5a4db320fb7b9c52a61bc554e44
Authentication Tag: a5cdaa4d9edc53763855
認証タグ：a5cdaa4d9edc53763855
A.2. SEED-CCM Test Vectors
A.2。 SEED-CCMテストベクトル
Key: 974bee725d44fc3992267b284c3c6750
キー：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
ペイロード：f57af5fd4ae19562976ec57a5a7ad55a 5af5c5e5c5fdf5c55ad57a4a7272d572 62e9729566ed66e97ac54a4a5a7ad5e1 5ae5fdd5fd5ac5d56ae56ad5c572d54a e54ac55a956afd6aed5a4ac562957a95 16991691d572fd14e97ae962ed7a9f4a 955af572e162f57a956666e17ae1f54a 95f566d54a66e16e4afd6a9f7ae1c5c5 5ae5d56afde916c5e94a6ec56695e14a fde1148416e94ad57ac5146ed59d1cc5
AAD: 8008315ebf2e6fe020e8f5eb
YOU：8008315ebf2e6fe020e8f5eb
Encrypted RTP Payload: 486843a881df215a8574650ddabf5dbb 2650f06f51252bccaeb4012899d6d71e 30c64dad5ead5d8ba65ffe9d79aaf30d c9e6334490c07e7533d704114a9006ec b3b3bff59ecf585485bc0bd286ed434c fd684d19a1ad514ca5f37b71d93288c0 7cf4d5e9b83db8becc8c692a7279b6a9 ac62ba970fc54f46dcc926d434c0b5ad 8678fbf0e7a03037924dae342ef64fa6 5b8eaea260fecb477a57e3919c5dab82
暗号化されたRTPペイロード：486843a881df215a8574650ddabf5dbb 2650f06f51252bccaeb4012899d6d71e 30c64dad5ead5d8ba65ffe9d79aaf30d c9e6334490c07e7533d704114a9006ec b3b3bff59ecf585485bc0bd286ed434c fd684d19a1ad514ca5f37b71d93288c0 7cf4d5e9b83db8becc8c692a7279b6a9 ac62ba970fc54f46dcc926d434c0b5ad 8678fbf0e7a03037924dae342ef64fa6 5b8eaea260fecb477a57e3919c5dab82
Authentication Tag: b0a8274cf6a8bb6cc466
認証タグ：b0a8274cf6a8bb6cc466
A.3. SEED-GCM Test Vectors
A.3。 SEED-GCMテストベクトル
Key: e91e5e75da65554a48181f3846349562
キー：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
ペイロード：f57af5fd4ae19562976ec57a5a7ad55a 5af5c5e5c5fdf5c55ad57a4a7272d572 62e9729566ed66e97ac54a4a5a7ad5e1 5ae5fdd5fd5ac5d56ae56ad5c572d54a e54ac55a956afd6aed5a4ac562957a95 16991691d572fd14e97ae962ed7a9f4a 955af572e162f57a956666e17ae1f54a 95f566d54a66e16e4afd6a9f7ae1c5c5 5ae5d56afde916c5e94a6ec56695e14a fde1148416e94ad57ac5146ed59d1cc5
AAD: 8008315ebf2e6fe020e8f5eb
YOU：8008315ebf2e6fe020e8f5eb
Encrypted RTP Payload: 8a5363682c6b1bbf13c0b09cf747a551 2543cb2f129b8bd0e92dfadf735cda8f 88c4bbf90288f5e58d20c4f1bb0d5844 6ea009103ee57ba99cdeabaaa18d4a9a 05ddb46e7e5290a5a2284fe50b1f6fe9 ad3f1348c354181e85b24f1a552a1193 cf0e13eed5ab95ae854fb4f5b0edb2d3 ee5eb238c8f4bfb136b2eb6cd7876042 0680ce1879100014f140a15e07e70133 ed9cbb6d57b75d574acb0087eefbac99
暗号化されたRTPペイロード：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ユン・韓国インターネット振興院ITベンチャータワー、Jungdaero 135市松坡区ソウル、韓国138から950 Eメール：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
Joongmanキム・韓国インターネット振興院ITベンチャータワー、Jungdaero 135市松坡区ソウル、韓国138から950 Eメール：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
Haeryongパーク韓国インターネット振興院ITベンチャータワー、Jungdaero 135市松坡区ソウル、韓国138から950 Eメール：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
Hyuncheolチョン韓国インターネット振興院ITベンチャータワー、Jungdaero 135市松坡区ソウル、韓国138から950 Eメール：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ウォン韓国インターネット振興院ITベンチャータワー、Jungdaero 135市松坡区ソウル、韓国138から950 Eメール：yjwon@kisa.or.kr