RFC4196 日本語訳

4196 The SEED Cipher Algorithm and Its Use with IPsec. H.J. Lee, J.H.Yoon, S.L. Lee, J.I. Lee. October 2005. (Format: TXT=22587 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                           H.J. Lee
Request for Comments: 4196                                     J.H. Yoon
Category: Standards Track                                       S.L. Lee
                                                                J.I. Lee
                                                                    KISA
                                                            October 2005

コメントを求めるワーキンググループH.J.リーの要求をネットワークでつないでください: 4196年のJ.H.チョカテゴリ: 標準化過程S.L.リーJ.I.リー吉舎2005年10月

            The SEED Cipher Algorithm and Its Use with IPsec

種子暗号アルゴリズムとIPsecとのその使用

Status of This Memo

このメモの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(2005)。

Abstract

要約

   This document describes the use of the SEED block cipher algorithm in
   the Cipher Block Chaining Mode, with an explicit IV, as a
   confidentiality mechanism within the context of the IPsec
   Encapsulating Security Payload (ESP).

このドキュメントはCipher Block Chaining ModeにおけるSEEDブロック暗号アルゴリズムの使用について説明します、明白なIVと共に、IPsec Encapsulating Security有効搭載量(超能力)の文脈の中の秘密性メカニズムとして。

1.  Introduction

1. 序論

1.1.  SEED

1.1. 種子

   SEED is a national industrial association standard [TTASSEED] and is
   widely used in South Korea for electronic commerce and financial
   services that are operated on wired and wireless communications.

SEEDは国家の産業組合規格[TTASSEED]であり、ワイヤードで無線のコミュニケーションで操作される電子商取引と金融サービスに韓国で広く使用されます。

   SEED is a 128-bit symmetric key block cipher that has been developed
   by KISA (Korea Information Security Agency) and a group of experts
   since 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 that
   is generated from the key scheduling.

SEEDは1998年以来吉舎(韓国情報Security Agency)と専門家のグループによって開発されている128ビットの対称鍵ブロック暗号です。 SEEDの入力/出力ブロック・サイズは128ビットです、そして、また、キー長は128ビットです。 SEEDには、ラウンドの16Feistel構造があります。 128ビットの入力は2つの64ビットのブロックに分割されます、そして、正しい64噛み付いているブロックは主要なスケジューリングから発生する64ビットのサブキーがある丸い機能への入力です。

   SEED is easily implemented in various software and hardware, and it
   can be effectively adopted to a computing environment with restricted
   resources, such as mobile devices and smart cards.

様々なソフトウェアとハードウェアで容易にSEEDを実行します、そして、事実上、制限されたリソースでコンピューティング環境にそれを採用できます、モバイル機器やスマートカードのように。

Lee, et al.                 Standards Track                     [Page 1]

RFC 4196               The Use of SEED with IPsec           October 2005

リー、他 規格は2005年10月にIPsecとの種子のRFC4196使用を追跡します[1ページ]。

   SEED is robust against known attacks including DC (Differential
   cryptanalysis), LC (Linear cryptanalysis), and related key attacks.
   SEED has gone through wide public scrutinizing procedures.  It has
   been evaluated and is considered cryptographically secure by credible
   organizations such as ISO/IEC JTC 1/SC 27 and Japan CRYPTREC
   (Cryptography Research and Evaluation Committees)[ISOSEED][CRYPTREC].

SEEDはDC(差分解読法)、LC(線形解読法)、および関連する主要な攻撃を含む知られている攻撃に対して強健です。 SEEDは手順を精査する広い公衆を通りました。 それは、ISO/IEC JTC1/サウスカロライナ27や日本CRYPTREC(暗号ResearchとEvaluation Committees)[ISOSEED][CRYPTREC]などの信用ある組織によって評価されて、安全であると暗号で考えられます。

   The remainder of this document specifies the use of SEED within the
   context of IPsec ESP.  For further information on how the various
   pieces of ESP fit together to provide security services, please refer
   to [ARCH], [ESP], and [ROAD].

このドキュメントの残りはIPsecの文脈の中でSEEDの使用を指定します。超能力。 超能力の様々な断片がセキュリティー・サービスを提供するためにどう一緒に合うかに関する詳細について、[ARCH]、[超能力]、および[ROAD]を参照してください。

1.2.  Terminology

1.2. 用語

   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
   "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase,
   as shown) are to be interpreted as described in RFC 2119 [KEYWORDS].

キーワード“MUST"、「必須NOT」が「必要です」、“SHOULD"、「「推薦され」て、このドキュメント(中で大文字してください、示されるように)で「5月」の、そして、「任意」のNOTはRFC2119[キーワード]で説明されるように解釈されることであるべきですか?

2.  The SEED Cipher Algorithm

2. 種子暗号アルゴリズム

   All symmetric block cipher algorithms share common characteristics
   and variables, including mode, key size, weak keys, block size, and
   rounds.  The following sections contain descriptions of the relevant
   characteristics of SEED.

すべての左右対称のブロック暗号アルゴリズムがモード、主要なサイズ、弱いキー、ブロック・サイズ、およびラウンドを含む共通する特徴と変数を共有します。 以下のセクションはSEEDの関連特性の記述を含みます。

   The algorithm specification and object identifiers are described in
   [ISOSEED] [SEED].  The SEED homepage,
   http://www.kisa.or.kr/seed/seed_eng.html, contains a wealth of
   information about SEED, including a detailed specification,
   evaluation report, test vectors, and so on.

アルゴリズム仕様と物の識別子は[ISOSEED][SEED]で説明されます。 SEEDホームページ( http://www.kisa.or.kr/seed/seed_eng.html )はSEEDの豊富な情報を含んでいます、仕様詳細、評価報告書、テストベクトルなどを含んでいて。

2.1.  Mode

2.1. モード

   NIST has defined 5 modes of operation for the Advanced Encryption
   Standard (AES) [AES] and other FIPS-approved ciphers [MODES]: CBC
   (Cipher Block Chaining), ECB (Electronic Codebook), CFB (Cipher
   FeedBack), OFB (Output FeedBack), and CTR (Counter).  The CBC mode is
   well-defined and well-understood for symmetric ciphers, and is
   currently required for all other ESP ciphers.  This document
   specifies the use of the SEED cipher in the CBC mode within ESP.
   This mode requires an Initialization Vector (IV) that is the same
   size as the block size.  Use of a randomly generated IV prevents
   generation of identical ciphertext from packets that have identical
   data that spans the first block of the cipher algorithm's block size

NISTはエー・イー・エス(AES)[AES]と他のFIPSによって承認された暗号[MODES]のために5つの運転モードを定義しました: CBC(暗号ブロック連鎖)、ECB(電子符号表)、CFB(暗号フィードバック)、OFB(出力フィードバック)、およびCTR(カウンタ)。 CBCモードが、明確であり、左右対称の暗号のためによく分かって、現在、他のすべての超能力暗号に必要です。 このドキュメントは超能力の中でCBCモードにおけるSEED暗号の使用を指定します。 このモードはブロック・サイズと同じサイズである初期設定Vector(IV)を必要とします。 手当たりしだいに発生しているIVの使用は暗号アルゴリズムのブロック・サイズの最初のブロックを測る同じデータを持っているパケットから同じ暗号文の世代を防ぎます。

   The IV is XOR'd with the first plaintext block before it is
   encrypted.  Then for successive blocks, the previous ciphertext block
   is XOR'd with the current plaintext before it is encrypted.

IVによるXORがそれの前の最初の平文ブロックでコード化されたということです。 そして、連続したブロックに関して、前の暗号文ブロックはXORがそれの前の現在の平文でコード化されたということです。

Lee, et al.                 Standards Track                     [Page 2]

RFC 4196               The Use of SEED with IPsec           October 2005

リー、他 規格は2005年10月にIPsecとの種子のRFC4196使用を追跡します[2ページ]。

   More information on the CBC mode can be obtained in [MODES]
   [CRYPTO-S].  For use of the CBC mode in ESP with 64-bit ciphers,
   please see [CBC].

[MODES][CRYPTO-S]でCBCモードに関する詳しい情報を得ることができます。 64ビットの暗号がある超能力におけるCBCモードの使用に関しては、[CBC]を見てください。

2.2.  Key Size and Numbers of Rounds

2.2. 主要なサイズと数のラウンド

   SEED supports 128-bit key and has the 16-round Feistel structure.

SEEDは128ビットのキーを支えて、ラウンドの16Feistel構造を持っています。

2.3.  Weak Keys

2.3. 弱いキー

   At the time this document was written, there were no known weak keys
   for SEED.

このドキュメントが書かれたとき、SEEDに、弱いキーは知られていませんでした。

2.4.  Block Size and Padding

2.4. ブロック・サイズと詰め物

   SEED uses a block size of 16 octets (128 bits).

SEEDは16の八重奏(128ビット)のブロック・サイズを使用します。

   Padding is required by SEED to maintain a 16-octet (128-bit)
   blocksize.  Padding MUST be added, as specified in [ESP], such that
   the data to be encrypted (which includes the ESP Pad Length and Next
   Header fields) has a length that is a multiple of 16 octets.

詰め物は、16八重奏(128ビット)がblocksizeされると主張するためにSEEDによって必要とされます。 詰め物を加えなければなりません、[超能力]で指定されるように、コード化されるべきデータ(超能力Pad LengthとNext Header分野を含んでいる)には16の八重奏の倍数である長さがあるように。

   Because of the algorithm specific padding requirement, no additional
   padding is required to ensure that the ciphertext terminates on a 4-
   octet boundary (i.e., maintaining a 16-octet blocksize guarantees
   that the ESP Pad Length and Next Header fields will be right aligned
   within a 4-octet word).  Additional padding MAY be included, as
   specified in [ESP], as long as the 16-octet blocksize is maintained.

アルゴリズムの特定の詰め物要件のために、どんな追加詰め物も、暗号文が4八重奏境界で終わるのを保証するのに必要ではありません(すなわち、16八重奏が超能力Pad LengthとNext Header分野が正しくなるという保証をblocksizeすると主張するのが4八重奏の単語の中に並びました)。 [超能力]で指定されるように16八重奏がblocksizeされるとき長さが維持されるように含まれていて、追加詰め物はそうするかもしれません。

2.5.  Performance

2.5. パフォーマンス

   Performance figures of SEED are available at
   http://www.kisa.or.kr/seed/seed_eng.html

SEEDのパフォーマンス図形は http://www.kisa.or.kr/seed/seed_eng.html で利用可能です。

Lee, et al.                 Standards Track                     [Page 3]

RFC 4196               The Use of SEED with IPsec           October 2005

リー、他 規格は2005年10月にIPsecとの種子のRFC4196使用を追跡します[3ページ]。

3.  ESP Payload

3. 超能力有効搭載量

   The ESP Payload is made up of the Initialization Vector(IV) of 16
   octets followed by the encrypted payload.  Thus, the payload field,
   as defined in [ESP], is broken down according to the following
   diagram:

超能力有効搭載量はコード化されたペイロードが支えた16の八重奏の初期設定Vector(IV)で補われます。 したがって、以下のダイヤグラムによると、[超能力]で定義されるペイロード分野は砕けています:

      +---------------+---------------+---------------+---------------+
      |                                                               |
      +               Initialization Vector (16 octets)               +
      |                                                               |
      +---------------+---------------+---------------+---------------+
      |                                                               |
      ~ Encrypted Payload (variable length, a multiple of 16 octets)  ~
      |                                                               |
      +---------------------------------------------------------------+

+---------------+---------------+---------------+---------------+ | | + 初期設定Vector(16の八重奏)+| | +---------------+---------------+---------------+---------------+ | | ~ コード化された有効搭載量(可変長、16の八重奏の倍数)~| | +---------------------------------------------------------------+

   The IV field MUST be the same size as the block size of the cipher
   algorithm being used.  The IV MUST be chosen at random and MUST be
   unpredictable.

IV分野は使用される暗号アルゴリズムのブロック・サイズと同じサイズであるに違いありません。 IVは無作為に選ばなければならなくて、予測できるはずがありません。

   Including the IV in each datagram ensures that decryption of each
   received datagram can be performed, even when some datagrams are
   dropped or re-ordered in transit.

各データグラムにIVを含んでいるのは、それぞれの容認されたデータグラムの復号化を実行できるのを確実にします、いくつかのデータグラムを低下するか、またはトランジットで再注文さえするとき。

   To avoid CBC encryption of very similar plaintext blocks in different
   packets, implementations MUST NOT use a counter or other low-hamming
   distance source for IVs.

異なったパケットの非常に同様の平文ブロックのCBC暗号化を避けるために、実現はIVsにカウンタか他の低く大根役者である距離ソースを使用してはいけません。

4.  Test Vectors

4. テストベクトル

   The first 2 test cases test SEED-CBC encryption.  Each test case
   includes key, the plaintext, and the resulting ciphertext.  All data
   are hexadecimal numbers (not prefixed by "0x").

最初の2つのテストケースがSEED-CBC暗号化をテストします。 各テストケースはキー、平文、および結果として起こる暗号文を含んでいます。 すべてのデータが16進数("0x"によって前に置かれていない)です。

   The last 4 test cases illustrate sample ESP packets using SEED-CBC
   for encryption.  All data are hexadecimal numbers (not prefixed by
   "0x").

ベスト4テストケースは、暗号化にSEED-CBCを使用することでサンプル超能力パケットを例証します。 すべてのデータが16進数("0x"によって前に置かれていない)です。

   Case #1    : Encrypting 32 bytes (2 blocks) using SEED-CBC with
                128-bit key
   Key        : ed2401ad  22fa2559  91bafdb0  1fefd697
   IV         : 93eb149f  92c9905b  ae5cd34d  a06c3c8e
   PlainText  : b40d7003  d9b6904b  35622750  c91a2457
                5bb9a632  364aa26e  3ac0cf3a  9c9d0dcb
   CipherText : f072c5b1  a0588c10  5af8301a  dcd91dd0
                67f68221  55304bf3  aad75ceb  44341c25

#1、をケースに入れてください: 128ビットの主要なKeyとSEED-CBCを使用することで32バイト(2ブロック)をコード化します: ed2401ad 22fa2559 91bafdb0 1fefd697IV: 93eb149f 92c9905b ae5cd34d a06c3c8e PlainText: b40d7003 d9b6904b35622750c91a2457 5bb9a632 364aa26e 3ac0cf3a 9c9d0dcb CipherText: f072c5b1 a0588c10 5af8301a dcd91dd0 67f68221 55304bf3 aad75ceb 44341c25

Lee, et al.                 Standards Track                     [Page 4]

RFC 4196               The Use of SEED with IPsec           October 2005

リー、他 規格は2005年10月にIPsecとの種子のRFC4196使用を追跡します[4ページ]。

   Case #2    : Encrypting 64 bytes (4 blocks) using SEED-CBC with
                128-bit key
   Key        : 88e34f8f  081779f1  e9f39437  0ad40589
   IV         : 268d66a7  35a81a81  6fbad9fa  36162501
   PlainText  : d76d0d18  327ec562  b15e6bc3  65ac0c0f
                8d41e0bb  938568ae  ebfd92ed  1affa096
                394d20fc  5277ddfc  4de8b0fc  e1eb2b93
                d4ae40ef  4768c613  b50b8942  f7d4b9b3
   CipherText : a293eae9  d9aebfac  37ba714b  d774e427
                e8b706d7  e7d9a097  228639e0  b62b3b34
                ced11609  cef2abaa  ec2edf97  9308f379
                c31527a8  267783e5  cba35389  82b48d06

#2、をケースに入れてください: 128ビットの主要なKeyとSEED-CBCを使用することで64バイト(4ブロック)をコード化します: 88e34f8f 081779f1 e9f39437 0ad40589IV: 268d66a7 35a81a81 6fbad9fa36162501平文: d76d0d18 327ec562 b15e6bc3 65ac0c0f 8d41e0bb 938568ae ebfd92ed 1affa096 394d20fc5277ddfc 4de8b0fc e1eb2b93 d4ae40ef4768c613 b50b8942 f7d4b9b3 CipherText: a293eae9 d9aebfac 37ba714b d774e427 e8b706d7 e7d9a097 228639e0 b62b3b34ced11609 cef2abaa ec2edf97 9308f379 c31527a8 267783e5 cba35389 82b48d06

   Case #3  : Sample transport-mode ESP packet (ping 192.168.123.100)
   Key                 : 90d382b4 10eeba7a  d938c46c ec1a82bf
   SPI                 : 4321
   Source address      : 192.168.123.3
   Destination address : 192.168.123.100
   Sequence number     : 1
   IV                  : e96e8c08  ab465763  fd098d45  dd3ff893

#3、をケースに入れてください: 交通機関超能力パケットを抽出してください。(192.168.123.100)キーを確認してください: 90d382b4 10eeba7a d938c46c ec1a82bf SPI: 4321年のソースアドレス: 192.168.123.3 送付先アドレス: 192.168.123.100 一連番号: 1、IV: e96e8c08 ab465763 fd098d45 dd3ff893

   Original packet :
   IP header (20 bytes) : 45000054 08f20000 4001f9fe  c0a87b03  c0a87b64
   Data (64 bytes) :
   08000ebd  a70a0000  8e9c083d  b95b0700
   08090a0b  0c0d0e0f  10111213  14151617
   18191a1b  1c1d1e1f  20212223  24252627
   28292a2b  2c2d2e2f  30313233  34353637

オリジナルのパケット: IPヘッダー(20バイト): 45000054 08f20000 4001f9fe c0a87b03 c0a87b64 Data(64バイト): 08000ebd a70a0000 8e9c083d b95b0700 08090a0b 0c0d0e0f10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f30313233 34353637

   Augment data with :
   Padding     : 01020304  05060708  090a0b0c  0d0e
   Pad length  : 0e
   Next header : 01 (ICMP)

以下でデータを増大させてください。 詰め物: 01020304 05060708 090a0b0c 0d0e Padの長さ: 0e次ヘッダー: 01 (ICMP)

   Pre-encryption Data with padding, pad length and next header(80
   bytes):
   08000ebd  a70a0000  8e9c083d  b95b0700
   08090a0b  0c0d0e0f  10111213  14151617
   18191a1b  1c1d1e1f  20212223  24252627
   28292a2b  2c2d2e2f  30313233  34353637
   01020304  05060708  090a0b0c  0d0e0e01

詰め物があるプレ暗号化Data、パッドの長さ、および次のヘッダー(80バイト): 08000ebd a70a0000 8e9c083d b95b0700 08090a0b 0c0d0e0f10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f30313233 34353637 01020304 05060708 090a0b0c 0d0e0e01

Lee, et al.                 Standards Track                     [Page 5]

RFC 4196               The Use of SEED with IPsec           October 2005

リー、他 規格は2005年10月にIPsecとの種子のRFC4196使用を追跡します[5ページ]。

   Post-encryption packet with SPI, Sequence number, IV :
   IP Header : 45000054 08f20000 4001f9fe  c0a87b03  c0a87b64
   SPI/Seq # : 00004321 00000001
   IV        : e96e8c08  ab465763  fd098d45  dd3ff893
   Encrypted Data (80 bytes) :
   e7ebaa03  cf45ef09  021b3011  b40d3769
   be96ebae  cd4222f6  b6f84ce5  b2d5cdd1
   60eb6b0e  5a47d16a  501a4d10  7b2d7cc8
   ab86ba03  9a000972  66374fa8  f87ee0fb
   ef3805db  faa144a2  334a34db  0b0f81ca

SPIがあるポスト暗号化パケット、Sequence番号、IV: IPヘッダー: 45000054 08f20000 4001f9fe c0a87b03 c0a87b64 SPI/Seq#: 00004321 00000001、IV: e96e8c08 ab465763 fd098d45 dd3ff893 Encrypted Data(80バイト): e7ebaa03 cf45ef09 021b3011 b40d3769be96ebae cd4222f6 b6f84ce5 b2d5cdd1 60eb6b0e5a47d16a 501a4d10 7b2d7cc8 ab86ba03 9a000972 66374fa8 f87ee0fb ef3805db faa144a2 334a34db 0b0f81ca

   Case #4 : Sample transport-mode ESP packet
   (ping -p 77 -s 20 192.168.123.100)
   Key : 90d382b4 10eeba7a d938c46c ec1a82bf
   SPI                 : 4321
   Source address      : 192.168.123.3
   Destination address : 192.168.123.100
   Sequence number     : 8
   IV : 69d08df7 d203329d b093fc49 24e5bd80

#4、をケースに入れてください: 交通機関超能力パケットを抽出してください。(-p77-s20 192.168.123.100)キーを確認してください: 90d382b4 10eeba7a d938c46c ec1a82bf SPI: 4321年のソースアドレス: 192.168.123.3 送付先アドレス: 192.168.123.100 一連番号: 8、IV: 69d08df7 d203329d b093fc49 24e5bd80

   Original packet:
   IP header (20 bytes) : 45000030 08fe0000 4001fa16 c0a87b03 c0a87b64
   Data (28 bytes) :
   0800b5e8 a80a0500 a69c083d 0b660e00 77777777 77777777 77777777

オリジナルのパケット: IPヘッダー(20バイト): 45000030 08fe0000 4001fa16 c0a87b03 c0a87b64 Data(28バイト): 0800b5e8 a80a0500 a69c083d 0b660e00 77777777 77777777 77777777

   Augment data with :
   Padding     : 0102
   Pad length  : 02
   Next header : 01 (ICMP)

以下でデータを増大させてください。 詰め物: 0102は長さを水増しします: 次の02ヘッダー: 01 (ICMP)

   Pre-encryption Data with padding, pad length and
   next header(32 bytes):
   0800b5e8 a80a0500 a69c083d 0b660e00
   77777777 77777777 77777777 01020201

詰め物があるプレ暗号化Data、パッドの長さ、および次のヘッダー(32バイト): 0800b5e8 a80a0500 a69c083d 0b660e00 77777777 77777777 77777777 01020201

   Post-encryption packet with SPI, Sequence number, IV  :
   IP header : 4500004c 08fe0000 4032f9c9 c0a87b03 c0a87b64
   SPI/Seq # : 00004321 00000008
   IV        : 69d08df7 d203329d b093fc49 24e5bd80
   Encrypted Data (32 bytes) :
   b9ad6e19  e9a6a2fa  02569160  2c0af541
   db0b0807  e1f660c7  3ae2700b  5bb5efd1

SPIがあるポスト暗号化パケット、Sequence番号、IV: IPヘッダー: 4500004c 08fe0000 4032f9c9 c0a87b03 c0a87b64 SPI/Seq#: 00004321 00000008、IV: 69d08df7 d203329d b093fc49 24e5bd80 Encrypted Data(32バイト): b9ad6e19 e9a6a2fa02569160 2c0af541 db0b0807 e1f660c7 3ae2700b 5bb5efd1

Lee, et al.                 Standards Track                     [Page 6]

RFC 4196               The Use of SEED with IPsec           October 2005

リー、他 規格は2005年10月にIPsecとの種子のRFC4196使用を追跡します[6ページ]。

   Case #5 : Sample tunnel-mode ESP packet (ping 192.168.123.200)
   Key     : 01234567  89abcdef  01234567  89abcdef
   SPI     : 8765
   Source address      : 192.168.123.3
   Destination address : 192.168.123.200
   Sequence number     : 2
   IV      : f4e76524  4f6407ad  f13dc138  0f673f37

#5、をケースに入れてください: トンネルモード超能力パケットを抽出してください。(192.168.123.200)キーを確認してください: 01234567 89abcdef 01234567 89abcdef SPI: 8765年のソースアドレス: 192.168.123.3 送付先アドレス: 192.168.123.200 一連番号: 2、IV: f4e76524 4f6407ad f13dc138 0f673f37

   Original packet :
   IP header (20 bytes) : 45000054 09040000 4001f988 c0a87b03 c0a87bc8
   Data (64 bytes) :
   08009f76  a90a0100  b49c083d  02a20400
   08090a0b  0c0d0e0f  10111213  14151617
   18191a1b  1c1d1e1f  20212223  24252627
   28292a2b  2c2d2e2f  30313233  34353637

オリジナルのパケット: IPヘッダー(20バイト): 45000054 09040000 4001f988 c0a87b03 c0a87bc8 Data(64バイト): 08009f76 a90a0100 b49c083d 02a20400 08090a0b0c0d0e0f 10111213 14151617 18191a1b1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f30313233 34353637

   Augment data with :
   Padding     : 01020304 05060708 090a
   Pad length  : 0a
   Next header : 04 (IP-in-IP)

以下でデータを増大させてください。 詰め物: 01020304 05060708 090a Padの長さ: 0a Nextヘッダー: 04 (IPにおけるIP)

   Pre-encryption Data with original IP header, padding, pad length and
   next header (96 bytes) :
   45000054  09040000  4001f988  c0a87b03
   c0a87bc8  08009f76  a90a0100  b49c083d
   02a20400  08090a0b  0c0d0e0f  10111213
   14151617  18191a1b  1c1d1e1f  20212223
   24252627  28292a2b  2c2d2e2f  30313233
   34353637  01020304  05060708  090a0a04

オリジナルのIPヘッダーがあるプレ暗号化Data(詰め物)は長さと次のヘッダー(96バイト)を水増しします: 45000054 09040000 4001f988 c0a87b03 c0a87bc8 08009f76 a90a0100 b49c083d02a20400 08090a0b 0c0d0e0f 10111213 14151617 18191a1b1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f30313233 34353637 01020304 05060708 090a0a04

   Post-encryption packet with SPI, Sequence number, IV :
   IP header : 4500008c  09050000  4032f91e  c0a87b03  c0a87bc8
   SPI/Seq # : 00008765  00000002
   IV : f4e76524  4f6407ad  f13dc138  0f673f37
   Encrypted Data (96 bytes):
   2638aa7b  05e71b54  9348082b  67b47b26
   c565aed4  737f0bcb  439c0f00  73e7913c
   3c8a3e4f  5f7a5062  003b78ed  7ca54a08
   c7ce047d  5bec14e4  8cba1005  32a12097
   8d7f5503  204ef661  729b4ea1  ae6a9178
   59a5caac  46e810bd  7875bd13  d6f57b3d

SPIがあるポスト暗号化パケット、Sequence番号、IV: IPヘッダー: 4500008c 09050000 4032f91e c0a87b03 c0a87bc8 SPI/Seq#: 00008765 00000002、IV: f4e76524 4f6407ad f13dc138 0f673f37 Encrypted Data(96バイト): 2638aa7b 05e71b54 9348082b 67b47b26 c565aed4 737f0bcb 439c0f00 73e7913c 3c8a3e4f 5f7a5062 003b78ed7ca54a08 c7ce047d 5bec14e4 8cba1005 32a12097 8d7f5503 204ef661 729b4ea1 ae6a9178 59a5caac 46e810bd 7875bd13 d6f57b3d

Lee, et al.                 Standards Track                     [Page 7]

RFC 4196               The Use of SEED with IPsec           October 2005

リー、他 規格は2005年10月にIPsecとの種子のRFC4196使用を追跡します[7ページ]。

   Case #6 : Sample tunnel-mode ESP packet
   (ping -p ff -s 40 192.168.123.200)
   Key : 01234567  89abcdef  01234567  89abcdef
   SPI : 8765
   Source address      : 192.168.123.3
   Destination address : 192.168.123.200
   Sequence number     : 5
   IV : 85d47224  b5f3dd5d  2101d4ea  8dffab22

#6、をケースに入れてください: トンネルモード超能力パケット(ピング-p ff-s40 192.168.123.200)キーを抽出してください: 01234567 89abcdef 01234567 89abcdef SPI: 8765年のソースアドレス: 192.168.123.3 送付先アドレス: 192.168.123.200 一連番号: 5、IV: 85d47224 b5f3dd5d 2101d4ea 8dffab22

   Original packet :
   IP header (20 bytes) :
   45000044  090c0000  4001f990  c0a87b03  c0a87bc8
   Data (48 bytes) :
   0800d63c  aa0a0200  c69c083d  a3de0300
   ffffffff  ffffffff  ffffffff  ffffffff
   ffffffff  ffffffff  ffffffff  ffffffff

オリジナルのパケット: IPヘッダー(20バイト): 45000044 090c0000 4001f990 c0a87b03 c0a87bc8 Data(48バイト): 0800d63c aa0a0200 c69c083d a3de0300 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff

   Augment data with :
   Padding     : 01020304  05060708  090a
   Pad length  : 0a
   Next header : 04 (IP-in-IP)

以下でデータを増大させてください。 詰め物: 01020304 05060708 090a Padの長さ: 0a Nextヘッダー: 04 (IPにおけるIP)

   Pre-encryption Data with original IP header, padding, pad length and
   next header (80 bytes):
   45000044  090c0000  4001f990  c0a87b03
   c0a87bc8  0800d63c  aa0a0200  c69c083d
   a3de0300  ffffffff  ffffffff  ffffffff
   ffffffff  ffffffff  ffffffff  ffffffff
   ffffffff  01020304  05060708  090a0a04

オリジナルのIPヘッダーがあるプレ暗号化Data(詰め物)は長さと次のヘッダー(80バイト)を水増しします: 45000044 090c0000 4001f990 c0a87b03 c0a87bc8 0800d63c aa0a0200 c69c083d a3de0300 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff01020304 05060708 090a0a04

   Post-encryption packet with SPI, Sequence number, IV :
   IP header : 4500007c  090d0000  4032f926  c0a87b03  c0a87bc8
   SPI/Seq # : 00008765  00000005
   IV : 85d47224  b5f3dd5d  2101d4ea  8dffab22
   Encrypted Data (80 bytes) :
   311168e0  bc36ac4e  59802bd5  192c5734
   8f3d29c8  90bab276  e9db4702  91f79ac7
   79571929  c170f902  ffb2f08b  d448f782
   31671414  ff29b7e0  168e1c87  09ba2b67
   a56e0fbc  4ff6a936  d859ed57  6c16ef1b

SPIがあるポスト暗号化パケット、Sequence番号、IV: IPヘッダー: 4500007c 090d0000 4032f926 c0a87b03 c0a87bc8 SPI/Seq#: 00008765 00000005、IV: 85d47224 b5f3dd5d 2101d4ea 8dffab22 Encrypted Data(80バイト): 311168e0 bc36ac4e 59802bd5 192c5734 8f3d29c8 90bab276 e9db4702 91f79ac7 79571929c170f902 ffb2f08b d448f782 31671414ff29b7e0 168e1c87 09ba2b67 a56e0fbc 4ff6a936 d859ed57 6c16ef1b

Lee, et al.                 Standards Track                     [Page 8]

RFC 4196               The Use of SEED with IPsec           October 2005

リー、他 規格は2005年10月にIPsecとの種子のRFC4196使用を追跡します[8ページ]。

5.  Interaction with IKE

5. IKEとの相互作用

   This section describes the use of IKE [IKE] to establish IPsec ESP
   security associations (SAs) that employ SEED in CBC mode.

このセクションは、CBCモードでSEEDを使うIPsec超能力セキュリティ協会(SAs)を証明するためにIKE[IKE]の使用について説明します。

5.1.  Phase 1 Identifier

5.1. フェーズ1識別子

   For Phase 1 negotiations, the object identifier of SEED-CBC is
   defined in [SEED].

Phase1交渉において、SEED-CBCに関する物の識別子は[SEED]で定義されます。

   algorithm OBJECT IDENTIFIER ::= { iso(1) member-body(2) korea(410)
   kisa(200004) algorithm(1) }

アルゴリズムOBJECT IDENTIFIER:、:= iso(1)は(2) korea(410) kisa(200004)アルゴリズム(1)をメンバーと同じくらい具体化させます。

   id-seedCBC OBJECT IDENTIFIER ::= { algorithm seedCBC(4) }

イド-seedCBC物の識別子:、:= アルゴリズムseedCBC(4)

5.2.  Phase 2 Identifier

5.2. フェーズ2識別子

   For Phase 2 negotiations, IANA has assigned an ESP Transform
   Identifier of (21) for ESP_SEED_CBC.

Phase2交渉のために、IANAは_超能力SEED_CBCのための(21)の超能力Transform Identifierを割り当てました。

5.3.  Key Length Attribute

5.3. キー長属性

   Since the SEED supports 128-bit key lengths, the Key Length attribute
   is set with 128 bits.

SEEDが128ビットのキー長を支持するので、Key Length属性は128ビットで設定されます。

5.4.  Hash Algorithm Considerations

5.4. 細切れ肉料理アルゴリズム問題

   HMAC-SHA-1 [HMAC-SHA] and HMAC-MD5 [HMAC-MD5] are currently
   considered of sufficient strength to serve both as IKE generators of
   128-bit SEED keys and as ESP authenticators for SEED encryption using
   128-bit keys.

現在、十分な力についてHMAC-SHA-1[HMAC-SHA]とHMAC-MD5[HMAC-MD5]が128ビットのSEEDキーのIKEジェネレータとしてSEED暗号化のための超能力固有識別文字として128ビットのキーを使用することで機能すると考えられます。

6.  Security Considerations

6. セキュリティ問題

   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 (by [CRYPTREC]).  For further
   security considerations, the reader is encouraged to read [CRYPTREC],
   [ISOSEED], and [SEED-EVAL].

警備上の問題は全くSEEDで見つけられていません。 SEEDはDifferential暗号文解読術、Linear暗号文解読術、および関連する主要な攻撃を含むすべての知られている攻撃に対して安全です。 最もよく知られている攻撃はキー([CRYPTREC]による)の徹底的な検索にすぎません。 さらなるセキュリティ問題において、読者が[CRYPTREC]、[ISOSEED]、および[SEED-EVAL]を読むよう奨励されます。

7.  IANA Considerations

7. IANA問題

   IANA has assigned ESP Transform Identifier (21) to ESP_SEED_CBC.

IANAは_超能力SEED_CBCに超能力Transform Identifier(21)を割り当てました。

Lee, et al.                 Standards Track                     [Page 9]

RFC 4196               The Use of SEED with IPsec           October 2005

リー、他 規格は2005年10月にIPsecとの種子のRFC4196使用を追跡します[9ページ]。

8.  Acknowledgments

8. 承認

   The authors want to thank Ph.D Haesuk Kim of Future Systems Inc. and
   Brian Kim of OULLIM Information Technology Inc. for providing expert
   advice on Test Vector examples.

作者は、Test Vectorの例で専門家の助言を提供して頂いて、Future Systems Inc.の博士号HaesukキムとOULLIM情報Technology Inc.のブライアン・キムに感謝したがっています。

9.  References

9. 参照

9.1.  Normative References

9.1. 引用規格

   [CBC]       Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
               Algorithms", RFC 2451, November 1998.

[CBC] ペレイラとR.とR.アダムス、「超能力CBC-モード暗号アルゴリズム」、RFC2451、1998年11月。

   [ESP]       Kent, S. and R. Atkinson, "IP Encapsulating Security
               Payload (ESP)", RFC 2406, November 1998.

[超能力] ケントとS.とR.アトキンソン、「セキュリティ有効搭載量(超能力)を要約するIP」、RFC2406、1998年11月。

   [IKE]       Harkins, D. and D. Carrel, "The Internet Key Exchange
               (IKE)", RFC 2409, November 1998.

[IKE]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。

   [KEYWORDS]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [SEED]      Park, J., Lee, S., Kim, J., and J. Lee, "The SEED
               Encryption Algorithm", RFC 4009, February 2005.

2005年2月の[種子]公園とJ.とリーとS.とキム、J.とJ.リー、「種子暗号化アルゴリズム」RFC4009。

   [TTASSEED]  Telecommunications Technology Association (TTA), South
               Korea, "128-bit Symmetric Block Cipher (SEED)", TTAS.KO-
               12.0004, September, 1998 (In Korean)
               http://www.tta.or.kr/English/new/main/index.htm

[TTASSEED]電気通信技術協会(TTA)、韓国「128ビットの左右対称のブロック暗号(種子)」、TTAS.KO12.0004、1998(韓国語の)年9月の http://www.tta.or.kr/English/new/main/index.htm

9.2.  Informative Reference

9.2. 有益な参照

   [AES]       NIST, FIPS PUB 197, "Advanced Encryption Standard(AES),
               November 2001.
               http://csrc.nist.gov/publications/fips/fips197/fips-197.
               {ps,pdf}

[AES]NIST(FIPSパブ197)は「暗号化規格(AES)、2001年11月の http://csrc.nist.gov/publications/fips/fips197/fips-197 を進めました」。 ps、pdf

   [ARCH]      Kent, S. and R. Atkinson, "Security Architecture for the
               Internet Protocol", RFC 2401, November 1998.

[アーチ形に曲げます] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。

   [CRYPTO-S]  Schneier, B., "Applied Cryptography Second Edition", John
               Wiley & Sons, New York, NY, 1995, ISBN 0-471-12845-7.

[暗号S] シュナイアーとB.と「適用された暗号第2版」とジョン・ワイリーと息子、ニューヨーク、ニューヨーク1995、ISBN0-471-12845-7。

   [CRYPTREC]  Information-technology Promotion Agency (IPA), Japan,
               CRYPTREC. "SEED Evaluation Report", February, 2002
               http://www.kisa.or.kr/seed/seed_eng.html

[CRYPTREC]情報技術販売促進代理店(IPA)、日本、CRYPTREC。 「種子評価報告書」、2002年2月の http://www.kisa.or.kr/seed/seed_eng.html

Lee, et al.                 Standards Track                    [Page 10]

RFC 4196               The Use of SEED with IPsec           October 2005

リー、他 規格は2005年10月にIPsecとの種子のRFC4196使用を追跡します[10ページ]。

   [HMAC-MD5]  Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
               ESP and AH", RFC 2403, November 1998.

そして、[HMAC-MD5] マドソン、C.、およびR.グレン、「超能力の中のHMAC-MD5-96の使用、ああ、」、RFC2403、11月1998日

   [HMAC-SHA]  Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
               ESP and AH", RFC 2404, November 1998.

そして、[HMAC-SHA] マドソン、C.、およびR.グレン、「超能力の中のHMAC-SHA-1-96の使用、ああ、」、RFC2404、11月1998日

   [ISOSEED]   ISO/IEC JTC 1/SC 27 N3979, "IT Security techniques -
               Encryption Algorithms - Part3 : Block ciphers", June
               2004.

[ISOSEED]ISO/IEC JTC1/サウスカロライナ27N3979、「IT Securityのテクニック(暗号化Algorithms)Part3:」 2004年6月の「ブロック暗号。」

   [MODES]     Symmetric Key Block Cipher Modes of Operation,
               http://www.nist.gov/modes/.

[モード]対称鍵は暗号運転モード、 http://www.nist.gov/modes/ を妨げます。

   [ROAD]      Thayer, R., N. Doraswamy and R. Glenn, "IP Security
               Document Roadmap", RFC 2411, November 1998.

[道路] セイヤーとR.とN.DoraswamyとR.グレン、「IPセキュリティドキュメント道路地図」、RFC2411、1998年11月。

   [SEED-EVAL] KISA, "Self Evaluation Report",
               http://www.kisa.or.kr/seed/data/Document_pdf/
               SEED_Self_Evaluation.pdf"

「[種子-EVAL] 吉舎、「自己採点レポート」、 http://www.kisa.or.kr/seed/data/Document_pdf/ は_自己_Evaluation.pdfに種を蒔きます」

Authors' Address

作者のアドレス

   Hyangjin Lee
   Korea Information Security Agency
   Phone: +82-2-405-5446
   Fax  : +82-2-405-5319
   EMail : jiinii@kisa.or.kr

Hyangjinリー韓国情報警備機関電話: +82-2-405-5446 ファックスで以下を送ってください。 +82-2-405-5319 メールしてください: jiinii@kisa.or.kr

   Jaeho Yoon
   Korea Information Security Agency
   Phone: +82-2-405-5434
   Fax  : +82-2-405-5219
   EMail : jhyoon@kisa.or.kr

Jaehoチョ韓国情報警備機関電話: +82-2-405-5434 ファックスで以下を送ってください。 +82-2-405-5219 メールしてください: jhyoon@kisa.or.kr

   Seoklae Lee
   Korea Information Security Agency
   Phone: +82-2-405-5230
   Fax  : +82-2-405-5219
   EMail : sllee@kisa.or.kr

Seoklaeリー韓国情報警備機関電話: +82-2-405-5230 ファックスで以下を送ってください。 +82-2-405-5219 メールしてください: sllee@kisa.or.kr

   Jaeil Lee
   Korea Information Security Agency
   Phone: +82-2-405-5200
   Fax  : +82-2-405-5219
   EMail: jilee@kisa.or.kr

Jaeilリー韓国情報警備機関電話: +82-2-405-5200 ファックスで以下を送ってください。 +82-2-405-5219 メールしてください: jilee@kisa.or.kr

Lee, et al.                 Standards Track                    [Page 11]

RFC 4196               The Use of SEED with IPsec           October 2005

リー、他 規格は2005年10月にIPsecとの種子のRFC4196使用を追跡します[11ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(2005)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Lee, et al.                 Standards Track                    [Page 12]

リー、他 標準化過程[12ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

SQLの昇順、降順を表すASCやDESCの言葉の由来

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る