RFC3566 日本語訳

Network Working Group                                         S. Frankel
Request for Comments: 3566                                          NIST
Category: Standards Track                                     H. Herbert
                                                                   Intel
                                                          September 2003

コメントを求めるワーキンググループS.フランケル要求をネットワークでつないでください: 3566年のNISTカテゴリ: 標準化過程H.ハーバートインテル2003年9月

          The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec

AES-XCBC-MAC-96アルゴリズムとIPsecとのその使用

Status of this Memo

この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 (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 All rights reserved。

Abstract

要約

   A Message Authentication Code (MAC) is a key-dependent one way hash
   function.  One popular way to construct a MAC algorithm is to use a
   block cipher in conjunction with the Cipher-Block-Chaining (CBC) mode
   of operation.  The classic CBC-MAC algorithm, while secure for
   messages of a pre-selected fixed length, has been shown to be
   insecure across messages of varying lengths such as the type found in
   typical IP datagrams.  This memo specifies the use of AES in CBC mode
   with a set of extensions to overcome this limitation.  This new
   algorithm is named AES-XCBC-MAC-96.

メッセージ立証コード(MAC)は主要に依存する一方通行のハッシュ関数です。 MACアルゴリズムを構成する1つのポピュラーな方法はCipherブロック推論(CBC)運転モードに関連してブロック暗号を使用することです。 古典的なCBC-MACアルゴリズムは、典型的なIPデータグラムで見つけられたタイプなどの異なった長さに関するメッセージの向こう側に不安定になるように前選択された固定長に関するメッセージに安全である間、示されています。このメモは、この限界を克服するためにCBCモードにおける1セットの拡大によるAESの使用を指定します。 この新しいアルゴリズムはAES-XCBC-MAC-96と命名されます。

Table of Contents

目次

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Specification of Requirements  . . . . . . . . . . . . . .   2
   3.  Basic CBC-MAC with Obligatory 10* Padding  . . . . . . . .   3
   4.  AES-XCBC-MAC-96  . . . . . . . . . . . . . . . . . . . . .   3
       4.1.  Keying Material. . . . . . . . . . . . . . . . . . .   5
       4.2.  Padding  . . . . . . . . . . . . . . . . . . . . . .   6
       4.3.  Truncation . . . . . . . . . . . . . . . . . . . . .   6
       4.4.  Interaction with the ESP Cipher Mechanism. . . . . .   6
       4.5.  Performance. . . . . . . . . . . . . . . . . . . . .   6
       4.6.  Test Vectors . . . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations  . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . .   8
   7.  Intellectual Property Rights Statement . . . . . . . . . .   8

1. 序論. . . . . . . . . . . . . . . . . . . . . . . 2 2。 要件. . . . . . . . . . . . . . 2 3の仕様。 義務的な10*詰め物. . . . . . . . 3 4がある基本的なCBC-MAC。 AES-XCBC Mac96.34.1。 材料を合わせます。 . . . . . . . . . . . . . . . . . . 5 4.2. .64.3を水増しします。 トランケーション. . . . . . . . . . . . . . . . . . . . . 6 4.4。 超能力暗号メカニズムとの相互作用。 . . . . . 6 4.5. パフォーマンス。 . . . . . . . . . . . . . . . . . . . . 6 4.6. ベクトル. . . . . . . . . . . . . . . . . . . . 7 5をテストしてください。 セキュリティ問題. . . . . . . . . . . . . . . . . 8 6。 IANA問題. . . . . . . . . . . . . . . . . . . 8 7。 知的所有権声明. . . . . . . . . . 8

Frankel & Herbert           Standards Track                     [Page 1]

RFC 3566               AES-XCBC-MAC-96 Algorithm          September 2003

フランケルとハーバートStandardsはAES-XCBC-MAC-96アルゴリズム2003年9月にRFC3566を追跡します[1ページ]。

   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . .   8
   9.  References . . . . . . . . . . . . . . . . . . . . . . . .   9
       9.1.  Normative References . . . . . . . . . . . . . . . .   9
       9.2.  Informative References . . . . . . . . . . . . . . .   9
   10. Authors' Addresses . . . . . . . . . . . . . . . . . . . .  10
   11. Full Copyright Statement . . . . . . . . . . . . . . . . .  11

8. 承認. . . . . . . . . . . . . . . . . . . . . 8 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . 9 9.1。 引用規格. . . . . . . . . . . . . . . . 9 9.2。 有益な参照. . . . . . . . . . . . . . . 9 10。 作者のアドレス. . . . . . . . . . . . . . . . . . . . 10 11。 完全な著作権宣言文. . . . . . . . . . . . . . . . . 11

1.  Introduction

1. 序論

   Message authentication provides data integrity and data origin
   authentication with respect to the original message source.  A
   Message Authentication Code (MAC) is a key-dependent one way hash
   function.  One popular way to construct a MAC algorithm is to use a
   block cipher in conjunction with the Cipher-Block-Chaining (CBC) mode
   of operation.  The classic CBC-MAC algorithm, while secure for
   messages of a pre-selected fixed length [CBC-MAC-2], has been shown
   to be insecure across messages of varying lengths such as the type
   found in typical IP datagrams [CBC-MAC-2, section 5].  In fact, it is
   trivial to produce forgeries for a second message given the MAC of a
   prior message.  [HANDBOOK, section 9.62, p. 354]

通報認証は元のメッセージ源に関して起源認証をデータ保全とデータに提供します。 メッセージ立証コード(MAC)は主要に依存する一方通行のハッシュ関数です。 MACアルゴリズムを構成する1つのポピュラーな方法はCipherブロック推論(CBC)運転モードに関連してブロック暗号を使用することです。 古典的なCBC-MACアルゴリズムは、典型的なIPデータグラム[CBC-MAC-2、セクション5]で見つけられたタイプなどの異なった長さに関するメッセージの向こう側に不安定になるように前選択された固定長[CBC-MAC-2]に関するメッセージに安全である間、示されています。 事実上、先のメッセージのMACを考えて、2番目のメッセージのための偽造を起こすのは些細です。 [HANDBOOK、セクション9.62、p。 354]

   This memo specifies the use of AES [AES] in CBC mode [MODES] with a
   set of extensions [XCBC-MAC-1] to overcome this limitation.  This new
   algorithm is named AES-XCBC-MAC-96.  Using the AES block cipher, with
   its increased block size (128 bits) and increased key length (128
   bits), provides the new algorithm with the ability to withstand
   continuing advances in crypto-analytic techniques and computational
   capability.  AES-XCBC-MAC-96 is used as an authentication mechanism
   within the context of the IPsec Encapsulating Security Payload (ESP)
   and the Authentication Header (AH) protocols.  For further
   information on ESP, refer to [ESP] and [ROADMAP].  For further
   information on AH, refer to [AH] and [ROADMAP].

このメモは、この限界を克服するためにCBCモード[MODES]における1セットの拡大[XCBC-MAC-1]によるAES[AES]の使用を指定します。 この新しいアルゴリズムはAES-XCBC-MAC-96と命名されます。 AESブロック暗号を使用すると、暗号分析的なテクニックとコンピュータの能力における継続する進歩に耐える能力はその増加するブロック・サイズ(128ビット)と増加するキー長(128ビット)と共に新しいアルゴリズムに提供されます。 AES-XCBC-MAC-96は認証機構としてIPsec Encapsulating Security有効搭載量(超能力)とAuthentication Header(AH)プロトコルの文脈の中で使用されます。 超能力に関する詳細について、[超能力]と[ROADMAP]を参照してください。 AHに関する詳細について、[AH]と[ROADMAP]を参照してください。

   The goal of AES-XCBC-MAC-96 is to ensure that the datagram is
   authentic and cannot be modified in transit.  Data integrity and data
   origin authentication as provided by AES-XCBC-MAC-96 are dependent
   upon the scope of the distribution of the secret key.  If the key is
   known only by the source and destination, this algorithm will provide
   both data origin authentication and data integrity for datagrams sent
   between the two parties.  In addition, only a party with the
   identical key can verify the hash.

AES-XCBC-MAC-96の目標はデータグラムを正統であり、トランジットで変更できないのを保証することです。 データの保全とAES-XCBC-MAC-96によって提供されるデータ起源認証は秘密鍵の分配の範囲に依存しています。 キーが単に情報筋と目的地によって知られていると、このアルゴリズムはデータ起源認証とデータ保全の両方を2回のパーティーの間に送られたデータグラムに供給するでしょう。 さらに、同じキーがあるパーティーだけが細切れ肉料理について確かめることができます。

2.  Specification of Requirements

2. 要件の仕様

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" that
   appear in this document are to be interpreted as described in BCP 14,
   RFC 2119 [RFC-2119].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「」 「5月」、「任意」は「推薦され」て、現れるBCP14RFC2119[RFC-2119]で説明されるように本書では解釈することであるべきではありません。

Frankel & Herbert           Standards Track                     [Page 2]

RFC 3566               AES-XCBC-MAC-96 Algorithm          September 2003

フランケルとハーバートStandardsはAES-XCBC-MAC-96アルゴリズム2003年9月にRFC3566を追跡します[2ページ]。

3.  Basic CBC-MAC with Obligatory 10* Padding

3. 義務的な10*詰め物がある基本的なCBC-MAC

   CBC-MAC uses a block cipher for encryption; the block cipher
   transforms b bits of plaintext to b bits of ciphertext.  The basic
   CBC-MAC [CBC-MAC-1, CBC-MAC-2] with Obligatory 10* Padding over a
   b-bit block cipher is calculated as follows for a message M:

CBC-MACは暗号化にブロック暗号を使用します。 ブロック暗号はbビットの平文を暗号文のbビットに変えます。 Obligatory10*がb-ビットの上ブロック暗号を水増ししている基本的なCBC-MAC[CBC-MAC-1、CBC-MAC-2]はメッセージMのために以下の通り計算されます:

   (1)  Append a single 1 bit to M.  Then append the minimum number of 0
        bits to M such that the length of M is a multiple of b.
        [NOTE: This is 1 of several padding schemes that can be used for
        CBC-MAC.  Several others are described in [MODES].]

(1) M.に1 1ビット添えてください。Thenが最低0ビットの数をMに追加するので、Mの長さはbの倍数です。 [以下に注意してください。 これはCBC-MACに使用できるいくつかの詰め物計画の1つです。 数人の他のものが[MODES]で説明されます。]

   (2)  Break M into n blocks, M[1] ... M[n], where the blocksize of
        blocks M[1] ... M[n] is b bits

(2) nブロック、M[1]への中断M… M[n]、どこ、blocksizeするか、M[1]…を妨げます。 M[n]はbビットです。

   (3)  Define E[0] = 0x00000000000000000000000000000000

(3) E[0]=0x00000000000000000000000000000000を定義してください。

   (4)  For each block M[i], where i = 1 ... n:
        XOR M[i] with E[i-1], then encrypt the result with Key K,
        yielding E[i].

(4) それぞれに関して、M[i]を妨げてください:(そこでは、iが1…nと等しいです)。 E[i-1]がある次に、Key Kと共に結果をコード化して、E[i]をもたらすXOR M[i]。

   (5)  E[n] is the b-bit authenticator.

(5) E[n]はb-ビット固有識別文字です。

   Basic CBC-MAC with obligatory 10* padding has been shown to be secure
   for messages up to (but not including) a pre-selected fixed length,
   in which the length is a multiple of the blocksize.  This algorithm
   is not suitable for IPsec for the following reasons:

義務的な10*詰め物がある基本的なCBC-MACはメッセージに(しかし、包含しない)前選択された固定長まで安全になるように見せられました、長さがどれの倍数であるかにblocksize このアルゴリズムは以下の理由でIPsecに適当ではありません:

   +    Any IPsec authenticator must be able to handle messages of
        arbitrary length.  However, the basic CBC-MAC cannot securely
        handle messages that exceed the pre-selected fixed length.

+ どんなIPsec固有識別文字も任意の長さに関するメッセージを扱うことができなければなりません。 しかしながら、基本的なCBC-MACはしっかりと前選択された固定長を超えているメッセージを扱うことができません。

   +    For messages shorter than the pre-selected fixed length, padding
        the message to the pre-selected fixed length may necessitate
        additional encryption operations, adding an unacceptable
        computational penalty.

前選択された固定長より短いメッセージのための+、前選択された固定長にメッセージを水増しすると、追加暗号化操作は必要とするかもしれません、容認できないコンピュータの刑罰を加えて。

4.  AES-XCBC-MAC-96

4. AES-XCBC Mac96

   [AES] describes the underlying AES algorithm, while [CBC-MAC-1] and
   [XCBC-MAC-1] describe the AES-XCBC-MAC algorithm.

[AES]は基本的なAESアルゴリズムを説明しますが、[CBC-MAC-1]と[XCBC-MAC-1]はAES-XCBC-MACアルゴリズムを説明します。

   The AES-XCBC-MAC-96 algorithm is a variant of the basic CBC-MAC with
   obligatory 10* padding; however, AES-XCBC-MAC-96 is secure for
   messages of arbitrary length.  The AES-XCBC-MAC-96 calculations
   require numerous encryption operations; this encryption MUST be
   accomplished using AES with a 128-bit key.  Given a 128-bit secret
   key K, AES-XCBC-MAC-96 is calculated as follows for a message M that

AES-XCBC-MAC-96アルゴリズムは義務的な10*詰め物がある基本的なCBC-MACの異形です。 しかしながら、任意の長さに関するメッセージに、AES-XCBC-MAC-96は安全です。 AES-XCBC-MAC-96計算は頻繁な暗号化操作を必要とします。 128ビットのキーがあるAESを使用して、この暗号化を実行しなければなりません。 128ビットの秘密鍵Kを考えて、AES-XCBC-MAC-96がメッセージMのために以下の通り計算される、それ

Frankel & Herbert           Standards Track                     [Page 3]

RFC 3566               AES-XCBC-MAC-96 Algorithm          September 2003

フランケルとハーバートStandardsはAES-XCBC-MAC-96アルゴリズム2003年9月にRFC3566を追跡します[3ページ]。

   consists of n blocks, M[1] ... M[n], in which the blocksize of blocks
   M[1] ... M[n-1] is 128 bits and the blocksize of block M[n] is
   between 1 and 128 bits:

nブロック、M[1]から成ります… M[n]、コネ、どれ、blocksizeするか、M[1]…を妨げます。 そして、M[n-1]が128ビットである、blocksizeする、ブロックMでは、[n]が1〜128ビットです:

   (1)  Derive 3 128-bit keys (K1, K2 and K3) from the 128-bit secret
        key K, as follows:
        K1 = 0x01010101010101010101010101010101 encrypted with Key K
        K2 = 0x02020202020202020202020202020202 encrypted with Key K
        K3 = 0x03030303030303030303030303030303 encrypted with Key K

(1) 以下の通り、128ビットの秘密鍵Kから3個の128ビットのキー(K1、ケーツーとK3)を引き出してください: K1=0x01010101010101010101010101010101はKey Kと共にKey Kと共にコード化されたKey K K3=0x03030303030303030303030303030303でコード化されたケーツー=0x02020202020202020202020202020202をコード化しました。

   (2)  Define E[0] = 0x00000000000000000000000000000000

(2) E[0]=0x00000000000000000000000000000000を定義してください。

   (3)  For each block M[i], where i = 1 ... n-1:
        XOR M[i] with E[i-1], then encrypt the result with Key K1,
        yielding E[i].

(3) それぞれに関して、M[i]を妨げてください:(そこでは、iが1…n-1と等しいです)。 E[i-1]がある次に、Key K1と共に結果をコード化して、E[i]をもたらすXOR M[i]。

   (4)  For block M[n]:

(4)、M[n]を妨げてください:

      a)  If the blocksize of M[n] is 128 bits:
          XOR M[n] with E[n-1] and Key K2, then encrypt the result with
          Key K1, yielding E[n].

a) blocksizeする、Mでは、[n]は128ビットです: E[n-1]とKeyケーツーがある次に、Key K1と共に結果をコード化して、E[n]をもたらすXOR M[n]。

      b)  If the blocksize of M[n] is less than 128 bits:

b) blocksizeする、Mでは、[n]は128ビット未満です:

         i)  Pad M[n] with a single "1" bit, followed by the number of
             "0" bits (possibly none) required to increase M[n]'s
             blocksize to 128 bits.

i) 「1インチのビット、続かれて、「のビットのM[n]を増加させるのに必要な0インチのもの(ことによるとなにも)数は128ビットにblocksizeすること」で単一のM[n]を水増ししてください。

         ii) XOR M[n] with E[n-1] and Key K3, then encrypt the result
             with Key K1, yielding E[n].

ii) E[n-1]とKey K3がある次に、Key K1と共に結果をコード化して、E[n]をもたらすXOR M[n]。

   (5)  The authenticator value is the leftmost 96 bits of the 128-bit
        E[n].

(5) 固有識別文字値は128ビットのE[n]の一番左96ビットです。

   NOTE1: If M is the empty string, pad and encrypt as in (4)(b) to
   create M[1] and E[1].  This will never be the case for ESP or AH, but
   is included for completeness sake.

NOTE1: Mが空のストリングであるなら、同じくらい中で(4)(b)を水増しして、コード化して、M[1]とE[1]を作成してください。 これは、超能力かAHのための決してケースではありませんが、完全性目的のために含まれています。

   NOTE2: [CBC-MAC-1] defines K1 as follows:
                  K1 = Constant1A encrypted with Key K |
                     Constant1B encrypted with Key K.

NOTE2: [CBC-MAC-1]は以下のK1を定義します: K1はKey Kと共にコード化されたConstant1Aと等しいです。| Constant1BはKeyと共にKをコード化しました。

          However, the second encryption operation is only needed for
          AES-XCBC-MAC with keys greater than 128 bits; thus, it is not
          included in the definition of AES-XCBC-MAC-96.

しかしながら、2番目の暗号化操作が128ビット以上のキーでAES-XCBC-MACに必要であるだけです。 したがって、それはAES-XCBC-MAC-96の定義に含まれていません。

Frankel & Herbert           Standards Track                     [Page 4]

RFC 3566               AES-XCBC-MAC-96 Algorithm          September 2003

フランケルとハーバートStandardsはAES-XCBC-MAC-96アルゴリズム2003年9月にRFC3566を追跡します[4ページ]。

   AES-XCBC-MAC-96 verification is performed as follows:
          Upon receipt of the AES-XCBC-MAC-96 authenticator, the entire
          128-bit value is computed and the first 96 bits are compared to
          the value stored in the authenticator field.

AES-XCBC-MAC-96検証は以下の通り実行されます: AES-XCBC-MAC-96固有識別文字を受け取り次第、全体の128ビットの値は計算されます、そして、最初の96ビットは固有識別文字分野に格納された値にたとえられます。

4.1.  Keying Material

4.1. 材料を合わせます。

   AES-XCBC-MAC-96 is a secret key algorithm.  For use with either ESP or
   AH a fixed key length of 128-bits MUST be supported.  Key lengths
   other than 128-bits MUST NOT be supported (i.e., only 128-bit keys are
   to be used by AES-XCBC-MAC-96).

AES-XCBC-MAC-96は秘密鍵アルゴリズムです。 超能力かAHのどちらかとの使用において、128ビットの固定キー長を支持しなければなりません。 128ビット以外のキー長を支持してはいけません(すなわち、128ビットのキーだけがAES-XCBC-MAC-96によって使用されることになっています)。

   AES-XCBC-MAC-96 actually requires 384 bits of keying material (128
   bits for the AES keysize + 2 times the blocksize).  This keying
   material can either be provided through the key generation mechanism
   or it can be generated from a single 128-bit key.  The latter approach
   has been selected for AES-XCBC-MAC-96, since it is analogous to other
   authenticators used within IPsec.  The reason AES-XCBC-MAC-96 uses 3
   keys is so the length of the input stream does not need to be known
   in advance.  This may be useful for systems that do one-pass assembly
   of large packets.

AES-XCBC-MAC-96が実際に合わせることの材料の384個のかけらを必要とする、(AES keysize+2倍で128ビット、blocksizeする、) キー生成メカニズムを通してこの合わせることの材料を供給できますか、または単一の128ビットのキーからそれを発生させることができます。 それがIPsecの中で使用された他の固有識別文字に類似しているので、後者のアプローチはAES-XCBC-MAC-96のために選択されました。 あらかじめ入力ストリームの長さが知られている必要はなくて、AES-XCBC-MAC-96が3個のキーを使用する理由はそうです。 これは大きいパケットの1パスのアセンブリをするシステムの役に立つかもしれません。

   A strong pseudo-random function MUST be used to generate the required
   128-bit key.  This key, along with the 3 derived keys (K1, K2 and K3),
   should be used for no purposes other than those specified in the
   algorithm.  In particular, they should not be used as keys in another
   cryptographic setting.  Such abuses will invalidate the security of
   the authentication algorithm.

必要な128ビットのキーを発生させるのに強い擬似ランダム機能を使用しなければなりません。 アルゴリズムで指定されたもの以外のどんな目的にも3個の派生しているキー(K1、ケーツーとK3)と共にこのキーを使用するべきではありません。 特に、キーとして別の暗号の設定でそれらを使用するべきではありません。 そのような乱用は認証アルゴリズムのセキュリティを無効にするでしょう。

   At the time of this writing there are no specified weak keys for use
   with AES-XCBC-MAC-96.  This does not mean to imply that weak keys do
   not exist.  If, at some point, a set of weak keys for AES-XCBC-MAC-96
   are identified, the use of these weak keys MUST be rejected followed
   by a request for replacement keys or a newly negotiated Security
   Association.

この書くこと時点で、AES-XCBC-MAC-96との使用のためのどんな指定された弱いキーもありません。 これは、弱いキーが存在しないのを含意することを意味しません。 1セットのAES-XCBC-MAC-96に、弱いキーが何らかのポイントで特定されるなら、交換キーか新たに交渉されたSecurity Associationを求める要求があとに続いていて、これらの弱いキーの使用を拒絶しなければなりません。

   [ARCH] describes the general mechanism for obtaining keying material
   when multiple keys are required for a single SA (e.g., when an ESP SA
   requires a key for confidentiality and a key for authentication).

[ARCH]は、入手のために複数のキーが独身のSAに必要であるときに(例えば、ESP SAはいつ秘密性のためのキーと認証のためのキーを必要としますか)、材料を合わせながら、一般的機構について説明します。

   In order to provide data origin authentication, the key distribution
   mechanism must ensure that unique keys are allocated and that they
   are distributed only to the parties participating in the
   communication.

データ起源認証を提供するために、主要な分配メカニズムは、ユニークキーを割り当てて、コミュニケーションに参加するパーティーだけにそれらを分配するのを確実にしなければなりません。

Frankel & Herbert           Standards Track                     [Page 5]

RFC 3566               AES-XCBC-MAC-96 Algorithm          September 2003

フランケルとハーバートStandardsはAES-XCBC-MAC-96アルゴリズム2003年9月にRFC3566を追跡します[5ページ]。

   Current attacks do not necessitate a specific recommended frequency
   for key changes.  However, periodic key refreshment is a fundamental
   security practice that helps against potential weaknesses of the
   function and the keys, reduces the information available to a
   cryptanalyst, and limits the damage resulting from a compromised key.

現在の攻撃はキーチェンジのための特定のお勧めの頻度を必要としません。 しかしながら、周期的な主要な軽い飲食物は、機能とキーの潜在的弱点に対して助ける根本的なセキュリティ実践であり、暗号解読者にとって、利用可能な情報を減らして、妥協しているキーから生じる損害を制限します。

4.2.  Padding

4.2. 詰め物

   AES-XCBC-MAC-96 operates on 128-bit blocks of data.  Padding
   requirements are specified in [CBC-MAC-1] and are part of the XCBC
   algorithm.  If you build AES-XCBC-MAC-96 according to [CBC-MAC-1] you
   do not need to add any additional padding as far as AES-XCBC-MAC-96
   is concerned.  With regard to "implicit packet padding" as defined in
   [AH], no implicit packet padding is required.

AES-XCBC-MAC-96は128ビットのブロックのデータを作動させます。 詰め物要件は、[CBC-MAC-1]で指定されて、XCBCアルゴリズムの一部です。 [CBC-MAC-1]に従ってAES-XCBC-MAC-96を造るなら、AES-XCBC-MAC-96に関する限り、あなたはどんな追加詰め物も加える必要はありません。 [AH]で定義される「暗黙のパケット詰め物」に関して、どんな暗黙のパケット詰め物も必要ではありません。

4.3.  Truncation

4.3. トランケーション

   AES-XCBC-MAC produces a 128-bit authenticator value.  AES-XCBC-MAC-96
   is derived by truncating this 128-bit value as described in [HMAC]
   and verified in [XCBC-MAC-2].  For use with either ESP or AH, a
   truncated value using the first 96 bits MUST be supported.  Upon
   sending, the truncated value is stored within the authenticator
   field.  Upon receipt, the entire 128-bit value is computed and the
   first 96 bits are compared to the value stored in the authenticator
   field.  No other authenticator value lengths are supported by
   AES-XCBC-MAC-96.

AES-XCBC-MACは128ビットの固有識別文字値を生産します。 AES-XCBC-MAC-96は、[HMAC]で説明されて、[XCBC-MAC-2]で確かめられるようにこの128ビットの値に先端を切らせることによって、引き出されます。 超能力かAHのどちらかとの使用において、最初の96ビットを使用する端が欠けている値を支持しなければなりません。 発信のときに、端が欠けている値は固有識別文字分野の中に格納されます。 領収書では、全体の128ビットの値は計算されます、そして、最初の96ビットは固有識別文字分野に格納された値と比較されます。 他の固有識別文字値の長さは全くAES-XCBC-MAC-96によって支持されません。

   The length of 96 bits was selected because it is the default
   authenticator length as specified in [AH] and meets the security
   requirements described in [XCBC-MAC-2].

96ビットの長さは、それが指定されるとして[AH]のデフォルト固有識別文字の長さであるので選択されて、[XCBC-MAC-2]で説明されたセキュリティ必要条件を満たします。

4.4.  Interaction with the ESP Cipher Mechanism

4.4. 超能力暗号メカニズムとの相互作用

   As of this writing, there are no known issues which preclude the use
   of AES-XCBC-MAC-96 with any specific cipher algorithm.

この書くこと現在、どんな特定の暗号アルゴリズムがあるAES-XCBC-MAC-96の使用も排除する問題が知られていません。

4.5.  Performance

4.5. パフォーマンス

   For any CBC MAC variant, the major computational effort is expended
   in computing the underlying block cipher.  This algorithm uses a
   minimum number of AES invocations, one for each block of the message
   or fraction thereof, resulting in performance equivalent to classic
   CBC-MAC.

どんなCBC MAC異形に関してはも、主要な計算量は基本的なブロック暗号を計算する際に費やされます。 このアルゴリズムは最小の数のAES実施を使用します、それのメッセージか断片の各ブロック単位の1つ、古典的なCBC-MACに同等な性能をもたらして。

   The key expansion requires 3 additional AES encryption operations,
   but these can be performed once in advance for each secret key.

主要な拡大は3つの追加AES暗号化操作を必要としますが、あらかじめ、各秘密鍵のために一度これらを実行できます。

Frankel & Herbert           Standards Track                     [Page 6]

RFC 3566               AES-XCBC-MAC-96 Algorithm          September 2003

フランケルとハーバートStandardsはAES-XCBC-MAC-96アルゴリズム2003年9月にRFC3566を追跡します[6ページ]。

4.6.  Test Vectors

4.6. テストベクトル

   These test cases were provided by John Black, co-author of the
   XCBC-MAC algorithm, who verified them with 2 independent
   implementations.  All values are hexadecimal numbers.

これらのテストケースはジョンBlack、XCBC-MACアルゴリズムの共著者によって提供されました。(その共著者は、2つの独立している実現でそれらについて確かめました)。 すべての値が16進数です。

   Test Case #1   : AES-XCBC-MAC-96 with 0-byte input
   Key (K)        : 000102030405060708090a0b0c0d0e0f
   Message (M)    : <empty string>
   AES-XCBC-MAC   : 75f0251d528ac01c4573dfd584d79f29
   AES-XCBC-MAC-96: 75f0251d528ac01c4573dfd5

テストケース#1: 0バイトがあるAES-XCBC-MAC-96はKey(K)を入力しました: 000102030405060708090a0b0c0d0e0fメッセージ(M): <の空のストリング>AES-XCBC-MAC: 75f0251d528ac01c4573dfd584d79f29 AES-XCBC-MAC-96: 75f0251d528ac01c4573dfd5

   Test Case #2   : AES-XCBC-MAC-96 with 3-byte input
   Key (K)        : 000102030405060708090a0b0c0d0e0f
   Message (M)    : 000102
   AES-XCBC-MAC   : 5b376580ae2f19afe7219ceef172756f
   AES-XCBC-MAC-96: 5b376580ae2f19afe7219cee

テストケース#2: 3バイトがあるAES-XCBC-MAC-96はKey(K)を入力しました: 000102030405060708090a0b0c0d0e0fメッセージ(M): 000102のAES-XCBC-Mac: 5b376580ae2f19afe7219ceef172756f AES-XCBC-MAC-96: 5b376580ae2f19afe7219cee

   Test Case #3   : AES-XCBC-MAC-96 with 16-byte input
   Key (K)        : 000102030405060708090a0b0c0d0e0f
   Message (M)    : 000102030405060708090a0b0c0d0e0f
   AES-XCBC-MAC   : d2a246fa349b68a79998a4394ff7a263
   AES-XCBC-MAC-96: d2a246fa349b68a79998a439

テストケース#3: 16バイトがあるAES-XCBC-MAC-96はKey(K)を入力しました: 000102030405060708090a0b0c0d0e0fメッセージ(M): 000102030405060708090a0b0c0d0e0f AES-XCBC-MAC: d2a246fa349b68a79998a4394ff7a263 AES-XCBC-MAC-96: d2a246fa349b68a79998a439

   Test Case #4   : AES-XCBC-MAC-96 with 20-byte input
   Key (K)        : 000102030405060708090a0b0c0d0e0f
   Message (M)    : 000102030405060708090a0b0c0d0e0f10111213
   AES-XCBC-MAC   : 47f51b4564966215b8985c63055ed308
   AES-XCBC-MAC-96: 47f51b4564966215b8985c63

テストケース#4: 20バイトがあるAES-XCBC-MAC-96はKey(K)を入力しました: 000102030405060708090a0b0c0d0e0fメッセージ(M): 000102030405060708090a0b0c0d0e0f10111213 AES-XCBC-MAC: 47f51b4564966215b8985c63055ed308 AES-XCBC-MAC-96: 47f51b4564966215b8985c63

   Test Case #5   : AES-XCBC-MAC-96 with 32-byte input
   Key (K)        : 000102030405060708090a0b0c0d0e0f
   Message (M)    : 000102030405060708090a0b0c0d0e0f10111213141516171819
                    1a1b1c1d1e1f
   AES-XCBC-MAC   : f54f0ec8d2b9f3d36807734bd5283fd4
   AES-XCBC-MAC-96: f54f0ec8d2b9f3d36807734b

テストケース#5: 32バイトがあるAES-XCBC-MAC-96はKey(K)を入力しました: 000102030405060708090a0b0c0d0e0fメッセージ(M): 000102030405060708090a0b0c0d0e0f10111213141516171819 1a1b1c1d1e1f AES-XCBC-MAC: f54f0ec8d2b9f3d36807734bd5283fd4 AES-XCBC-MAC-96: f54f0ec8d2b9f3d36807734b

   Test Case #6   : AES-XCBC-MAC-96 with 34-byte input
   Key (K)        : 000102030405060708090a0b0c0d0e0f
   Message (M)    : 000102030405060708090a0b0c0d0e0f10111213141516171819
                    1a1b1c1d1e1f2021
   AES-XCBC-MAC   : becbb3bccdb518a30677d5481fb6b4d8
   AES-XCBC-MAC-96: becbb3bccdb518a30677d548

テストケース#6: 34バイトがあるAES-XCBC-MAC-96はKey(K)を入力しました: 000102030405060708090a0b0c0d0e0fメッセージ(M): 000102030405060708090a0b0c0d0e0f10111213141516171819 1a1b1c1d1e1f2021 AES-XCBC-MAC: becbb3bccdb518a30677d5481fb6b4d8 AES-XCBC-MAC-96: becbb3bccdb518a30677d548

   Test Case #7   : AES-XCBC-MAC-96 with 1000-byte input
   Key (K)        : 000102030405060708090a0b0c0d0e0f
   Message (M)    : 00000000000000000000 ... 00000000000000000000
                    [1000 bytes]

テストケース#7: 1000バイトがあるAES-XCBC-MAC-96はKey(K)を入力しました: 000102030405060708090a0b0c0d0e0fメッセージ(M): 00000000000000000000 ... 00000000000000000000 [1000バイト]

Frankel & Herbert           Standards Track                     [Page 7]

RFC 3566               AES-XCBC-MAC-96 Algorithm          September 2003

フランケルとハーバートStandardsはAES-XCBC-MAC-96アルゴリズム2003年9月にRFC3566を追跡します[7ページ]。

   AES-XCBC-MAC   : f0dafee895db30253761103b5d84528f
   AES-XCBC-MAC-96: f0dafee895db30253761103b

AES-XCBC-Mac: f0dafee895db30253761103b5d84528f AES-XCBC-MAC-96: f0dafee895db30253761103b

5.  Security Considerations

5. セキュリティ問題

   The security provided by AES-XCBC-MAC-96 is based upon the strength
   of AES.  At the time of this writing there are no practical
   cryptographic attacks against AES or AES-XCBC-MAC-96.

AES-XCBC-MAC-96によって提供されたセキュリティはAESの強さに基づいています。 この書くこと時点で、どんな実用的な暗号の攻撃もAESかAES-XCBC-MAC-96に反対していません。

   As is true with any cryptographic algorithm, part of its strength
   lies in the correctness of the algorithm implementation, the security
   of the key management mechanism and its implementation, the strength
   of the associated secret key, and upon the correctness of the
   implementation in all of the participating systems.  This document
   contains test vectors to assist in verifying the correctness of
   AES-XCBC-MAC-96 code.

本当に、どんな暗号アルゴリズムでも、そのままで、強さの一部があります。アルゴリズム実装の正当性とかぎ管理メカニズムのセキュリティと実現、関連秘密鍵の強さ、および全部で. このドキュメントが含む参加システムの実現の正当性では、ベクトルをテストして、AES-XCBC-MAC-96コードの正当性について確かめるのを助けてください。

6.  IANA Considerations

6. IANA問題

   IANA has assigned AH Transform Identifier 9 to AH_AES-XCBC-MAC.  IANA
   has assigned AH/ESP Authentication Algorithm Value 9 to AES-XCBC-MAC.

IANAはAH_AES-XCBC-MACにAH Transform Identifier9を割り当てました。 IANAはAH/超能力Authentication Algorithm Value9をAES-XCBC-MACに割り当てました。

7.  Intellectual Property Rights Statement

7. 知的所有権声明

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication 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 Secretariat.

IETFはどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可がimplementersによるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。

8.  Acknowledgments

8. 承認

   Portions of this text were unabashedly borrowed from [HMAC-SHA].

[HMAC-SHA]から本稿の部分を平気で借りました。

   Thanks to the XCBC-MAC authors for their expert advice and rapid
   response to our queries: to Phil Rogaway for providing values for the
   XCBC-MAC constants; and to John Black for detailed corrections to the
   algorithm specifications and for providing the test cases.  Thanks
   also to Andrew Krywaniuk for insisting on (and providing wording for)
   a rationale for the 3-key approach.

私たちの質問への彼らの専門家の助言と迅速な応答をXCBC-MAC作者をありがとうございます: フィルに、提供するためのRogawayはXCBC-MACのために定数を評価します。 そして、アルゴリズム仕様への詳細な修正とテストケースを提供するためのジョンBlackに。 そして、また、アンドリューKrywaniukに主張してくださってありがとうございます、(言葉遣いを提供する、)、3主要近接路のための原理。

Frankel & Herbert           Standards Track                     [Page 8]

RFC 3566               AES-XCBC-MAC-96 Algorithm          September 2003

フランケルとハーバートStandardsはAES-XCBC-MAC-96アルゴリズム2003年9月にRFC3566を追跡します[8ページ]。

9.  References

9. 参照

9.1.  Normative References

9.1. 引用規格

   [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 PUB197、「エー・イー・エス(AES)」11月2001日の http://csrc.nist.gov/publications/fips/fips197/ fips-197。ps、pdf

   [AH]          Kent, S. and R. Atkinson, "IP Authentication Header",
                 RFC 2402, November 1998.

[ああ] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。

   [CBC-MAC-1]   Black, J. and P. Rogaway, "CBC MACs for
                 Arbitrary-Length Messages: The Three-Key
                 Constructions," in M. Bellare, editor, Advances in
                 Cryptology -- CRYPTO '00, volume 1880 of Lecture Notes
                 in Computer Science, p.  0197, August 2000,
                 Springer-Verlag.
                 http://www.cs.ucdavis.edu/~rogaway/papers/3k.ps

[CBC-MAC-1] 黒、J.、およびP.Rogaway、「任意の長さのためのCBC MACsは通信します」。 ConstructionsをThree合わせてください。「」 M.Bellareのエディタ、CryptologyのAdvances--CRYPTO'00、コンピュータScienceの1880ボリュームLecture Notes、p'。 追出石-Verlag0197、2000年8月、 http://www.cs.ucdavis.edu/~rogaway/papers/3k.ps

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

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

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

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

   [XCBC-MAC-1]  Black, J. and P. Rogaway, "A Suggestion for Handling
                 Arbitrary-Length Messages with the CBC MAC," NIST
                 Second Modes of Operation Workshop, August 2001.
                 http://csrc.nist.gov/encryption/modes/proposedmodes/
                 xcbc-mac/xcbc-mac-spec.pdf

[XCBC-MAC-1]は黒くします、Operation WorkshopのJ.とP.Rogaway、「CBC MACがある取り扱い任意の長さのメッセージのための提案」NIST Second Modes、8月2001日の http://csrc.nist.gov/encryption/modes/proposedmodes/ xcbc-mac/xcbc-mac-spec.pdf

9.2.  Informative References

9.2. 有益な参照

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

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

   [CBC-MAC-2]  Bellare, M., J. Kilian and P. Rogaway, "The Security of
                the Cipher Block Chaining Message Authentication Code,"
                Journal of Computer and System Sciences (JCSS), Vol.
                61, No. 3, December 2000, pp. 362-399.
                http://www.cse.ucsd.edu/users/mihir/papers/cbc.{ps,pdf}

[CBC-MAC-2] BellareとM.とJ.キリアンとP.Rogawayと「暗号ブロック連鎖メッセージ立証コードのセキュリティ」とコンピュータのJournalとSystem Sciences(JCSS)、Vol.61、No.3、2000年12月、ページ 362-399 http://www.cse.ucsd.edu/users/mihir/papers/cbc 。ps、pdf

   [HMAC]       Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
                Keyed-Hashing for Message Authentication", RFC 2104,
                February 1997.

[HMAC] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。

Frankel & Herbert           Standards Track                     [Page 9]

RFC 3566               AES-XCBC-MAC-96 Algorithm          September 2003

フランケルとハーバートStandardsはAES-XCBC-MAC-96アルゴリズム2003年9月にRFC3566を追跡します[9ページ]。

   [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日

   [HANDBOOK]   Menezes, A., P. Van Oorschot and S. Vanstone, "Handbook
                of Applied Cryptography", CRC Press, 1997.

[ハンドブック]メネゼス、A.、P.バンOorschot、およびS.Vanstone、「適用された暗号のハンドブック」、CRCプレス、1997。

   [MODES]      Dworkin, M., "Recommendation for Block Cipher Modes of
                Operation: Methods and Techniques," NIST Special
                Publication 800-38A, December 2001.
                http://csrc.nist.gov/publications/nistpubs/800-38a
                /sp800-38a.pdf

[モード]ドーキン、M.、「ブロックのための推薦は運転モードを解きます」。 「方法とテクニック」、NISTの特別な公表800-38A、12月2001日の http://csrc.nist.gov/publications/nistpubs/800-38a /sp800-38a. pdf

   [RFC-2026]   Bradner, S., "The Internet Standards Process -- Revision
                3", BCP 9, RFC 2026, October 1996.

[RFC-2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」

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

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

   [XCBC-MAC-2] Rogaway, Phil, email communications, October 2001.

[XCBC-MAC-2]Rogaway(フィル)は2001年10月にコミュニケーションをメールします。

10.  Authors' Addresses

10. 作者のアドレス

   Sheila Frankel
   NIST - National Institute of Standards and Technology
   820 West Diamond Ave.
   Room 677
   Gaithersburg, MD 20899

シェイラフランケルNIST--米国商務省標準技術局820の西ダイヤモンドAve。 部屋677ゲイザースバーグ(MD)20899

   Phone: +1 (301) 975-3297
   EMail: sheila.frankel@nist.gov

以下に電話をしてください。 +1 (301) 975-3297 メールしてください: sheila.frankel@nist.gov

   Howard C. Herbert
   Intel Corporation
   Lan Access Division
   5000 West Chandler Blvd.
   MS-CH7-404
   Chandler, Arizona 85226

ハワードC.ハーバートインテル社ランアクセス師団5000の西ろうそく屋Blvd. MS-CH7-404ろうそく屋、アリゾナ 85226

   Phone: +1 (480) 554-3116
   EMail: howard.c.herbert@intel.com

以下に電話をしてください。 +1 (480) 554-3116 メールしてください: howard.c.herbert@intel.com

Frankel & Herbert           Standards Track                    [Page 10]

RFC 3566               AES-XCBC-MAC-96 Algorithm          September 2003

フランケルとハーバートStandardsはAES-XCBC-MAC-96アルゴリズム2003年9月にRFC3566を追跡します[10ページ]。

11.  Full Copyright Statement

11. 完全な著作権宣言文

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

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

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

Frankel & Herbert           Standards Track                    [Page 11]

フランケルとハーバート標準化過程[11ページ]