RFC4010 日本語訳
4010 Use of the SEED Encryption Algorithm in Cryptographic MessageSyntax (CMS). J. Park, S. Lee, J. Kim, J. Lee. February 2005. (Format: TXT=22403 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Park
Request for Comments: 4010 S. Lee
Category: Standards Track J. Kim
J. Lee
KISA
February 2005
コメントを求めるワーキンググループJ.公園要求をネットワークでつないでください: 4010秒間リーCategory: 標準化過程J.キムJ.リー吉舎2005年2月
Use of the SEED Encryption Algorithm
in Cryptographic Message Syntax (CMS)
暗号のメッセージ構文における種子暗号化アルゴリズムの使用(cm)
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 specifies the conventions for using the SEED encryption algorithm for encryption with the Cryptographic Message Syntax (CMS).
このドキュメントはCryptographic Message Syntax(CMS)との暗号化にSEED暗号化アルゴリズムを使用するのにコンベンションを指定します。
SEED is added to the set of optional symmetric encryption algorithms in CMS by providing two classes of unique object identifiers (OIDs). One OID class defines the content encryption algorithms and the other defines the key encryption algorithms.
SEEDは、2つのクラスのユニークなオブジェクト識別子(OIDs)を提供することによって、CMSの任意の左右対称の暗号化アルゴリズムのセットに追加されます。 1つのOIDのクラスが満足している暗号化アルゴリズムを定義します、そして、もう片方が主要な暗号化アルゴリズムを定義します。
1. Introduction
1. 序論
This document specifies the conventions for using the SEED encryption algorithm [SEED][TTASSEED] for encryption with the Cryptographic Message Syntax (CMS)[CMS]. The relevant object identifiers (OIDs) and processing steps are provided so that SEED may be used in the CMS specification (RFC 3852, RFC 3370) for content and key encryption.
このドキュメントはCryptographic Message Syntax(CMS)[CMS]との暗号化に、SEED暗号化アルゴリズム[SEED][TTASSEED]を使用するのにコンベンションを指定します。 内容とキー暗号化にCMS仕様(RFC3852、RFC3370)でSEEDを使用できるように関連オブジェクト識別子(OIDs)と処理ステップを提供します。
Park, et al. Standards Track [Page 1] RFC 4010 The SEED Encryption Algorithm in CMS February 2005
公園、他 規格はcm2005年2月にRFC4010種子暗号化アルゴリズムを追跡します[1ページ]。
1.1. SEED
1.1. 種子
SEED is a symmetric encryption algorithm developed by KISA (Korea Information Security Agency) and a group of experts since 1998. The input/output block size and key length of SEED is 128-bits. 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は1998年以来吉舎(韓国情報Security Agency)と専門家のグループによって開発された左右対称の暗号化アルゴリズムです。 SEEDの入力/出力ブロック・サイズとキー長は128ビットです。 SEEDには、ラウンドの16Feistel構造があります。 128ビットの入力は2つの64ビットのブロックに分割されます、そして、正しい64ビットのブロックは丸い機能への入力です、64ビットのサブキーが主要なスケジューリングから生成されている状態で。
SEED is easily implemented in various software and hardware because it takes less memory to implement than other algorithms and generates keys without degrading the security of the algorithm. In particular, it can be effectively adopted in a computing environment with a restricted resources, such as mobile devices and smart cards.
アルゴリズムのセキュリティを下がらせないで、SEEDは実装するメモリより他のアルゴリズムを取るので様々なソフトウェアとハードウェアで容易に実装されて、キーを生成します。 特に、事実上、制限されたリソースでコンピューティング環境でそれを採用できます、モバイル機器やスマートカードのように。
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]などの信用ある組織によって評価されて、安全であると暗号で考えられます。
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 communications.
SEEDは国家の産業組合規格[TTASSEED]であり、ワイヤードでワイヤレスのコミュニケーションで操作された電子商取引と金融サービスに韓国で広く使用されます。
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHOULD"、「「推薦され」て、このドキュメント(中で大文字してください、示されるように)で「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように解釈されることであるべきですか?
2. Object Identifiers for Content and Key Encryption
2. 内容のためのオブジェクト識別子とキー暗号化
This section provides the OIDs and processing information necessary for SEED to be used for content and key encryption in CMS. SEED is added to the set of optional symmetric encryption algorithms in CMS by providing two classes of unique object identifiers (OIDs). One OID class defines the content encryption algorithms and the other defines the key encryption algorithms. Thus, a CMS agent can apply SEED either for content or key encryption by selecting the corresponding object identifier, supplying the required parameter, and starting the program code.
このセクションはSEEDが内容に使用されるためにOIDsと処理必要情報を供給します、そして、CMS. SEEDの主要な暗号化は、2つのクラスのユニークなオブジェクト識別子(OIDs)を提供することによって、CMSの任意の左右対称の暗号化アルゴリズムのセットに追加されます。 1つのOIDのクラスが満足している暗号化アルゴリズムを定義します、そして、もう片方が主要な暗号化アルゴリズムを定義します。その結果、CMSエージェントは内容かキー暗号化のために対応するオブジェクト識別子を選択することによって、SEEDを適用できます、必要なパラメタを提供して、プログラム・コードを開始させて。
Park, et al. Standards Track [Page 2] RFC 4010 The SEED Encryption Algorithm in CMS February 2005
公園、他 規格はcm2005年2月にRFC4010種子暗号化アルゴリズムを追跡します[2ページ]。
2.1. OIDs for Content Encryption
2.1. 満足している暗号化のためのOIDs
SEED is added to the set of symmetric content encryption algorithms defined in [CMSALG]. The SEED content-encryption algorithm in Cipher Block Chaining (CBC) mode has the following object identifier:
SEEDは[CMSALG]で定義された左右対称の満足している暗号化アルゴリズムのセットに追加されます。 Cipher Block Chaining(CBC)モードによるSEED満足している暗号化アルゴリズムには、以下のオブジェクト識別子があります:
id-seedCBC OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) korea(410) kisa(200004)
algorithm(1) seedCBC(4) }
イド-seedCBCオブジェクト識別子:、:= iso(1)メンバーボディー(2)korea(410) kisa(200004)アルゴリズム(1)seedCBC(4)
The AlgorithmIdentifier parameters field MUST be present, and the parameters field MUST contain the value of Initialization Vector (IV):
AlgorithmIdentifierパラメタ分野は存在していなければなりません、そして、パラメタ分野は初期設定Vector(IV)の値を含まなければなりません:
SeedCBCParameter ::= SeedIV -- Initialization Vector
SeedCBCParameter:、:= SeedIV--初期設定ベクトル
SeedIV ::= OCTET STRING (SIZE(16))
SeedIV:、:= 八重奏ストリング(サイズ(16))
The plain text is padded according to Section 6.3 of [CMS].
[CMS]のセクション6.3によると、プレーンテキストは水増しされます。
2.2. OIDs for Key Encryption
2.2. 主要な暗号化のためのOIDs
The key-wrap/unwrap procedures used to encrypt/decrypt a SEED content-encryption key (CEK) with a SEED key-encryption key (KEK) are specified in Section 3. Generation and distribution of key- encryption keys are beyond the scope of this document.
SEEDの満足している暗号化がSEEDの主要な暗号化によって主要な(CEK)キー(KEK)であると暗号化するか、または解読するのにおいて中古の/が開ける主要な包装の手順はセクション3で指定されます。 主要な暗号化キーの生成と分配はこのドキュメントの範囲を超えています。
The SEED key-encryption algorithm has the following object identifier:
SEED主要な暗号化アルゴリズムには、以下のオブジェクト識別子があります:
id-npki-app-cmsSeed-wrap OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) korea(410) kisa(200004) npki-app(7)
smime(1) alg(1) cmsSEED-wrap(1) }
cmsSeedが包装するイドnpki装置オブジェクト識別子:、:= iso(1)メンバーボディー(2)korea(410) kisa(200004) npki装置(7)smime(1) alg(1) cmsSEED包装(1)
The parameter associated with this object identifier MUST be absent, because the key wrapping procedure itself defines how and when to use an IV.
このオブジェクト識別子に関連しているパラメタは欠けるに違いありません、主要なラッピング手順自体が、どのように、いつIVを使用するかを定義するので。
3. Key Wrap Algorithm
3. 主要な包装アルゴリズム
SEED key wrapping and unwrapping is done in conformance with the AES key wrap algorithm [RFC3394].
AESの主要な包装アルゴリズム[RFC3394]で順応でSEEDの主要なラッピングと開けることをします。
3.1. Notation and Definitions
3.1. 記法と定義
The following notation is used in the description of the key wrapping algorithms:
以下の記法は主要なラッピングアルゴリズムの記述に使用されます:
Park, et al. Standards Track [Page 3] RFC 4010 The SEED Encryption Algorithm in CMS February 2005
公園、他 規格はcm2005年2月にRFC4010種子暗号化アルゴリズムを追跡します[3ページ]。
SEED(K, W) Encrypt W using the SEED codebook with key K
SEED-1(K, W) Decrypt W using the SEED codebook with key K
MSB(j, W) Return the most significant j bits of W
LSB(j, W) Return the least significant j bits of W
B1 ^ B2 The bitwise exclusive or (XOR) of B1 and B2
B1 | B2 Concatenate B1 and B2
K The key-encryption key K
n The number of 64-bit key data blocks
s The number of steps in the wrapping process,
s = 6n
P[i] The ith plaintext key data block
C[i] The ith ciphertext data block
A The 64-bit integrity check register
R[i] An array of 64-bit registers where
i = 0, 1, 2, ..., n
A[t], R[i][t] The contents of registers A and R[i] after
encryption step t.
IV The 64-bit initial value used during the
wrapping process.
W LSB(j、W)の最も重要なjビットが最も重要でないjビットのW B1^B2を返す主要なK MSB(j、W)リターンがあるSEED符号表を使用することでSEED-1(K、W)がWを解読するキーKがあるSEED符号表を使用して、SEED(K、W)がWを暗号化する、bitwiseする、排他的である、B1とB2 B1の(XOR)| B2はB1を連結します、そして、B2Kの主要な暗号化の主要なK nはラッピングのステップの数が処理する64ビットの重要なデータブロックsの数を連結して、s=6n P[i]はith平文重要なデータブロックCです。[i] ith暗号文データは64ビットの配列がiが0、1、2と等しいところに登録するA64ビットの保全チェックレジスタR[i]を妨げます…, n A[t]、レジスタAとR[i]後暗号化のコンテンツが踏むR[i][t]、t。 IV初期の値がラッピングの間に使用した64ビットプロセス。
In the key wrap algorithm, the concatenation function will be used to concatenate 64-bit quantities to form the 128-bit input to the SEED codebook. The extraction functions will be used to split the 128-bit output from the SEED codebook into two 64-bit quantities.
主要な包装アルゴリズムで、連結機能は、128ビットの入力をSEED符号表に形成するのに64ビットの量を連結するのにおいて使用するでしょう。 抽出機能は、128ビットの出力をSEED符号表から2つの64ビットの量に分けるのに使用されるでしょう。
3.2. SEED Key Wrap
3.2. 種子キー包装
Key wrapping with SEED is identical to Section 2.2.1 of [RFC3394] with "AES" replaced by "SEED".
SEEDがある主要なラッピングは.1セクション2.2[RFC3394]と「AES」を「種子」に取り替えていて同じです。
The inputs to the key wrapping process are the KEK and the plaintext to be wrapped. The plaintext consists of n 64-bit blocks containing the key data being wrapped. The key wrapping process is described below.
主要なラッピングプロセスへの入力は、包装されるべきKEKと平文です。 平文は包装される重要なデータを含むn64ビットのブロックから成ります。 主要なラッピングプロセスは以下で説明されます。
Inputs: Plaintext, n 64-bit values {P[1], P[2], ..., P[n]}, and
Key, K (the KEK).
Outputs: Ciphertext, (n+1) 64-bit values {C[0], C[1], ..., C[n]}.
入力: 平文、n64ビットの値P[1]、P[2]、…、P[n]、およびKey、K(KEK)。 出力: 暗号文、(n+1)64ビットの値C[0]、C[1]、…、C[n]。
1) Initialize variables.
1) 変数を初期化してください。
Set A[0] to an initial value (see Section 3.4)
For i = 1 to n
R[0][i] = P[i]
i=1〜n R[0][i]=Pのために初期の値(セクション3.4を見る)にA[0]を設定してください。[i]
Park, et al. Standards Track [Page 4] RFC 4010 The SEED Encryption Algorithm in CMS February 2005
公園、他 規格はcm2005年2月にRFC4010種子暗号化アルゴリズムを追跡します[4ページ]。
2) Calculate intermediate values.
2) 中間的値について計算してください。
For t = 1 to s, where s = 6n
A[t] = MSB(64, SEED(K, A[t-1] | R[t-1][1])) ^ t
For i = 1 to n-1
R[t][i] = R[t-1][i+1]
R[t][n] = LSB(64, SEED(K, A[t-1] | R[t-1][1]))
s=6n A[t]がMSBと等しいsへのt=1、(64、SEED、(K、n-1 R[t][i]=R[t-1][i+1]R[t][n]へのA[t-1]| R[t-1][1]))^t For i=1はLSBと等しいです。(64、種子、(A[t-1]| K、R[t-1][1]))
3) Output the results.
3) 結果を出力してください。
Set C[0] = A[s]
For i = 1 to n
C[i] = R[s][i]
1〜n i=C[i]=R[s]にC[0]=A[s]を設定してください。[i]
An alternative description of the key wrap algorithm involves indexing rather than shifting. This approach allows one to calculate the wrapped key in place, avoiding the rotation in the previous description. This produces identical results and is more easily implemented in software.
主要な包装アルゴリズムの代替の記述は、移行するよりむしろ索引をつけることを伴います。 このアプローチで、前の記述における回転を避けて、人は適所にある包装されたキーについて計算できます。 これは、同じ結果を生んで、ソフトウェアで、より容易に実装されます。
Inputs: Plaintext, n 64-bit values {P[1], P[2], ..., P[n]}, and
Key, K (the KEK).
Outputs: Ciphertext, (n+1) 64-bit values {C[0], C[1], ..., C[n]}.
入力: 平文、n64ビットの値P[1]、P[2]、…、P[n]、およびKey、K(KEK)。 出力: 暗号文、(n+1)64ビットの値C[0]、C[1]、…、C[n]。
1) Initialize variables.
1) 変数を初期化してください。
Set A = IV, an initial value (see Section 3.4)
For i = 1 to n
R[i] = P[i]
A=IVを設定してください、そして、i=1〜n R[i]のための初期の値(セクション3.4を見る)はPと等しいです。[i]
2) Calculate intermediate values.
2) 中間的値について計算してください。
For j = 0 to 5
For i=1 to n
B = SEED(K, A | R[i])
A = MSB(64, B) ^ t where t = (n*j)+i
R[i] = LSB(64, B)
n Bへの0〜5j=For i=1=SEED、(K、A| R[i])Aは(n*j)+i t=R[i]がLSBと等しいMSB(64、B)^tと等しいです。(64、B)
3) Output the results.
3) 結果を出力してください。
Set C[0] = A
For i = 1 to n
C[i] = R[i]
1〜n C[0]=For i=C[i]=Rを設定してください。[i]
Park, et al. Standards Track [Page 5] RFC 4010 The SEED Encryption Algorithm in CMS February 2005
公園、他 規格はcm2005年2月にRFC4010種子暗号化アルゴリズムを追跡します[5ページ]。
3.3. SEED Key Unwrap
3.3. 種子キーは開けられます。
Key unwrapping with SEED is identical to Section 2.2.2 of [RFC3394], with "AES" replaced by "SEED".
SEEDとの主要な開けるのは.2セクション2.2[RFC3394]と「AES」を「種子」に取り替えていて同じです。
The inputs to the unwrap process are the KEK and (n+1) 64-bit blocks of ciphertext consisting of previously wrapped key. It returns n blocks of plaintext consisting of the n 64-bit blocks of the decrypted key data.
開けてください。入力、プロセスは以前に包装されたキーのKEKと(n+1)64ビットのブロックの暗号文の成ることです。 それは解読された重要なデータのn64ビットのブロックのnブロックについて平文の成ることを返します。
Inputs: Ciphertext, (n+1) 64-bit values {C[0], C[1], ..., C[n]},
and Key, K (the KEK).
Outputs: Plaintext, n 64-bit values {P[1], P[2], ..., P[n]}.
入力: 暗号文、(n+1)64ビットの値C[0]、C[1]、…、C[n]、およびKey、K(KEK)。 出力: 平文、nの64ビットはP[1]、P[2]、…、P[n]を評価します。
1) Initialize variables.
1) 変数を初期化してください。
Set A[s] = C[0] where s = 6n
For i = 1 to n
R[s][i] = C[i]
[0] sが6n For iと= 1〜n R[s][i]=C等しいところにA[s]=Cを設定してください。[i]
2) Calculate the intermediate values.
2) 中間的値について計算してください。
For t = s to 1
A[t-1] = MSB(64, SEED-1(K, ((A[t] ^ t) | R[t][n]))
R[t-1][1] = LSB(64, SEED-1(K, ((A[t]^t) | R[t][n]))
For i = 2 to n
R[t-1][i] = R[t][i-1]
1A[t-1]=MSBへのt=s、(64、SEED-1、(K、(A[t]^t)| R[t][n]))R[t-1][1]がLSBと等しい、(64、SEED-1、(K、(A[t]^t)| i=2〜n R[t-1][i]のためのR[t][n]))はR[t]と等しいです。[i-1]
3) Output the results.
3) 結果を出力してください。
If A[0] is an appropriate initial value (see Section 3.4),
Then
For i = 1 to n
P[i] = R[0][i]
Else
Return an error
A[0]であるなら、適切な初期の値(セクション3.4を見る)、R[0][i]のほかのThen For i=1〜n P[i]=Returnは誤りですか?
The unwrap algorithm can also be specified as an index based operation, allowing the calculations to be carried out in place. Again, this produces the same results as the register shifting approach.
アルゴリズム缶を開けてください、そして、また、インデックスが操作を基礎づけたので、指定されてください、計算が適所に行われるのを許容して。 一方、これはアプローチを移行させるレジスタと同じ結果を生みます。
Inputs: Ciphertext, (n+1) 64-bit values {C[0], C[1], ..., C[n]},
and Key, K (the KEK).
Outputs: Plaintext, n 64-bit values {P[0], P[1], ..., P[n]}.
入力: 暗号文、(n+1)64ビットの値C[0]、C[1]、…、C[n]、およびKey、K(KEK)。 出力: 平文、nの64ビットはP[0]、P[1]、…、P[n]を評価します。
Park, et al. Standards Track [Page 6] RFC 4010 The SEED Encryption Algorithm in CMS February 2005
公園、他 規格はcm2005年2月にRFC4010種子暗号化アルゴリズムを追跡します[6ページ]。
1) Initialize variables.
1) 変数を初期化してください。
Set A = C[0]
For i = 1 to n
R[i] = C[i]
セットAはC[0]と1〜n R[i]=i=C等しいです。[i]
2) Compute intermediate values.
2) 中間的値を計算してください。
For j = 5 to 0
For i = n to 1
B = SEED-1(K, (A ^ t) | R[i]) where t = n*j+i
A = MSB(64, B)
R[i] = LSB(64, B)
nから1B=5〜0j=For i=SEED-1、(K、(^t)| tがn*j+i A=MSB(64、B)R[i]と等しいR[i])はLSBと等しいです。(64、B)
3) Output results.
3) 出力は結果として生じます。
If A is an appropriate initial value (see Section 3.4),
Then
For i = 1 to n
P[i] = R[i]
Else
Return an error
Aであるなら、適切な初期の値(セクション3.4を見る)、R[i]のほかのThen For i=1〜n P[i]=Returnは誤りですか?
3.4. Key Data Integrity -- the Initial Value
3.4. 重要なデータ保全--初期の値
The initial value (IV) refers to the value assigned to A[0] in the first step of the wrapping process. This value is used to obtain an integrity check on the key data. In the final step of the unwrapping process, the recovered value of A[0] is compared to the expected value of A[0]. If there is a match, the key is accepted as valid, and the unwrapping algorithm returns it. If there is not a match, then the key is rejected, and the unwrapping algorithm returns an error.
初期の値(IV)はラッピングプロセスの第一歩でA[0]に割り当てられた値について言及します。 この値は、重要なデータの保全チェックを得るのに使用されます。 開けるプロセスの最終的なステップでは、A[0]の回復している値はA[0]の期待値にたとえられます。 マッチがあれば、キーは有効であるとして認められます、そして、開けるアルゴリズムはそれを返します。 マッチがなければ、キーは拒絶されます、そして、開けるアルゴリズムは誤りを返します。
The exact properties achieved by this integrity check depend on the definition of the initial value. Different applications may call for somewhat different properties; for example, whether there is a need to determine the integrity of key data throughout its lifecycle or just when it is unwrapped. This specification defines a default initial value that supports the integrity of the key data during the period it is wrapped (in Section 3.4.1). Provision is also made to support alternative initial values (in Section 3.4.2).
この保全チェックで獲得された正確な特性は初期の価値の定義に依存します。 異なったアプリケーションはいくらか異なった特性を求めるかもしれません。 lifecycle中で重要なデータの保全を決定する必要が例えばあるか、またはちょうどそれが開けられるとき。 この仕様はそれが包装される(セクション3.4.1で)期間、重要なデータの保全をサポートするデフォルトの初期の値を定義します。 また、代替の初期の値(セクション3.4.2における)をサポートするのを設備をします。
Park, et al. Standards Track [Page 7] RFC 4010 The SEED Encryption Algorithm in CMS February 2005
公園、他 規格はcm2005年2月にRFC4010種子暗号化アルゴリズムを追跡します[7ページ]。
3.4.1. Default Initial Value
3.4.1. デフォルトの初期の値
The default initial value (IV) is defined to be the hexadecimal constant:
デフォルトの初期の値(IV)は16進定数になるように定義されます:
A[0] = IV = A6A6A6A6A6A6A6A6
A[0]=IVはA6A6A6A6A6A6A6A6と等しいです。
The use of a constant as the IV supports a strong integrity check on the key data during the period that it is wrapped. If unwrapping produces A[0] = A6A6A6A6A6A6A6A6, then the chance that the key data is corrupt is 2^-64. If unwrapping produces A[0] = any other value, then the unwrap must return an error and not return any key data.
IVとしての定数の使用はそれが包装される期間、重要なデータの強い保全チェックをサポートします。 開けるのがA[0]=A6A6A6A6A6A6A6A6を生産するなら、重要なデータが間違っているという機会は2^-64です。 開けてください。生産物を開けるなら、A[0]はいかなる他の値とも等しいです、そして誤りを返して、少しの重要なデータも返してはいけません。
3.4.2. Alternative Initial Values
3.4.2. 代替の初期の値
When the key wrap is used as part of a larger key management protocol or system, the desired scope for data integrity may be more than just the key data, and the desired duration may be more than just the period that it is wrapped. Also, if the key data is not just a SEED key, it may not always be a multiple of 64 bits. Alternative definitions of the initial value can be used to address such problems. According to RFC 3394 [RFC3394], NIST will define alternative initial values in future key management publications as they are needed. To accommodate a set of alternatives that may evolve over time, non-application-specific key wrap implementations will require some flexibility in the way the initial value is set and tested.
主要な包装が、より大きいかぎ管理プロトコルかシステムの一部として使用されるとき、データ保全のための必要な範囲がまさしく重要なデータ以上であるかもしれなく、必要な持続時間はまさしくそれが包装される期間以上であるかもしれません。 また、重要なデータが単なるSEEDキーでないなら、それはいつも64ビットの倍数であるかもしれないというわけではありません。 そのようなその問題を訴えるのに初期の価値の代替の定義を使用できます。RFC3394[RFC3394]によると、それらが必要であるようにNISTは将来のかぎ管理刊行物で代替の初期の値を定義するでしょう。 時間がたつにつれて発展するかもしれない1セットの代替手段に対応するために、非アプリケーションの詳細の主要な包装実装は初期の値が設定されて、テストされる方法で何らかの柔軟性を必要とするでしょう。
4. SMIMECapabilities Attribute
4. SMIMECapabilities属性
An S/MIME client SHOULD announce the set of cryptographic functions it supports by using the S/MIME capabilities attribute. This attribute provides a partial list of OIDs of cryptographic functions and MUST be signed by the client. The functions' OIDs SHOULD be logically separated in functional categories and MUST be ordered with respect to their preference.
SHOULDがS/MIME能力属性を使用することでそれがサポートする暗号の機能のセットを発表するS/MIMEクライアント。 この属性を暗号の機能のOIDsの部分的なリストを提供して、クライアントは署名しなければなりません。 機能のOIDs SHOULDを機能的なカテゴリで論理的に切り離して、彼らの好みに関して注文しなければなりません。
RFC 3851 [RFC3851], Section 2.5.2 defines the SMIMECapabilities signed attribute (defined as a SEQUENCE of SMIMECapability SEQUENCEs) to be used to specify a partial list of algorithms that the software announcing the SMIMECapabilities can support.
RFC3851[RFC3851]、セクション2.5.2はソフトウェアがSMIMECapabilitiesを発表する場合サポートすることができるアルゴリズムの部分的なリストを指定するのに使用されるために属性(SMIMECapability SEQUENCEsのSEQUENCEと定義される)であると署名されるSMIMECapabilitiesを定義します。
If an S/MIME client is required to support symmetric encryption with SEED, the capabilities attribute MUST contain the SEED OID specified above in the category of symmetric algorithms. The parameter associated with this OID MUST be SeedSMimeCapability.
S/MIMEクライアントがSEEDとの左右対称の暗号化をサポートするのに必要であるなら、能力属性は上でカテゴリで指定されたSEED OIDを含まなければなりません。左右対称のアルゴリズムこのOID MUSTに関連しているパラメタでは、SeedSMimeCapabilityになってください。
SeedSMimeCapabilty ::= NULL
SeedSMimeCapabilty:、:= ヌル
Park, et al. Standards Track [Page 8] RFC 4010 The SEED Encryption Algorithm in CMS February 2005
公園、他 規格はcm2005年2月にRFC4010種子暗号化アルゴリズムを追跡します[8ページ]。
The SMIMECapability SEQUENCE representing SEED MUST be DER-encoded as the following hexadecimal strings:
SEED MUSTを表すSMIMECapability SEQUENCEは以下の16進ストリングとしてDERによってコード化されています:
30 0C 06 08 2A 83 1A 8C 9A 44 01 04 05 00
30 0C06 08 2A83 1A8C9A44 01 04 05 00
When a sending agent creates an encrypted message, it has to decide which type of encryption algorithm to use. In general, the decision process involves information obtained from the capabilities lists included in messages received from the recipient, as well as other information, such as private agreements, user preferences and legal restrictions. If local policy requires the use of SEED for symmetric encryption, then both the sending and receiving S/MIME clients must support it, and SEED must be configured as the preferred symmetric algorithm.
送付エージェントが暗号化メッセージを作成するとき、それは、どのタイプの暗号化アルゴリズムを使用するかを決めなければなりません。 一般に、決定プロセスは受取人から受け取られたメッセージにリストを含んでいて、能力から得られた情報にかかわります、他の情報と同様に、個人的な協定や、ユーザー選択や法的規制などのように。 ローカルの方針がSEEDの左右対称の暗号化の使用を必要とするなら、両方の送受信S/MIMEクライアントはそれをサポートしなければなりません、そして、都合のよい左右対称のアルゴリズムとしてSEEDを構成しなければなりません。
5. Security Considerations
5. セキュリティ問題
This document specifies the use of SEED for encrypting the content of a CMS message and for encrypting the symmetric key used to encrypt the content of a CMS message, with the other mechanisms being the same as the existing ones. Therefore, the security considerations described in the CMS specifications [CMS][CMSALG] and the AES key wrap algorithm [RFC3394] can be applied to this document. No security problem has been found on SEED [CRYPTREC].
このドキュメントはSEEDのCMSメッセージの内容を暗号化して、CMSメッセージの内容を暗号化するのに使用される対称鍵を暗号化する使用を指定します、他のメカニズムが既存のものと同じ状態で。 したがって、CMS仕様[CMS][CMSALG]とAESの主要な包装アルゴリズム[RFC3394]で説明されたセキュリティ問題はこのドキュメントに適用できます。 警備上の問題は全くSEED[CRYPTREC]で見つけられていません。
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[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
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
3852, July 2004.
[cm] Housley、R.、「暗号のメッセージ構文(cm)」、RFC3852、2004年7月。
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002.
[CMSALG] Housley、R.、「暗号のメッセージ構文(cm)アルゴリズム」、RFC3370、2002年8月。
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[RFC3851] Ramsdell、B.、「安全な/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1メッセージ仕様」、RFC3851、2004年7月。
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap Algorithm", RFC 3394, September 2002.
[RFC3394] SchaadとJ.とR.Housley、「エー・イー・エス(AES)の主要な包装アルゴリズム」、RFC3394、2002年9月。
Park, et al. Standards Track [Page 9] RFC 4010 The SEED Encryption Algorithm in CMS February 2005
公園、他 規格はcm2005年2月にRFC4010種子暗号化アルゴリズムを追跡します[9ページ]。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
6.2. Informative References
6.2. 有益な参照
[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。
[ISOSEED] ISO/IEC, ISO/IEC JTC1/SC 27 N 256r1, "National Body
contributions on NP 18033 Encryption algorithms in
response to document SC 27 N 2563", October, 2000
[ISOSEED]ISO/IEC、ISO/IEC JTC1/サウスカロライナ27N256r1、「ドキュメントサウスカロライナ27N2563に対応したNP18033Encryptionアルゴリズムにおける国家のBody貢献」、2000年10月
[CRYPTREC] Information-technology Promotion Agency (IPA), Japan,
CRYPTREC. "SEED Evaluation Report", February, 2002
http://www.kisa.or.kr
[CRYPTREC]情報技術販売促進代理店(IPA)、日本、CRYPTREC。 「種子評価報告書」、2002年2月の http://www.kisa.or.kr
Park, et al. Standards Track [Page 10] RFC 4010 The SEED Encryption Algorithm in CMS February 2005
公園、他 規格はcm2005年2月にRFC4010種子暗号化アルゴリズムを追跡します[10ページ]。
Appendix A. ASN.1 Module
付録A.ASN.1モジュール
SeedEncryptionAlgorithmInCMS
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs9(9) smime(16) modules(0) id-mod-cms-seed(24) }
SeedEncryptionAlgorithmInCMSiso(1)が(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16)モジュール(0)イドモッズ風で(2) 私たちをメンバーと同じくらい具体化させる、-(24)にcm種を蒔いてください。
DEFINITIONS IMPLICIT TAGS ::=
定義、内在しているタグ:、:=
BEGIN
始まってください。
id-seedCBC OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) korea(410) kisa(200004)
algorithm(1) seedCBC(4) }
イド-seedCBCオブジェクト識別子:、:= iso(1)メンバーボディー(2)korea(410) kisa(200004)アルゴリズム(1)seedCBC(4)
-- Initialization Vector (IV)
-- 初期設定ベクトル(IV)
SeedCBCParameter ::= SeedIV
SeedIV ::= OCTET STRING (SIZE(16))
SeedCBCParameter:、:= SeedIV SeedIV:、:= 八重奏ストリング(サイズ(16))
-- SEED Key Wrap Algorithm identifiers - Parameter is absent.
-- SEED Key Wrap Algorithm識別子--パラメタは欠けています。
id-npki-app-cmsSeed-wrap OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) korea(410) kisa(200004) npki-app(7)
smime(1) alg(1) cmsSEED-wrap(1) }
cmsSeedが包装するイドnpki装置オブジェクト識別子:、:= iso(1)メンバーボディー(2)korea(410) kisa(200004) npki装置(7)smime(1) alg(1) cmsSEED包装(1)
-- SEED S/MIME Capability parameter
-- SEED S/MIME Capabilityパラメタ
SeedSMimeCapability ::= NULL
SeedSMimeCapability:、:= ヌル
END
終わり
Park, et al. Standards Track [Page 11] RFC 4010 The SEED Encryption Algorithm in CMS February 2005
公園、他 規格はcm2005年2月にRFC4010種子暗号化アルゴリズムを追跡します[11ページ]。
Authors' Addresses
作者のアドレス
Jongwook Park Korea Information Security Agency 78, Garak-Dong, Songpa-Gu, Seoul, 138-803 REPUBLIC OF KOREA
Jongwook公園韓国情報警備機関78、Garak-ドング、Songpa-Gu、ソウル、138-803大韓民国
Phone: +82-2-405-5432 FAX : +82-2-405-5499 EMail: khopri@kisa.or.kr
以下に電話をしてください。 +82-2-405-5432 ファックスで以下を送ってください。 +82-2-405-5499 メールしてください: khopri@kisa.or.kr
Sungjae Lee Korea Information Security Agency
Sungjaeリー韓国情報警備機関
Phone: +82-2-405-5243 FAX : +82-2-405-5499 EMail: sjlee@kisa.or.kr
以下に電話をしてください。 +82-2-405-5243 ファックスで以下を送ってください。 +82-2-405-5499 メールしてください: sjlee@kisa.or.kr
Jeeyeon Kim Korea Information Security Agency
Jeeyeonキム韓国情報警備機関
Phone: +82-2-405-5238 FAX : +82-2-405-5499 EMail: jykim@kisa.or.kr
以下に電話をしてください。 +82-2-405-5238 ファックスで以下を送ってください。 +82-2-405-5499 メールしてください: jykim@kisa.or.kr
Jaeil Lee Korea Information Security Agency Phone: +82-2-405-5300 FAX : +82-2-405-5499 EMail: jilee@kisa.or.kr
Jaeilリー韓国情報警備機関電話: +82-2-405-5300 ファックスで以下を送ってください。 +82-2-405-5499 メールしてください: jilee@kisa.or.kr
Park, et al. Standards Track [Page 12] RFC 4010 The SEED Encryption Algorithm in CMS February 2005
公園、他 規格はcm2005年2月にRFC4010種子暗号化アルゴリズムを追跡します[12ページ]。
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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Park, et al. Standards Track [Page 13]
公園、他 標準化過程[13ページ]
一覧
スポンサーリンク
