RFC3218 日本語訳

Network Working Group                                        E. Rescorla
Request for Comments: 3218                                    RTFM, Inc.
Category: Informational                                     January 2002

コメントを求めるワーキンググループE.レスコラの要求をネットワークでつないでください: 3218年のRTFM Inc.カテゴリ: 情報の2002年1月

                Preventing the Million Message Attack on
                      Cryptographic Message Syntax

暗号のメッセージ構文に対する100万メッセージ攻撃を防ぎます。

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

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

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

Abstract

要約

   This memo describes a strategy for resisting the Million Message
   Attack.

このメモはMillion Message Attackに抵抗するための戦略を説明します。

Table of Contents

目次

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   1
   2. Overview of PKCS-1  . . . . . . . . . . . . . . . . . . . . .   2
   2.1. The Million Message Attack  . . . . . . . . . . . . . . . .   3
   2.2. Applicability . . . . . . . . . . . . . . . . . . . . . . .   3
   2.2.1. Note on Block Cipher Padding  . . . . . . . . . . . . . .   4
   2.3. Countermeasures . . . . . . . . . . . . . . . . . . . . . .   4
   2.3.1. Careful Checking  . . . . . . . . . . . . . . . . . . . .   4
   2.3.2. Random Filling  . . . . . . . . . . . . . . . . . . . . .   5
   2.3.3. OAEP  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   2.4. Security Considerations . . . . . . . . . . . . . . . . . .   6
   3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   6
   4. References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
   5. Author's Address. . . . . . . . . . . . . . . . . . . . . . .   6
   6. Full Copyright Statement  . . . . . . . . . . . . . . . . . .   7

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 1 2。 PKCS-1. . . . . . . . . . . . . . . . . . . . . 2 2.1の概観。 100万メッセージ攻撃. . . . . . . . . . . . . . . . 3 2.2。 適用性. . . . . . . . . . . . . . . . . . . . . . . 3 2.2.1。 ブロック暗号で詰め物. . . . . . . . . . . . . . 4 2.3に注意してください。 対策. . . . . . . . . . . . . . . . . . . . . . 4 2.3.1。 慎重な照合. . . . . . . . . . . . . . . . . . . . 4 2.3.2。 無作為の充填. . . . . . . . . . . . . . . . . . . . . 5 2.3.3。 OAEP. . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4。 セキュリティ問題. . . . . . . . . . . . . . . . . . 6 3。 承認. . . . . . . . . . . . . . . . . . . . . . . 6 4。 参照. . . . . . . . . . . . . . . . . . . . . . . . . 6 5。 作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . . 6 6. 完全な著作権宣言文. . . . . . . . . . . . . . . . . . 7

1.  Introduction

1. 序論

   When data is encrypted using RSA it must be padded out to the length
   of the modulus -- typically 512 to 2048 bits.  The most popular
   technique for doing this is described in [PKCS-1-v1.5].  However, in
   1998 Bleichenbacher described an adaptive chosen ciphertext attack on
   SSL [MMA].  This attack, called the Million Message Attack, allowed
   the recovery of a single PKCS-1 encrypted block, provided that the

データがRSAを使用することでコード化されているとき、係数の長さにそれを広げなければなりません--通常512〜2048ビット。 これをするための最もポピュラーなテクニックは[PKCS-1-v1.5]で説明されます。 しかしながら、1998年に、Bleichenbacherは適応型の選ばれた暗号文攻撃をSSL[MMA]に説明しました。 Million Message Attackと呼ばれるこの攻撃であり、許容されて、独身のPKCS-1の回復はブロックをコード化しました。

Rescorla                     Informational                      [Page 1]

RFC 3218      Preventing the Million Message Attack on CMS  January 2002

cm2002年1月に100万メッセージ攻撃を防ぐレスコラ情報[1ページ]のRFC3218

   attacker could convince the receiver to act as a particular kind of
   oracle. (An oracle is a program which answers queries based on
   information unavailable to the requester (in this case the private
   key)).  The MMA is also possible against [CMS].  Mail list agents are
   the most likely CMS implementations to be targets for the MMA, since
   mail list agents are automated servers that automatically respond to
   a large number of messages.  This document describes a strategy for
   resisting such attacks.

攻撃者は、特定の種類に関する神託として機能するように受信機に納得させることができました。 (神託はリクエスタ(この場合秘密鍵)を入手できない情報に基づく質問に答えるプログラムです。) また、MMAも[CMS]に対して可能です。 メール・リストエージェントはMMAのための目標である最もありそうなCMS実現です、メール・リストエージェントが自動的に多くのメッセージに反応する自動化されたサーバであるので。 このドキュメントはそのような攻撃に抵抗するための戦略を説明します。

2.  Overview of PKCS-1

2. PKCS-1の概観

   The first stage in RSA encryption is to map the message to be
   encrypted (in CMS a symmetric content-encryption key (CEK)) into an
   integer the same length as (but numerically less than) the RSA
   modulus of the recipient's public key (typically somewhere between
   512 and 2048 bits).  PKCS-1 describes the most common procedure for
   this transformation.

RSA暗号化における第一段階が同じ長さに整数にコード化されるべき(CMSのa左右対称の満足している暗号化キー(CEK)で)メッセージを写像することになっている、(数の上でより少ない、)、受取人の公開鍵(通常512と2048ビットの間のどこか)のRSA係数。 PKCS-1はこの変化のための最も多くの常法を説明します。

   We start with an "encryption block" of the same length as the
   modulus.  The rightmost bytes of the block are set to the message to
   be encrypted.  The first two bytes are a zero byte and a "block type"
   byte.  For encryption the block type is 2.  The remaining bytes are
   used as padding.  The padding is constructed by generating a series
   of non-zero random bytes.  The last padding byte is zero, which
   allows the padding to be distinguished from the message.

私たちは係数と同じ長さの「暗号化ブロック」から始めます。 ブロックの一番右のバイトはコード化されるべきメッセージに設定されます。 最初の2バイトはバイトがなくて「ゴシック体」バイトです。 暗号化のために、ゴシック体は2歳です。 残っているバイトは詰め物として使用されます。 詰め物は、一連の非ゼロの無作為のバイトを発生させることによって、構成されます。 最後の詰め物バイトはゼロです。(そのゼロは、詰め物がメッセージと区別されるのを許容します)。

      +---+---+----------------------+---+---------------------+
      | 0 | 2 | Nonzero random bytes | 0 |      Message        |
      +---+---+----------------------+---+---------------------+

+---+---+----------------------+---+---------------------+ | 0 | 2 | 非零の無作為のバイト| 0 | メッセージ| +---+---+----------------------+---+---------------------+

   Once the block has been formatted, the sender must then convert the
   block into an integer.  This is done by treating the block as an
   integer in big-endian form.  Thus, the resulting number is less than
   the modulus (because the first byte is zero), but within a factor of
   2^16 (because the second byte is 2).

かつてのブロックはフォーマットされて、次に、送付者はブロックを整数に変換しなければなりません。 ビッグエンディアンフォームの整数としてブロックを扱うことによって、これをします。 係数(最初のバイトがゼロであるので)より少ないのですがしたがって2^16の要素の中で(2番目のバイトが2であるので)結果として起こる数。

   In CMS, the message is always a randomly generated symmetric
   content-encryption key (CEK).  Depending on the cipher being used it
   might be anywhere from 8 to 32 bytes.

CMSでは、いつもメッセージは手当たりしだいに発生している左右対称の満足している暗号化キー(CEK)です。 使用される暗号によって、それはどこでも8〜32バイトあるかもしれません。

   There must be at least 8 bytes of non-zero padding.  The padding
   prevents an attacker from verifying guesses about the encrypted
   message.  Imagine that the attacker wishes to determine whether or
   not two RSA-encrypted keys are the same.  Because there are at least
   255^8 (about 2^64) different padding values with high probability two
   encryptions of the same CEK will be different.  The padding also
   prevents the attacker from verifying guessed CEKs by trial-encrypting
   them with the recipient's RSA key since he must try each potential

そっと歩く少なくとも8バイトの非ゼロがあるに違いありません。 詰め物によって、攻撃者は暗号化メッセージに関して推測について確かめることができません。 攻撃者が、2個のRSAによってコード化されたキーが同じであるかどうか決定したがっていると想像してください。 高い確率がある少なくとも255^8つ(およそ2^64)の異なった詰め物値があるので、同じCEKの2つの暗号化が異なるでしょう。 詰め物によって、また、彼が各可能性を試みなければならないので、攻撃者はトライアルをコード化する彼らで受取人のRSAキーで推測されたCEKsについて確かめることができません。

Rescorla                     Informational                      [Page 2]

RFC 3218      Preventing the Million Message Attack on CMS  January 2002

cm2002年1月に100万メッセージ攻撃を防ぐレスコラ情報[2ページ]のRFC3218

   pad for every guess.  Note that a lower cost attack would be to
   exhaustively search the CEK space by trial-decrypting the content and
   examining the plaintext to see if it appears reasonable.

あらゆる推測には、そっと歩いてください。 下側の費用攻撃が内容をトライアルで解読して、それが妥当に見えるかどうか確認するために平文を調べることによってCEKスペースを徹底的に捜すことであることに注意してください。

2.1.  The Million Message Attack

2.1. 100万メッセージ攻撃

   The purpose of the Million Message Attack (MMA) is to recover a
   single plaintext (formatted block) given the ciphertext (encrypted
   block).  The attacker first captures the ciphertext in transit and
   then uses the recipient as an oracle to recover the plaintext by
   sending transformed versions of the ciphertext and observing the
   recipient's response.

Million Message Attack(MMA)の目的は暗号文(コード化されたブロック)を考えて、ただ一つの平文(ブロックをフォーマットする)を回復することです。 発信することによって平文を回復する神託が暗号文と受取人の応答を観測するバージョンを変えたので、攻撃者は、最初に、トランジットにおける暗号文を得て、次に、受取人を使用します。

   Call the ciphertext C. The attacker then generates a series of
   integers S and computes C'=C*(S^e) mod n.  Upon decryption, C'
   produces a corresponding plaintext M'.  Most values of M' will appear
   to be garbage but some values of M' (about one in 2^16) will have the
   correct first two bytes 00 02 and thus appear to be properly PKCS-1
   formatted.  The attack proceeds by finding a sequence of values S
   such that the resulting M' is properly PKCS-1 formatted.  This
   information can be used to discover M. Operationally, this attack
   usually requires about 2^20 messages and responses.  Details can be
   found in [MMA].

'C.に暗号文に電話をしてください。そして攻撃者は、一連の整数Sを発生させて、C*(S^e)C'=モッズnを計算します。 '復号化に、C'は対応する平文Mを生産します'。 ''Mのゴミにもかかわらず、いくつかの値であるように見えること'が(2^16におけるおよそ1)そうするMのほとんどの値が、00 02を適度の最初の2バイト持って、その結果、適切にである見えます。フォーマットされたPKCS-1。 '攻撃は、結果として起こるM'が適切にそうであるようにものを値Sの系列に見つけることによって、フォーマットされたPKCS-1を続かせます。 通常、この攻撃は、2^20のメッセージと応答に関してM.Operationallyを発見するのにこの情報を使用できるのを必要とします。 [MMA]で詳細を見つけることができます。

2.2.  Applicability

2.2. 適用性

   Since the MMA requires so many messages, it must be mounted against a
   victim who is willing to process a large number of messages.  In
   practice, no human is willing to read this many messages and so the
   MMA can only be mounted against an automated victim.

MMAがとても多くのメッセージを必要とするので、多くのメッセージを処理しても構わないと思っている犠牲者に対してそれを取り付けなければなりません。 実際には、どんな人間も、この多くのメッセージを読んでも構わないと思っていないので、自動化された犠牲者に対してMMAを取り付けることができるだけです。

   The MMA also requires that the attacker be able to distinguish cases
   where M' was PKCS-1 formatted from cases where it was not.  In the
   case of CMS the attacker will be sending CMS messages with C'
   replacing the wrapped CEK.  Thus, there are five possibilities:

'また、MMAは、攻撃者がM'がそれがそうでなかったケースからフォーマットされたPKCS-1であったケースを区別できるのを必要とします。 'CMSの場合では、攻撃者はC'が包装されたCEKを取り替えているメッセージをCMSに送るでしょう。 したがって、5つの可能性があります:

   1. M' is improperly formatted.
   2. M' is properly formatted but the CEK is prima facie bogus (wrong
      length, etc.)
   3. M' is properly formatted and the CEK appears OK.  A signature or
      MAC is present so integrity checking fails.
   4. M' is properly formatted and no integrity check is applied.  In
      this case there is some possibility (approximately 1/32) that the
      CBC padding block will verify properly.  (The actual probability
      depends highly on the receiving implementation.  See "Note on
      Block Cipher Padding" below).  The message will appear OK at the
      CMS level but will be bogus at the application level.

1. 'M'は不適切にフォーマットされます。 2. 'M'は適切にフォーマットされますが、CEKは一見したところではにせです(間違った長さなど)。 3. 'M'は適切にフォーマットされます、そして、CEKはOKに見えます。 署名かMACが存在しているので、保全の照合は失敗します。 4. 'M'は適切にフォーマットされます、そして、どんな保全チェックも適用されていません。 この場合、CBC詰め物ブロックが適切に確かめる何らかの可能性(およそ1/32)があります。 (実際の確率は受信実現に非常に依存します。 以下の「ブロック暗号詰め物に関する注」を見てください。). メッセージは、CMSレベルでOKに見えますが、アプリケーションレベルでにせになるでしょう。

Rescorla                     Informational                      [Page 3]

RFC 3218      Preventing the Million Message Attack on CMS  January 2002

cm2002年1月に100万メッセージ攻撃を防ぐレスコラ情報[3ページ]のRFC3218

   5. M' is properly formatted and the resulting CEK is correct.  This
      is extremely improbable but not impossible.

5. 'M'は適切にフォーマットされます、そして、結果として起こるCEKは正しいです。 これは、非常にありそうもないのですが、不可能ではありません。

   The MMA requires the attacker to be able to distinguish case 1 from
   cases 2-4.  (He can always distinguish case 5, of course).  This
   might happen if the victim returned different errors for each case.
   The attacker might also be able to distinguish these cases based on
   timing -- decrypting the message and verifying the signature takes
   some time.  If the victim responds uniformly to all four errors then
   no attack is possible.

MMAは、攻撃者がケース2-4とケース1を区別できるのを必要とします。 (彼がいつもケース5を区別できる、もちろん。) 犠牲者が各ケースのための異なった誤りを返すなら、これは起こるでしょうに。 また、攻撃者はメッセージを解読して、タイミングに基づくこれらのケースを区別できるかもしれません、そして、署名について確かめるのはある程度時間がかかっています。 犠牲者が一様にすべての4つの誤りまで応じるなら、どんな攻撃も可能ではありません。

2.2.1.  Note on Block Cipher Padding

2.2.1. ブロック暗号で詰め物に注意してください。

   [CMS] specifies a particular kind of block cipher padding in which
   the final cipher block is padded with bytes containing the length of
   the padding.  For instance, a 5-byte block would be padded with three
   bytes of value 03, as in:

[CMS]はバイトが詰め物の長さを含んでいて最終的な暗号ブロックが水増しされる特定の種類のブロック暗号詰め物を指定します。 例えば、5バイトのブロックは以下のように価値03の3バイトで水増しされるでしょう。

     XX XX XX XX XX 03 03 03

XX XX XX XX XX03 03 03

   [CMS] does not specify how this padding is to be removed but merely
   observes that it is unambiguous.  An implementation might simply get
   the value of the final byte and truncate appropriately or might
   verify that all the padding bytes are correct.  If the receiver
   simply truncates then the probability that a random block will appear
   to be properly padded is roughly 1/32.  If the receiver checks all
   the padding bytes, then the probability is 1/256 + (1/256^2) + ...
   (roughly 1/255).

[CMS]は、取り除くこの詰め物がことである方法を指定しませんが、それが明白であることを単に観測します。 すべての詰め物バイトが力が単に最終的なバイトの値を得て、適切に先端を切るか、または確かめるかもしれない実現である、正しいです。 受信機がその時無作為のブロックが現れるという確率に単に、先端を切らせるなら、適切にそっと歩くのは、およそ1/32です。 受信機がすべての詰め物バイトをチェックするなら、確率は(1/256^2)1/256++です… (およそ1/255。)

2.3.  Countermeasures

2.3. 対策

2.3.1.  Careful Checking

2.3.1. 慎重な照合

   Even without countermeasures, sufficiently careful checking can go
   quite a long way to mitigating the success of the MMA.  If the
   receiving implementation also checks the length of the CEK and the
   parity bits (if available) AND responds identically to all such
   errors, the chances of a given M' being properly formatted are
   substantially decreased.  This increases the number of probe messages
   required to recover M. However, this sort of checking only increases
   the workfactor and does not eliminate the attack entirely because
   some messages will still be properly formatted up to the point of
   keylength.  However, the combination of all three kinds of checking
   (padding, length, parity bits) increases the number of messages to
   the point where the attack is impractical.

対策がなくても、十分慎重な照合はMMAの成功を緩和するのにかなり長い道のりで行くことができます。 '受信実現がまた、CEKの長さとパリティビット(利用可能であるなら)をチェックして、同様にそのようなすべての誤りに応じるなら、適切にフォーマットされる当然のことM'の可能性はかなり減少します。 これがM.Howeverを回収するのに必要である徹底的調査メッセージの数を増加させて、完全にそれでも、いくつかのメッセージが適切にkeylengthの先までフォーマットされるので、この種類の照合だけが、workfactorを増加させて、攻撃を排除しません。 しかしながら、すべての3種類の照合の組み合わせ(詰め物、長さ、パリティビット)は攻撃が非実用的である肝心のメッセージの数を増加させます。

Rescorla                     Informational                      [Page 4]

RFC 3218      Preventing the Million Message Attack on CMS  January 2002

cm2002年1月に100万メッセージ攻撃を防ぐレスコラ情報[4ページ]のRFC3218

2.3.2.  Random Filling

2.3.2. 無作為の充填

   The simplest countermeasure is to treat misformatted messages as if
   they were properly PKCS-1 formatted.  When the victim detects an
   improperly formatted message, instead of returning an error he
   substitutes a randomly generated message.  In CMS, since the message
   is always a wrapped content-encryption key (CEK) the victim should
   simply substitute a randomly generated CEK of appropriate length and
   continue.  Eventually this will result in a decryption or signature
   verification error but this is exactly what would have happened if M'
   happened to be properly formatted but contained an incorrect CEK.
   Note that this approach also prevents the attacker from
   distinguishing various failure cases via timing since all failures
   return roughly the same timing behavior.  (The time required to
   generate the random-padding is negligible in almost all cases.  If an
   implementation has a very slow PRNG it can generate random padding
   for every message and simply discard it if the CEK decrypts
   correctly).

最も簡単な対策はまるでそれらが適切に通信するかのようにmisformattedされた御馳走へフォーマットされたPKCS-1が通信しているということです。 犠牲者が不適切にフォーマットされたメッセージを検出するとき、誤りを返すことの代わりに、彼は手当たりしだいに発生しているメッセージを代入します。 CMSでは、いつもメッセージが包装された満足している暗号化キー(CEK)であるので、犠牲者は、単に適切な長さの手当たりしだいに発生しているCEKを代入して、続くべきです。 '結局、復号化か署名照合誤りをもたらすでしょうが、これはまさにMであるなら起こったことです'は、たまたま適切にフォーマットされましたが、不正確なCEKを含みました。 また、攻撃者がこのアプローチによってすべての失敗がおよそ同じタイミング行動を返すのでタイミングで様々な失敗事件を区別できないことに注意してください。 (無作為の詰め物を発生させるのに必要である時間はほとんどすべての場合取るにたらないです。 実現に非常に遅いPRNGがあるなら、CEKであるならあらゆるメッセージのための無作為の詰め物を発生させて、単にそれを捨てることができる、正しく解読する。).

   In a layered implementation it's quite possible that the PKCS-1 check
   occurs at a point in the code where the length of the expected CEK is
   not known.  In that case the implementation must ensure that bad
   PKCS-1 padding and ok-looking PKCS-1 padding with an incorrect length
   CEK behave the same.  An easy way to do this is to also randomize
   CEKs that are of the wrong length or otherwise improperly formatted
   when they are processed at the layer that knows the length.

層にされた実現では、PKCS-1チェックがポイントに予想されたCEKの長さが知られていないコードで起こるのは、かなり可能です。 その場合、実現はCEKが同じように振る舞わせる誤長でそっと歩くその悪いPKCS-1詰め物とOK見えるPKCS-1を確実にしなければなりません。 これをする簡単な方法はまた、彼らが層に処理されるとき間違った長さがあるか、または別の方法で不適切にフォーマットされているCEKsをランダマイズするために、それが長さを知っているということです。

   Note: It is a mistake to use a fixed CEK because the attacker could
   then produce a CMS message encrypted with that CEK.  This message
   would decrypt properly (i.e. appear to be a completely valid CMS
   application to the receiver), thus allowing the attacker to determine
   that the PKCS-1 formatting was incorrect.  In fact, the new CEK
   should be cryptographically random, thus preventing the attacker from
   guessing the next "random" CEK to be used.

以下に注意してください。 次に、攻撃者がそのCEKと共にコード化されたCMSメッセージを出すことができたので、固定CEKを使用するのは、誤りです。 攻撃者が、PKCS-1形式が不正確であったと決心しているのをこのメッセージはそうして、適切(すなわち、受信機への完全に有効なCMSアプリケーションであるように見える)に解読して、その結果、許容するでしょう。 事実上、新しいCEKが暗号でそうであるべきである、無作為である、その結果、攻撃者が、次の「無作為」のCEKが使用されると推測するのを防ぎます。

2.3.3.  OAEP

2.3.3. OAEP

   Optimal Asymmetric Encryption Padding (OAEP) [OAEP, PKCS-1-v2] is
   another technique for padding a message into an RSA encryption block.
   Implementations using OAEP are not susceptible to the MMA.  However,
   OAEP is incompatible with PKCS-1.  Implementations of S/MIME and CMS
   must therefore continue to use PKCS-1 for the foreseeable future if
   they wish to communicate with current widely deployed
   implementations.  OAEP is being specified for use with AES keys in
   CMS so this provides an upgrade path to OAEP.

最適のAsymmetric Encryption Padding(OAEP)[OAEP、PKCS-1-v2]は、RSA暗号化ブロックにメッセージを水増しするための別のテクニックです。 OAEPを使用する実現はMMAに影響されやすくはありません。 しかしながら、OAEPはPKCS-1と非互換です。 したがって、彼らが現在の広く配備された実現で交信したいなら、S/MIMEとCMSの実現は、予見できる未来にPKCS-1を使用し続けなければなりません。 AESキーがCMSにある状態でOAEPが使用に指定されているので、これはアップグレード経路をOAEPに供給します。

Rescorla                     Informational                      [Page 5]

RFC 3218      Preventing the Million Message Attack on CMS  January 2002

cm2002年1月に100万メッセージ攻撃を防ぐレスコラ情報[5ページ]のRFC3218

2.4.  Security Considerations

2.4. セキュリティ問題

   This entire document describes how to avoid a certain class of
   attacks when performing PKCS-1 decryption with RSA.

この全体のドキュメントはRSAと共にPKCS-1復号化を実行するとき、あるクラスの攻撃を避ける方法を説明します。

3.  Acknowledgments

3. 承認

   Thanks to Burt Kaliski and Russ Housley for their extensive and
   helpful comments.

彼らの大規模で役立っているコメントをバートKaliskiとラスHousleyをありがとうございます。

4.  References

4. 参照

   [CMS]         Housley, R., "Cryptographic Message Syntax", RFC 2630,
                 June 1999.

[cm] Housley、R.、「暗号のメッセージ構文」、RFC2630、1999年6月。

   [MMA]         Bleichenbacher, D., "Chosen Ciphertext Attacks against
                 Protocols based on RSA Encryption Standard PKCS #1",
                 Advances in Cryptology -- CRYPTO 98.

[MMA]Bleichenbacher、D.、「プロトコルに対する選ばれたCiphertext Attacksは1インチをRSA Encryption Standard PKCS#に基礎づけました、CryptologyのAdvances--CRYPTO98。」

   [MMAUPDATE]   D. Bleichenbacher, B. Kaliski, and J. Staddon, "Recent
                 Results on PKCS #1: RSA Encryption Standard", RSA
                 Laboratories' Bulletin #7, June 26, 1998.

[MMAUPDATE]D.Bleichenbacher、B.Kaliski、およびJ.Staddon、「PKCS#1の最近の結果:」 「RSA暗号化規格、」、1998年6月26日のRSA研究所の報告#7。

   [OAEP]        Bellare, M., Rogaway, P., "Optimal Asymmetric
                 Encryption Padding", Advances in Cryptology --
                 Eurocrypt 94.

M.、Rogaway、P.、「最適の非対称の暗号化詰め物」という[OAEP]Bellareは暗号理論で進みます--Eurocrypt94。

   [PKCS-1-v1.5] Kaliski, B., "PKCS #1: RSA Encryption, Version 1.5.",
                 RFC 2313, March 1998.

[PKCS-1-v1.5]Kaliski、B.、「PKCS#1:」 「RSA暗号化、バージョン1.5」、RFC2313、3月1998日

   [PKCS-1-v2]   Kaliski, B., "PKCS #1: RSA Encryption, Version 2.0",
                 RFC 2347, October 1998.

[PKCS-1-v2]Kaliski、B.、「PKCS#1:」 RSA暗号化、バージョン2インチ、RFC2347、1998年10月。

5.  Author's Address

5. 作者のアドレス

   Eric Rescorla
   RTFM, Inc.
   2064 Edgewood Drive
   Palo Alto, CA 94303

エリックレスコラRTFM Inc.2064Edgewood Driveパロアルト、カリフォルニア 94303

   Phone: (650) 320-8549
   EMail: ekr@rtfm.com

以下に電話をしてください。 (650) 320-8549 メールしてください: ekr@rtfm.com

Rescorla                     Informational                      [Page 6]

RFC 3218      Preventing the Million Message Attack on CMS  January 2002

cm2002年1月に100万メッセージ攻撃を防ぐレスコラ情報[6ページ]のRFC3218

6.  Full Copyright Statement

6. 完全な著作権宣言文

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

Copyright(C)インターネット協会(2002)。 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機能のための基金は現在、インターネット協会によって提供されます。

Rescorla                     Informational                      [Page 7]

レスコラInformationalです。[7ページ]