|
ネットワーク WG Request for Comments： 3874 分類： 情報提供 |
R. Housley Vigil Security 2004年9月 |
このメモは、 インターネットコミュニティに情報を提供するものです。 これは、いかなるインターネット標準をも定めるものではありません。 このメモの配布には制限はありません。
Copyright (C) The Internet Society (2004).
本書は、 SHA-224と呼ばれる224bitの一方向ハッシュ関数を規定します。 SHA-224は、SHA-256に基づいていますが、 異なるIVを使っており、その結果は、 224bitに切り詰められています。
本書は、SHA-224と呼ばれる224bitの一方向ハッシュ関数を規定します。 NIST (National Institute of Standards and Technology)は、 2004年2月28日に、 SHA-224一方向ハッシュ関数を規定しているFIPS 180-2の変更通知をアナウンスしました。 一方向ハッシュ関数は、 メッセージダイジェストとしても知られています。 SHA-224は、SHA-256(既にNIST [SHA2] によって規定されている256bitの一方向ハッシュ関数)に基づいています。 SHA-224ハッシュ値の計算処理は、2段階です。 まず、異なるIVが使われる以外は、 SHA-256のハッシュ値が計算処理されます。 2番目に、結果としての256bitのハッシュ値は、 224bitに切り詰められます。
NISTは、暗号鍵の管理についてのガイダンスを策定中であり、 NISTは、最近、 コメントを募るドラフト [NISTGUIDE] を発行しました。 5つのセキュリティレベル(80, 112, 128, 192, 256bitのセキュリティ)が、 そのガイダンスにおいて検討されています。 一方向ハッシュ関数は、ひとつを除いて、 これらのすべてのレベル用に利用可能です。 SHA-224は、このvoidになります。 SHA-224は、112bitのセキュリティ(これは、通常、Triple-DES [3DES] で受容される強さです。) を提供する一方向ハッシュ関数です。
本書は、インターネットコミュニティに、 SHA-224一方向ハッシュ関数仕様を利用可能にし、これは、 ASN.1-basedプロトコルにおける用途のためにオブジェクト識別子を発行する。
SHA-224は、SHA-256に基づいているので、概ね同量の労力が、 SHA-224もしくはSHA-256のメッセージダイジェスト値を計算するために費やされる。 SHA-224とSHA-256は、概ね同等の計算量的複雑性をもちますが、 SHA-224は、112bitのセキュリティを提供する一方向ハッシュ関数について、 適切な選択肢のひとつです。 異なるIVの利用は、 「切り詰められたSHA-256のメッセージダイジェスト値は、 同一のデータについて計算されたSHA-224メッセージダイジェスト値と間違われることができないこと」を確保します。
利用環境によっては、 転送されるすべてのオクテットに対して神経質なところがあります。 これらの場合において、SHA-224によって提供される、 (4octetによる)より小さなメッセージダイジェスト値が重要です。
これらの観察によって、下記のガイダンスが導かれます。：
本書中のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"は、 [STDWORDS] に記述されているように解釈されるべきものです。
SHA-224は、長さが264bitsより短いメッセージについての一方向ハッシュ値を計算処理するために使われる可能性があります。
SHA-224は、SHA-256 [SHA2] を利用しています。 一方向ハッシュ値を計算処理するために、SHA-256は、 sixty-four 32-bit words、eight 32-bit working変数のメッセージscheduleを使い、 eight 32-bit wordsのハッシュ値を作りりだします。
その関数は、下記の2つの例外を伴うSHA-256と同一の作法で定義されます。：
まず、SHA-224について、 8つの32-bit working変数(collectively called H)の初期ハッシュ値は、下記の eight 32-bit words (in hex)から成るものとする。：
H_0 = c1059ed8 H_4 = ffc00b31
H_1 = 367cd507 H_5 = 68581511
H_2 = 3070dd17 H_6 = 64f98fa7
H_3 = f70e5939 H_7 = befa4fa4
2番目に、SHA-224は、単に、最初の7つの32-bit wordsをSHA-256の結果中に(SHA-256の結果中の残る32-bit wordsを無視して)適用します。 すなわち、Hの最終的な値は、下記のように使われます。 ここで、|| は、concatenationを表しています。：
H_0 || H_1 || H_2 || H_3 || H_4 || H_5 || H_6
この章には、3つのテストベクターが示されます。 これらのテストベクターは、 SHA-224の実装をテストするために使えます。
そのメッセージを、 下記のバイナリと同等である24-bitのASCII文字列 "abc"となるようにハッシュ化します。：
01100001 01100010 01100011
SHA-224ハッシュ値は、下記のとおりです(in hex)。：
75388b16 512776cc 5dba5da1 fd890150 b0c6455c b4f58b19 52522525
そのメッセージを448-bitのASCII文字列"abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq"となるようにハッシュ化します。
SHA-224ハッシュ値は、下記のとおりです(in hex)。：
75388b16 512776cc 5dba5da1 fd890150 b0c6455c b4f58b19 52522525
そのメッセージを、 文字"a"の1,000,000字から成るASCII文字列のbinary-coded形式となるようにハッシュ化します。
SHA-224ハッシュ値は、下記のとおりです(in hex)。：
20794655 980c91d8 bbb4c1ea 97618a4b f03f4258 1948b2ee 4ee7ad67
NISTは、SHA-224についてのASN.1 [X.208-88, X.209-88] オブジェクト識別子を割り当てました。 プロトコルによっては、一方向ハッシュ関数を指名するために、 オブジェクト識別子を使います。 一例は、CMS [CMS] です。 SHA-224を利用する、このようなプロトコルの実装は、 下記のオブジェクト識別子を使わなければなりません(MUST)。
id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) sha224(4) }
一方向ハッシュ関数は、典型的には、 (デジタル署名アルゴリズムや鍵つきHMACのような)他の暗号アルゴリズムと共に、 あるいは、random値の生成において使われます。 一方向ハッシュ関数が他のアルゴリズムと組み合わせて使われているとき、 一定数bitのセキュリティの一方向ハッシュ関数の利用を要求するどこかで規定された要件がある可能性があります。 たとえば、あるメッセージが 128bitのセキュリティを提供するデジタル署名アルゴリズムで署名される場合、 その署名アルゴリズムは、 同数bitのセキュリティを提供する一方向ハッシュアルゴリズムの利用を要求する可能性がります。 SHA-224は、112bitのセキュリティ(これは、一般に、 受容されているTriple-DES [3DES] の強度)を提供することが意図されています。
本書は、 SHA-224仕様をインターネットコミュニティに提供することが意図されています。 この一方向ハッシュ関数のセキュリティについての独立した宣言は、 いかなる特定用途についても、 著者によって意図されたものではありません。 しかし、SHA-256が期待されるセキュリティを提供するかぎり、 SHA-224は、その期待されるレベルのセキュリティを提供します。
| [SHA2] |
Federal Information Processing Standards Publication
(FIPS PUB) 180-2,
Secure Hash Standard, 2002年8月1日. |
| [STDWORDS] |
Bradner, S., 「RFCにおいて要請の程度を示すために用いるキーワード (Key words for use in RFCs to Indicate Requirement Levels)」, BCP 14, RFC 2119, 1997年3月. |
| [3DES] |
American National Standards Institute. ANSI X9.52-1998, Triple Data Encryption Algorithm Modes of Operation. 1998年. |
| [CMS] |
Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852(English), 2004年7月. |
| [NISTGUIDE] |
National Institute of Standards and Technology. Second Draft: "Key Management Guideline, Part 1: General Guidance." 2002年6月. [http://csrc.nist.gov/encryption/kms/guideline-1.pdf] |
| [X.208-88] |
CCITT Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1). 1988年. |
| [X.209-88] |
CCITT Recommendation X.209: Specification of Basic
Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988年. |
テストベクトルを作成してくださったJim Schaad 氏に多謝。 Brian Gladman氏による2番目の実装は、 「テストベクトルが正しいこと」を確認するために使われました。
Russell Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
USA
EMail： housley＠vigilsec.com
宮川 寧夫
独立行政法人 情報処理推進機構
セキュリティセンター
EMail： miyakawa＠ipa.go.jp
Copyright (C) The Internet Society (2004).
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.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE 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.
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.
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.
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.
Funding for the RFC Editor function is currently provided by the Internet Society.