RFC2785 日本語訳

Network Working Group                                     R. Zuccherato
Request for Comments: 2785                         Entrust Technologies
Category: Informational                                      March 2000

Zuccheratoがコメントのために要求するワーキンググループR.をネットワークでつないでください: 2785は技術カテゴリをゆだねます: 情報の2000年3月

       Methods for Avoiding the "Small-Subgroup" Attacks on the
             Diffie-Hellman Key Agreement Method for S/MIME

S/MIMEのためにディフィー-ヘルマンの主要な協定メソッドに対する「小さいサブグループ」攻撃を避けるためのメソッド

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 (2000).  All Rights Reserved.

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

Abstract

要約

   In some circumstances the use of the Diffie-Hellman key agreement
   scheme in a prime order subgroup of a large prime p is vulnerable to
   certain attacks known as "small-subgroup" attacks.  Methods exist,
   however, to prevent these attacks.  This document will describe the
   situations relevant to implementations of S/MIME version 3 in which
   protection is necessary and the methods that can be used to prevent
   these attacks.

いくつかの事情では、大きい第1pの主要なオーダーサブグループにおけるディフィー-ヘルマンの主要な協定体系の使用は「小さいサブグループ」攻撃として知られているある攻撃に被害を受け易いです。 メソッドは、しかしながら、これらの攻撃を防ぐために存在しています。 このドキュメントは保護が必要であるS/MIMEバージョン3の実装に関連している状況とこれらの攻撃を防ぐのに使用できるメソッドを説明するでしょう。

1. Introduction

1. 序論

   This document will describe those situations in which protection from
   "small-subgroup" type attacks is necessary when using Diffie-Hellman
   key agreement [RFC2631] in implementations of S/MIME version 3
   [RFC2630, RFC2633].  Thus, the ephemeral-static and static-static
   modes of Diffie-Hellman will be focused on. Some possible non-S/MIME
   usages of CMS are also considered, though with less emphasis than the
   cases arising in S/MIME.  The situations for which protection is
   necessary are those in which an attacker could determine a
   substantial portion (i.e. more than a few bits) of a user's private
   key.

このドキュメントはS/MIMEバージョン3[RFC2630、RFC2633]の実装にディフィー-ヘルマンの主要な協定[RFC2631]を使用するとき「小さいサブグループ」タイプ攻撃からの保護が必要であるそれらの状況について説明するでしょう。 したがって、ディフィー-ヘルマンのはかなく静的で静的に静的なモードに集中するでしょう。 また、もっとも、CMSのいくつかの可能な非S/MIME使用法がS/MIMEで起こるケースより少ない強調で考えられます。 保護が必要である状況は攻撃者がユーザの秘密鍵のかなりの部分(すなわち、数ビットより多くの)を決定できたそれらです。

   Protecting oneself from these attacks involves certain costs.  These
   costs may include additional processing time either when a public key
   is certified or a shared secret key is derived, increased parameter
   generation time, and possibly the licensing of encumbered

これらの攻撃から我が身をかばうのはあるコストを伴います。 共有された秘密鍵は、公開鍵が公認されるとき、これらのコストが追加処理時間を含むかもしれませんか、派生して、増強されたパラメタ世代時間と、ことによると妨げられることの認可です。

Zuccherato                   Informational                      [Page 1]

RFC 2785     Methods for Avoiding "Small-Subgroup" Attacks    March 2000

2000年3月に「小さいサブグループ」攻撃を避けるためのZuccheratoの情報[1ページ]のRFC2785メソッド

   technologies.  All of these factors must be considered when deciding
   whether or not to protect oneself from these attacks, or whether to
   engineer the application so that protection is not necessary.

技術。 これらの攻撃から我が身をかばうかどうか、または保護は必要でないようにアプリケーションを設計するかどうか決めるとき、これらの要素のすべてを考えなければなりません。

   We will not consider "attacks" where the other party in the key
   agreement merely forces the shared secret value to be "weak" (i.e.
   from a small set of possible values) without attempting to compromise
   the private key.  It is not worth the effort to attempt to prevent
   these attacks since the other party in the key agreement gets the
   shared secret and can simply make the plaintext public.

私たちは秘密鍵に感染するのを試みない主要な合意における相手が共有秘密キー値が「弱いこと」を(すなわち、小さい可能な値からの)単に強制する「攻撃」を考えるつもりではありません。 主要な合意における相手が共有秘密キーを得て、単に平文を公共にすることができるのでこれらの攻撃を防ぐのを試みるのは取り組みの価値がありません。

   The methods described in this memo may also be used to provide
   protection from similar attacks on elliptic curve based Diffie-
   Hellman.

また、このメモで説明されたメソッドは、楕円曲線に対する同様の攻撃からの保護にベースのディフィー・ヘルマンを提供するのに使用されるかもしれません。

1.1 Notation

1.1 記法

   In this document we will use the same notation as in [RFC2631].  In
   particular the shared secret ZZ is generated as follows:

私たちが[RFC2631]で同じ記法を使用するつもりであるこのドキュメントで。 特に、共有秘密キーZZは以下の通り生成されます:

      ZZ = g ^ (xb * xa) mod p

ZZはg^(xb*xa)モッズpと等しいです。

   Note that the individual parties actually perform the computations:

個々のパーティーが実際に計算を実行することに注意してください:

      ZZ = (yb ^ xa)  mod p  = (ya ^ xb)  mod p

ZZがモッズp=と等しい、(Yb^xa)(あなた、^xb) モッズp

   where ^ denotes exponentiation.

^が羃法を指示するところ。

      ya is Party A's public key; ya = g ^ xa mod p
      yb is Party B's public key; yb = g ^ xb mod p
      xa is Party A's private key; xa is in the interval [2, (q - 2)]
      xb is Party B's private key; xb is in the interval [2, (q - 2)]
      p is a large prime
      g = h^((p-1)/q) mod p, where
      h is any integer with 1 < h < p-1 such that h^((p-1)/q) mod p > 1
            (g has order q mod p)
      q is a large prime
      j a large integer such that p=q*j + 1

あなたはパーティAの公開鍵です。 g^xaモッズpあなた=Ybはパーティビーズ公開鍵です。 g^xbのモッズ風のp Yb=xaはパーティAの秘密鍵です。 xaが間隔にある、[2 (q--2)] xbはパーティビーズ秘密鍵です。 xbが間隔[2、(q--2]pは大きい主要なg=h^(p-1)/qである)モッズpにあって、大きい主要なj a大きい整数が1<h<p-1あれほどそんなにh^((p-1)/q)モッズ風のp>1(gには、オーダーqモッズpがいます)qに従ってhがあらゆる整数であることのそのようなものである、そのp=q*j+1つ

   In this discussion, a "static" public key is one that is certified
   and is used for more than one key agreement, and an "ephemeral"
   public key is one that is not certified but is used only one time.

この議論では、「静的な」公開鍵は公認されて、1つ以上の主要な協定に使用されるものです、そして、「はかない」公開鍵は公認されませんが、あるときだけ使用されるものです。

   The order of an integer y modulo p is the smallest value of x greater
   than 1 such that y^x mod p = 1.

整数y法pの注文はそのような1つのそのy^xモッズp=1つよりすばらしいxの最も小さい値です。

Zuccherato                   Informational                      [Page 2]

RFC 2785     Methods for Avoiding "Small-Subgroup" Attacks    March 2000

2000年3月に「小さいサブグループ」攻撃を避けるためのZuccheratoの情報[2ページ]のRFC2785メソッド

1.2 Brief Description of Attack

1.2 攻撃の簡単な説明

   For a complete description of these attacks see [LAW] and [LIM].

これらの攻撃の完全な記述に関しては、[LAW]と[LIM]を見てください。

   If the other party in an execution of the Diffie-Hellman key
   agreement method has a public key not of the form described above,
   but of small order (where small means less than q) then he/she may be
   able to obtain information about the user's private key.  In
   particular, if information on whether or not a given decryption was
   successful is available, if ciphertext encrypted with the agreed upon
   key is available, or if a MAC computed with the agreed upon key is
   available, information about the user's private key can be obtained.

ディフィー-ヘルマンの主要な協定メソッドの実行におけるパーティーには上で説明されたフォームではなく、小口注文の公開鍵がもう片方であるならあります。(q) 次に、その人より少ない小さい資力がユーザの秘密鍵の情報を得ることができるかもしれないところ。 同意がキーにある状態で暗号化された暗号文が利用可能であるなら与えられた復号化がうまくいったかどうかの情報が利用可能であるか、または同意がキーにある状態で計算されたMACが利用可能であるなら、特に、ユーザの秘密鍵の情報を得ることができます。

   Assume Party A has a valid public key ya and that Party B has a
   public key yb that is not of the form described in Section 1.1,
   rather yb has order r, where r is much less than q.  Thus yb^r=1 mod
   p.  Now, when Party A produces ZZ as yb^xa mod p, there will only be
   r possible values for ZZ instead of q-3 possible values.  At this
   point Party B does not know the value ZZ, but may be able to
   exhaustively search for it.

パーティAには1.1に、むしろYbが持っているセクションで説明されたフォームのものでない公開鍵YbがあなたとそのパーティBで、rがqよりはるかに少ないrを命令する有効な公開鍵があると仮定してください。 その結果、Yb^r=1モッズp。 パーティAが現在Yb^xaモッズpとしてZZを生産するときだけ、r q-3の可能な値の代わりにZZに、可能な値があるでしょう。 ここに、パーティBは、値のZZを知りませんが、それを徹底的に捜し求めることができるかもしれません。

   If Party A encrypts plaintext with this value and makes that
   ciphertext available to Party B, Party B only needs to exhaustively
   search through r possibilities to determine which key produced the
   ciphertext.  When the correct one is found, this gives information
   about the value of xa modulo r.  Similarly, if Party A uses ZZ to
   decrypt a ciphertext and Party B is able to determine whether or not
   decryption was performed correctly, then information about xa can be
   obtained.  The actual number of messages that must be sent or
   received for these attacks to be successful will depend on the
   structure of the prime p.  However, it is not unreasonable to expect
   that the entire private key could be determined after as few as one
   hundred messages.

パーティAでこの値で平文を暗号化して、その暗号文がパーティBに利用可能になるなら、パーティBは、どのキーが暗号文を生産したかを決定するrの可能性を徹底的に隅々まで捜す必要があるだけです。 正しい方が見つけられるとき、これはxa法rの値に関して知らせます。 同様に、パーティAが暗号文を解読するのにZZを使用して、パーティBが、復号化が正しく実行されたかどうか決定できるなら、xaの情報を得ることができます。 これらの攻撃がうまくいっているために送らなければならないか、または受け取らなければならないメッセージの実数は第1pの構造に依存するでしょう。 しかしながら、全体の秘密鍵が最小100のメッセージの後に決定できたと予想するのは無理ではありません。

   A similar attack can be mounted if Party B chooses a public key of
   the form yb=g^xb*f, where f is an element of small order.  In this
   situation Party A will compute ZZ=yb^xa=g^(xa*xb)*f^xa mod p.  Again,
   Party B can compute g^(xa*xb) and can therefore exhaust the small
   number of possible values of f^xa mod p to determine information
   about xa.

パーティBがfが小口注文の要素であるg^xbフォームYb=*fの公開鍵を選ぶなら、同様の攻撃を仕掛けることができます。 この状況で、パーティAはZZ=Yb^xa=g^(xa*xb)*f^xaモッズpを計算するでしょう。 一方、パーティBでg^(xa*xb)を計算できて、したがって、f^xaモッズpの可能な値の少ない数は、xaの情報を決定するためにくたくたになることができます。

   An attack is also possible if Party B has a public key yb of order r
   where r factors into small integers but is not necessarily a small
   integer itself.  In this case, the attacker needs to know the value
   ZZ computed by Party A.  From this value Party B can solve for Party
   A's private key modulo r using the Pohlig-Hellman [PH] algorithm.

また、パーティBにrがわずかな整数を要因として考慮するオーダーrの公開鍵Ybがあるなら、攻撃も可能ですが、必ずわずかな整数はそれ自体ではありませんか? この場合、攻撃者は、値のZZがPohlig-ヘルマン[ペーハー]アルゴリズムを使用することでパーティA.FromによるパーティBがパーティAの秘密鍵法rのために解決できるこの値を計算したのを知る必要があります。

Zuccherato                   Informational                      [Page 3]

RFC 2785     Methods for Avoiding "Small-Subgroup" Attacks    March 2000

2000年3月に「小さいサブグループ」攻撃を避けるためのZuccheratoの情報[3ページ]のRFC2785メソッド

   However, this attack is not as practical as the cases already
   presented, where information about the private key is recovered from
   the *use* of ZZ, rather than ZZ itself, by exhaustive search.

しかしながら、この攻撃は既に提示されたケースほど実用的ではありません、徹底的な検索で。(そこでは、ZZよりむしろZZ自身の*使用*は秘密鍵の情報から取り戻されます)。

2. Situations Where Protection Is Necessary

2. 保護が必要である状況

   This section describes the situations in which the sender of a
   message should obtain protection against this type of attack and also
   those situations in which the receiver of a message should obtain
   protection. Each entity may decide independently whether it requires
   protection from these attacks.

このセクションはメッセージの送付者がこのタイプの攻撃に対する保護を得るべきである状況とメッセージの受信機が保護を得るはずであるそれらの状況も説明します。 各実体は、それがこれらの攻撃から保護を必要とするかどうか独自に決めるかもしれません。

   This discussion assumes that the recipient's key pair is static, as
   is always the case in [RFC2631].

この議論は、いつものことだが[RFC2631]で受取人の主要な組が静的であると仮定します。

2.1 Message Sender

2.1 メッセージ送付者

   This section describes situations in which the message sender should
   be protected.

このセクションはメッセージ送付者が保護されるべきである状況について説明します。

   If the sender's key is ephemeral, (i.e. ephemeral-static Diffie-
   Hellman is being used), then no protection is necessary.  In this
   situation only the recipients of the message can obtain the plaintext
   and corresponding ciphertext and therefore determine information
   about the private key using the "small-subgroup" attacks.  However,
   the recipients can always decrypt the message and since the sender's
   key is ephemeral, even if the recipient can learn the entire private
   key no other messages are at risk.  Notice here that if two or more
   recipients have selected the same domain parameters (p,q,g) then the
   same ephemeral public key can be used for all of them.  Since the key
   is ephemeral and only associated with a message that the recipients
   can already decrypt, no interesting attacks are possible.

送付者のキーがはかないなら(すなわち、はかなく静的なディフィー・ヘルマンは使用されています)、その時、ノー・プロテクションが必要です。 この状況だけで、メッセージの受取人は、「小さいサブグループ」攻撃を使用することで平文と対応する暗号文を得て、したがって、秘密鍵の情報を決定できます。 しかしながら、受取人はいつもメッセージを解読することができます、そして、送付者のキーがはかないので、受取人が全体の秘密鍵を学ぶことができても、他のどんなメッセージも危険ではありません。 ここで2人以上の受取人が同じドメインパラメタ(p、q、g)を選択したならそれらのすべてに同じはかない公開鍵を使用できるのに注意してください。 以来、キーははかないです、そして、受取人が既に解読することができるメッセージに関連しているだけであって、どんなおもしろい攻撃も可能ではありません。

   If the sender's key is static (i.e. static-static Diffie-Hellman is
   being used), then protection is necessary because in this situation a
   recipient mounting a small-subgroup attack may be able to obtain the
   plaintext from another recipient (perhaps one with a valid public key
   also controlled by the recipient) and therefore could obtain
   information about the private key.  Moreover, the attacker does not
   need to know the plaintext to test whether a key is correct, provided
   that the plaintext has sufficient redundancy (e.g., ASCII).  This
   information could then be used to attack other messages protected
   with the same static key.

送付者のキーが静的であるなら(すなわち、静的に静的なディフィー-ヘルマンは使用されています)、小さいサブグループ攻撃を仕掛けている受取人がこの状況で、別の受取人(恐らくまた、有効な公開鍵が受取人が制御されている1)から平文を得ることができたかもしれなくて、したがって、秘密鍵の情報を得ることができたので、保護が必要です。 そのうえ、攻撃者はキーが正しいか否かに関係なく、テストするために平文を知る必要はありません、平文に十分な冗長(例えば、ASCII)があれば。 そして、同じ静的なキーで保護された他のメッセージを攻撃するのにこの情報を使用できました。

Zuccherato                   Informational                      [Page 4]

RFC 2785     Methods for Avoiding "Small-Subgroup" Attacks    March 2000

2000年3月に「小さいサブグループ」攻撃を避けるためのZuccheratoの情報[4ページ]のRFC2785メソッド

2.2 Message Recipient

2.2 メッセージ受取人

   This section describes situations in which the message recipient
   should be protected.

このセクションはメッセージ受取人が保護されるべきである状況について説明します。

   If absolutely no information on the decryption of the ciphertext is
   available to any other party than the recipient, then protection is
   not necessary because this attack requires information on whether the
   decryption was successful to be sent to the attacker.  So, no
   protective measures are necessary if the implementation ensures that
   no information about the decryption can leak out.  However,
   protection may be warranted if human users may give this information
   to the sender via out of band means (e.g. through telephone
   conversations).

受取人よりいかなる他のパーティーにも、絶対に暗号文の復号化のどんな情報も利用可能でないなら、この攻撃が、復号化がうまくいったかどうかの情報が攻撃者に送られるのを必要とするので、保護は必要ではありません。 それで、実装が、復号化の情報が全く漏れることができないのを確実にするなら、どんな保護処分も必要ではありません。 を通してしかしながら、人間のユーザがこの情報を送付者に教えるかもしれないなら保護が保証されるかもしれない、バンド手段(例えば、電話での会話による)から。

   If information on the decryption is available to any other party,
   then protection is necessary. In particular, protection is necessary
   if any protocol event allows any other party to conclude that
   decryption was successful.  Such events include replies and returning
   signed receipts.

いかなる他のパーティーにも、復号化の情報が利用可能であるなら、保護が必要です。 他のパーティーが、どんなプロトコルイベントでも復号化がうまくいったと結論を下すことができるなら、保護が特に、必要です。 そのようなイベントは領収書であると署名される回答と帰りを含んでいます。

3. Methods Of Protection

3. 保護のメソッド

   This section describes five protective measures that senders and
   recipients of messages can use to protect themselves from "small-
   subgroup" attacks.

このセクションはメッセージの送付者と受取人が「小さいサブグループ」攻撃から我が身をかばうのに使用できる5つの保護処分について説明します。

   Implementers should note that some of the procedures described in
   this section may be the subject of patents or pending patents.

Implementersは、このセクションで説明された手順のいくつかが特許か係属特許の対象であるかもしれないことに注意するはずです。

3.1 Public Key Validation

3.1 公開鍵合法化

   This method is described in Section 2.1.5 of [RFC2631], and its
   description is repeated here.  If this method is used, it should be
   used to validate public keys of the other party prior to computing
   the shared secret ZZ.  The public key to be validated is y.

このメソッドは.5セクション2.1[RFC2631]で説明されます、そして、記述はここで繰り返されます。 このメソッドが使用されているなら、それは、共有秘密キーZZを計算する前に相手の公開鍵を有効にするのに使用されるべきです。 有効にされるべき公開鍵はyです。

   1. Verify that y lies within the interval [2,p-1]. If it does not,
        the key is invalid.
   2. Compute y^q mod p. If the result == 1, the key is valid.
        Otherwise the key is invalid.

1. yが間隔[2、p-1]に属すことを確かめてください。 そうしないなら、キーは無効です。 2. y^qモッズpを計算してください。 結果=1であるなら、キーは有効です。 さもなければ、キーは無効です。

3.2 CA Performs Public Key Validation

3.2 カリフォルニアは公開鍵合法化を実行します。

   The Certification Authority (CA) could perform the Public Key
   Validation method described in Section 3.1 prior to signing and
   issuing a certificate containing a Diffie-Hellman public key.  In
   this way, any party using the public key can be assured that a

認証局(カリフォルニア)はディフィー-ヘルマン公開鍵を含む証明書を署名して、発行する前にセクション3.1で説明されたPublic Key Validationメソッドを実行できました。 このように、公開鍵を使用しているどんなパーティーにもそのaを保証できます。

Zuccherato                   Informational                      [Page 5]

RFC 2785     Methods for Avoiding "Small-Subgroup" Attacks    March 2000

2000年3月に「小さいサブグループ」攻撃を避けるためのZuccheratoの情報[5ページ]のRFC2785メソッド

   trusted third party has already performed the key validation process.
   This method is only viable for static public keys.  When Static-
   Static Diffie-Hellman is employed, both the sender and recipient are
   protected when the CA has performed public key validation.  However,
   when Ephemeral-Static Diffie-Hellman is employed, only the sender can
   be protected by having the CA perform public key validation.  Since
   the sender generates an ephemeral public key, the CA cannot perform
   the validation on that public key.

信頼できる第三者機関は既に主要な合法化プロセスを実行しました。 静的な公開鍵だけに、このメソッドは実行可能です。 Staticの静的なディフィー-ヘルマンが採用しているとき、カリフォルニアが公開鍵合法化を実行したとき、送付者と受取人の両方は保護されます。 しかしながら、Ephemeral静的なディフィー-ヘルマンが採用しているとき、カリフォルニアに公開鍵合法化を実行させることによって、送付者しか保護できません。 送付者がはかない公開鍵を生成するので、カリフォルニアはその公開鍵に合法化を実行できません。

   In the case of a static public key a method must exist to assure the
   user that the CA has actually performed this verification.  The CA
   can notify certificate users that it has performed the validation by
   reference to the CA's Certificate Policy (CP) and Certification
   Practice Statement (CPS) [RFC2527] or through extensions in the
   certificate.

静的な公開鍵の場合では、メソッドは、カリフォルニアが実際にこの検証を実行したことをユーザに知らせるために存在しなければなりません。 カリフォルニアは、CAのCertificate Policy(CP)とCertification Practice Statement(CPS)[RFC2527]か証明書における拡大を通して参照で合法化を実行したことを証明書ユーザに通知できます。

3.3 Choice of Prime p

3.3 Prime pの選択

   The prime p could be chosen such that p-1=2*q*k where k is a large
   prime or is the product of large primes (large means greater than or
   equal to q).  This will prevent an attacker from being able to find
   an element (other than 1 and p-1) of small order modulo p, thus
   thwarting the small-subgroup attack.  One method to produce primes of
   this form is to run the prime generation algorithm multiple times
   until an appropriate prime is obtained.  As an example, the value of
   k could be tested for primality.  If k is prime, then the value of p
   could be accepted, otherwise the prime generation algorithm would be
   run again, until a value of p is produced with k prime.

第1pは選ばれたそのようなものがkが大きい主要であるか大きい盛りの製品(多大はqをより意味する)であるそのp-1=2*q*kであるならそうすることができるでしょうに。 これによって、攻撃者は、法がpであることが小口注文の要素(1とp-1を除いた)にわかることができないでしょう、その結果、小さいサブグループ攻撃を阻みます。 このフォームの盛りを生産する1つのメソッドは適切な第1を得るまで主要な世代アルゴリズムを複数の回実行することです。 例として、primalityがないかどうかkの値をテストできました。 kが主要であるなら、pの値を受け入れるかもしれなくて、さもなければ、再び主要な世代アルゴリズムを実行するでしょう、pの値がk第1で生産されるまで。

   However, since with primes of this form there is still an element of
   order 2 (i.e. p-1), one bit of the private key could still be lost.
   Thus, this method may not be appropriate in circumstances where the
   loss of a single bit of the private key is a concern.

しかしながら、オーダー2(すなわち、p-1)の要素がこのフォームの盛りと共にあるので、秘密鍵の1ビットはまだなくされている場合がありました。 したがって、このメソッドは秘密鍵の1ビットの損失が関心である事情で適切でないかもしれません。

   Another method to produce primes of this form is to choose the prime
   p such that p = 2*q*k + 1 where k is small (i.e. only a few bits). In
   this case, the leakage due to a small subgroup attack will be only a
   few bits.  Again, this would not be appropriate for circumstances
   where the loss of even a few bits of the private key is a concern. In
   this approach, q is large.  Note that in DSA, q is limited to 160
   bits for performance reasons, but need not be the case for Diffie-
   Hellman.

pは、このフォームの盛りを生産する別のメソッドが第1pを選ぶことであるので、2*q*と等しいです。kが小さいk+1(すなわち、ほんの数ビット)。 この場合、小さいサブグループ攻撃による漏出はほんの数ビットになるでしょう。 一方、秘密鍵の数ビットさえの損失が関心である事情には、これは適切でないでしょう。 このアプローチでは、qは大きいです。 qがDSAでは、性能理由で160ビットに制限されますが、ディフィー・ヘルマンのためのケースである必要はないことに注意してください。

   Additionally, other methods (i.e. public key validation) can be
   combined with this method in order to prevent the loss of a few bits
   of the private key.

さらに、秘密鍵の数ビットの損失を防ぐために、他のメソッド(すなわち、公開鍵合法化)をこのメソッドに結合できます。

Zuccherato                   Informational                      [Page 6]

RFC 2785     Methods for Avoiding "Small-Subgroup" Attacks    March 2000

2000年3月に「小さいサブグループ」攻撃を避けるためのZuccheratoの情報[6ページ]のRFC2785メソッド

3.4 Compatible Cofactor Exponentiation

3.4 コンパチブル補助因子羃法

   This method of protection is specified in [P1363] and [KALISKI].  It
   involves modifying the computation of ZZ by including j (the
   cofactor) in the computations and is compatible with ordinary
   Diffie-Hellman when both  parties' public keys are valid. If a
   party's public key is invalid, then the resulting ZZ will either be 1
   or an element of order q; the small subgroup elements will either be
   detected or cancelled.  This method requires that gcd(j,q)=1.

保護のこのメソッドは[P1363]と[KALISKI]で指定されます。 'それは、ZZの計算を変更することを計算にj(補助因子)を含んでいることによって伴って、双方であるときに、普通のディフィー-ヘルマンと互換性があり'公開鍵は有効です。 パーティーの公開鍵が無効であるなら、結果として起こるZZはオーダーqの1か要素のどちらかになるでしょう。 わずかなサブグループ要素は、検出されるか、または取り消されるでしょう。 このメソッドはその最大公約数(j、q)=1を必要とします。

   Instead of computing ZZ as ZZ=yb^xa mod p, Party A would compute it
   as ZZ=(yb^j)^c mod p where c=j^(-1)*xa mod q.  (Similarly for Party
   B.)

ZZがYb^xaモッズpと等しいのでZZを計算することの代わりに、ZZがc=j^(-1)*がモッズqをxaする(Yb^j)^cモッズpと等しいときに、パーティAはそれを計算するでしょう。 (同様である、パーティB.)

   If the resulting value ZZ satisfies ZZ==1, then the key agreement
   should be abandoned because the public key being used is invalid.

結果として起こる値のZZがZZ==1を満たすなら、使用される公開鍵が無効であるので、主要な協定はやめられるべきです。

   Note that when j is larger than q, as is usually the case with
   Diffie-Hellman, this method is less efficient than the method of
   Section 3.1.

jがqよりセクション3.1のメソッドより大きいときに、通常ディフィー-ヘルマンがいるケースのように、このメソッドが、より効率的でないことに注意してください。

3.5 Non-compatible Cofactor Exponentiation

3.5 非コンパチブル補助因子羃法

   This method of protection is specified in [P1363].  Similar to the
   method of Section 3.4, it involves modifying the computation of ZZ by
   including j (the cofactor) in the computations. If a party's public
   key is invalid, then the resulting ZZ will either be 1 or an element
   of order q; the small subgroup elements will either be detected or
   cancelled. This method requires that gcd(j,q)=1.

保護のこのメソッドは[P1363]で指定されます。 セクション3.4のメソッドと同様です、それは計算にj(補助因子)を含んでいることによってZZの計算を変更することを伴います。 パーティーの公開鍵が無効であるなら、結果として起こるZZはオーダーqの1か要素のどちらかになるでしょう。 わずかなサブグループ要素は、検出されるか、または取り消されるでしょう。 このメソッドはその最大公約数(j、q)=1を必要とします。

   Instead of computing ZZ as ZZ=yb^xa mod p, Party A would compute it
   as ZZ=(yb^j)^xa mod p.  (Similarly for Party B.)  However, with this
   method the resulting ZZ value is different from what is computed in
   [RFC2631] and therefore is not interoperable with implementations
   conformant to [RFC2631].

ZZがYb^xaモッズpと等しいのでZZを計算することの代わりに、ZZが(Yb^j)^xaモッズpと等しいときに、パーティAはそれを計算するでしょう。 (同様である、パーティB.) しかしながら、このメソッドについて、結果として起こるZZ値は[RFC2631]で計算された、したがって実装conformantで共同利用できないことから[RFC2631]まで異なっています。

   If the resulting value ZZ satisfies ZZ==1, then the key agreement
   should be abandoned because the public key being used is invalid.

結果として起こる値のZZがZZ==1を満たすなら、使用される公開鍵が無効であるので、主要な協定はやめられるべきです。

   Note that when j is larger than q, as is usually the case with
   Diffie-Hellman, this method is less efficient than the method of
   Section 3.1.

jがqよりセクション3.1のメソッドより大きいときに、通常ディフィー-ヘルマンがいるケースのように、このメソッドが、より効率的でないことに注意してください。

Zuccherato                   Informational                      [Page 7]

RFC 2785     Methods for Avoiding "Small-Subgroup" Attacks    March 2000

2000年3月に「小さいサブグループ」攻撃を避けるためのZuccheratoの情報[7ページ]のRFC2785メソッド

4. Ephemeral-Ephemeral Key Agreement

4. はかなくはかない主要な協定

   This situation is when both the sender and recipient of a message are
   using ephemeral keys.  While this situation is not possible in
   S/MIME, it might be used in other protocol environments.  Thus we
   will briefly discuss protection for this case as well.

この状況は送付者とメッセージの受取人の両方がはかないキーを使用している時です。 この状況がS/MIMEで可能でない間、それは他のプロトコル環境で使用されるかもしれません。 したがって、また、私たちはこのような場合簡潔に保護について議論するつもりです。

   Implementers should note that some of the procedures described in
   this section may be the subject of patents or pending patents.

Implementersは、このセクションで説明された手順のいくつかが特許か係属特許の対象であるかもしれないことに注意するはずです。

   Ephemeral-ephemeral key agreement gives an attacker more flexibility
   since both parties' public keys can be changed and they can be
   coerced into computing the same key from a small space. However, in
   the ephemeral-static case, only the sender's public key can be
   changed, and only the recipient can be coerced by an outside attacker
   into computing a key from a small space.

'はかなくはかない主要な協定は双方以来の、より多くの柔軟性を攻撃者に与える'という公開鍵を変えることができます、そして、小さいスペースから同じキーを計算するのにそれらを強制できます。 しかしながら、はかなく静的な場合では、送付者の公開鍵しか変えることができません、そして、外部の攻撃者は小さいスペースからキーを計算するのに受取人しか強制できません。

   Thus, in some ephemeral-ephemeral key agreements protection may be
   necessary for both entities. One possibility is that the attacker
   could modify both parties' public key so as to make their shared key
   predictable.  For example, the attacker could replace both ya and yb
   with some element of small order, say -1.  Then, with a certain
   probability, both the sender and receiver would compute the same
   shared value that comes from some small, easily exhaustible set.

したがって、いくつかのはかなくはかない主要な合意では、保護が両方の実体に必要であるかもしれません。 '1つの可能性は攻撃者が双方を変更できたということです'という公開鍵、それらの共有されたキーを予測できるようにしてください。 -1は、例えば、攻撃者があなたとYbの両方を小口注文の何らかの要素に取り替えることができたと言います。 そして、ある確率と、送付者と受信機が同じように計算する両方が何らかの小さくて、容易に使いつくせるセットから来る値を共有しました。

   Note that in this situation if protection was obtained from the
   methods of Section 3.3, then each user must ensure that the other
   party's public key does not come from the small set of elements of
   small order.  This can be done either by checking a list of such
   elements, or by additionally applying the methods of Sections 3.1,
   3.4 or 3.5.

セクション3.3のメソッドから保護を得たならこの状況で、各ユーザが、相手の公開鍵が小さいセットの小口注文の要素から来ないのを保証しなければならないことに注意してください。 そのような要素のリストをチェックするか、またはさらに、セクション3.1、3.4または3.5のメソッドを適用することによって、これができます。

   Protection from these attacks is not necessary however if the other
   party's ephemeral public key has been authenticated.  The
   authentication may be in the form of a signature, MAC, or any other
   integrity protection mechanism.  An example of this is in the
   Station-To-Station protocol [STS].  Since the owner authenticates the
   public key, a third party cannot modify it and therefore cannot mount
   an attack.  Thus, the only person that could attack an entity's
   private key is the other authenticated entity in the key agreement.
   However, since both public keys are ephemeral, they only protect the
   current session that the attacker would have access to anyway.

しかしながら、相手のはかない公開鍵が認証されたなら、これらの攻撃からの保護は必要ではありません。 認証が署名、MAC、またはいかなる他の保全保護メカニズムの形にもあるかもしれません。 ステーション・トゥー・ステーションプロトコル[STS]にはこの例があります。 所有者が公開鍵を認証するので、第三者は、それを変更できないで、したがって、攻撃を開始できません。 したがって、実体の秘密鍵を攻撃できた唯一の人が主要な合意でもう片方の認証された実体です。 しかしながら、両方の公開鍵がはかないので、それらは攻撃者がとにかく近づく手段を持っている現在のセッションを保護するだけです。

5. Security Considerations

5. セキュリティ問題

   This entire document addresses security considerations in the
   implementation of Diffie-Hellman key agreement.

この全体のドキュメントは、セキュリティがディフィー-ヘルマンの主要な協定の実装で問題であると扱います。

Zuccherato                   Informational                      [Page 8]

RFC 2785     Methods for Avoiding "Small-Subgroup" Attacks    March 2000

2000年3月に「小さいサブグループ」攻撃を避けるためのZuccheratoの情報[8ページ]のRFC2785メソッド

6. Intellectual Property Rights

6. 知的所有権

   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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

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

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を扱ってください。

7. References

7. 参照

   [KALISKI] B.S. Kaliski, Jr., "Compatible cofactor multiplication for
             Diffie-Hellman primitives", Electronics Letters, vol. 34,
             no. 25, December 10, 1998, pp. 2396-2397.

[KALISKI]理学士Kaliski、Jr.、「ディフィー-ヘルマン基関数のためのコンパチブル補助因子乗法」、Electronics Letters、vol.34、No.25、1998年12月10日、ページ 2396-2397.

   [LAW]     L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone, "An
             efficient protocol for authenticated key agreement",
             Technical report CORR 98-05, University of Waterloo, 1998.

[LAW] L.法とA.メネゼスとM.QuとJ.SolinasとS.Vanstone、「認証された主要な協定のための効率的なプロトコル」、TechnicalはCORR98-05、ウォータールー大学、1998を報告します。

   [LIM]     C.H. Lim and P.J. Lee, "A key recovery attack on discrete
             log- based schemes using a prime order subgroup", B.S.
             Kaliski, Jr., editor, Advances in Cryptology - Crypto '97,
             Lecture Notes in Computer Science, vol. 1295, 1997,
             Springer-Verlag, pp. 249-263.

[LIM]C.H.リムとP.J.リー、「離散的なログに対するキーリカバリー攻撃は主要なオーダーサブグループを使用することで体系を基礎づけました」、理学士Kaliski、Jr.、エディタ、CryptologyのAdvances--暗号97年、コンピュータScienceのLecture Notes、vol.1295、1997、Springer-Verlag、ページ 249-263.

   [P1363]   IEEE P1363, Standard Specifications for Public Key
             Cryptography, 1998, work in progress.

[P1363]IEEE P1363(Public Key Cryptography、1998年のStandard Specifications)は進行中で働いています。

   [PH]      S.C Pohlig and M.E. Hellman, "An improved algorithm for
             computing logarithms over GF(p) and its cryptographic
             significance", IEEE Transactions on Information Theory,
             vol. 24, 1972, pp. 106-110.

[ペーハー]S.C PohligとM.E.ヘルマン、「GF(p)とその暗号の意味に関して対数を計算するための拡張アルゴリズム」、情報Theory、vol.24、1972、ページのIEEE Transactions 106-110.

Zuccherato                   Informational                      [Page 9]

RFC 2785     Methods for Avoiding "Small-Subgroup" Attacks    March 2000

2000年3月に「小さいサブグループ」攻撃を避けるためのZuccheratoの情報[9ページ]のRFC2785メソッド

   [RFC2527] Chokhani, S. and W. Ford, "Internet X.509 Public Key
             Infrastructure, Certificate Policy and Certification
             Practices Framework", RFC 2527, March 1999.

[RFC2527] Chokhani、S.、およびW.フォード、「インターネットX.509公開鍵基盤、方針を証明してください。そうすれば、証明はフレームワークを練習します」、RFC2527、1999年3月。

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

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

   [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
             2631, June 1999.

[RFC2631] レスコラ、E.、「ディフィー-ヘルマンの主要な協定メソッド」、RFC2631、1999年6月。

   [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
             2633, June 1999.

[RFC2633] Ramsdell、B.、「S/MIMEバージョン3メッセージ仕様」、RFC2633、1999年6月。

   [STS]     W. Diffie, P.C. van Oorschot and M. Wiener, "Authentication
             and authenticated key exchanges", Designs, Codes and
             Cryptography, vol. 2, 1992, pp. 107-125.

[STS]W.ディフィー、P.C.バンOorschot、M.Wiener、および「認証と認証された主要な交換」とDesignsとCodesとCryptography、vol.2、1992、ページ 107-125.

8. Author's Address

8. 作者のアドレス

   Robert Zuccherato
   Entrust Technologies
   750 Heron Road
   Ottawa, Ontario
   Canada K1V 1A7

ロバートZuccheratoは技術750サギのRoadオタワ、オンタリオカナダK1V 1A7をゆだねます。

   EMail: robert.zuccherato@entrust.com

メール: robert.zuccherato@entrust.com

Zuccherato                   Informational                     [Page 10]

RFC 2785     Methods for Avoiding "Small-Subgroup" Attacks    March 2000

2000年3月に「小さいサブグループ」攻撃を避けるためのZuccheratoの情報[10ページ]のRFC2785メソッド

9.  Full Copyright Statement

9. 完全な著作権宣言文

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

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

Zuccherato                   Informational                     [Page 11]

Zuccherato情報です。[11ページ]