[要約] RFC 2785は、Diffie-Hellman (DH) 鍵共有プロトコルにおいて、鍵の安全性を著しく損なう可能性がある「小部分群攻撃 (Small-Subgroup Attacks)」とその対策について解説しています。攻撃者が特定の値を選択することで共有鍵の候補を限定させる手法を分析し、受信した公開値が適切な位数（order）を持つかを検証する手順を推奨しています。暗号プロトコルの実装において、DH鍵交換の数学的な安全性を保証し、鍵情報の漏洩を防止するための具体的な防御策を提供することを目的としています。
Network Working Group R. Zuccherato
Request for Comments: 2785 Entrust Technologies
Category: Informational March 2000
Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME
S/MIME の Diffie-Hellman 鍵合意手法に対する Small Subgroup 攻撃の回避方法
Status of this 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）The Internet Society（2000）。無断転載を禁じます。
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.
状況によっては、大きな素数 p の素数位数部分群における Diffie-Hellman 鍵合意方式の使用は、「小部分群攻撃（small-subgroup attacks）」として知られる特定の攻撃に対して脆弱になります。しかし、これらの攻撃を防ぐ方法は存在します。このドキュメントでは、保護が必要な S/MIME バージョン 3 の実装に関連する状況と、これらの攻撃を防ぐために使用できる方法について説明します。
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] の実装において Diffie-Hellman 鍵合意 [RFC2631] を使用する際に、「小部分群」タイプの攻撃からの保護が必要となる状況について説明します。したがって、Diffie-Hellman のエフェメラル-静的（ephemeral-static）および静的-静的（static-static）モードに焦点を当てます。S/MIME で発生するケースほど重視はしませんが、CMS の 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 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.
このメモで説明されている方法は、楕円曲線ベースのdiffie-hellmanに対する同様の攻撃からの保護を提供するためにも使用できます。
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
Note that the individual parties actually perform the computations:
個々の当事者が実際に計算を実行することに注意してください。
ZZ = (yb ^ xa) mod p = (ya ^ xb) mod 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
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.
この議論では、「静的」公開鍵とは証明書によって証明され、2回以上の鍵合意に使用される公開鍵のことであり、「エフェメラル」公開鍵とは証明されていないが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 における位数（order）とは、y^x mod p = 1 を満たす 1 より大きい最小の整数 x の値です。
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.
Diffie-Hellman 鍵合意方式の実行において、相手方が上記のような形式ではなく、小さな位数（ここで小さいとは 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 が有効な公開鍵 ya を持ち、パーティ B がセクション 1.1 で説明した形式ではない公開鍵 yb を持っており、yb の位数 r が q よりはるかに小さいと仮定します。すなわち、yb^r = 1 mod p です。このとき、パーティ A が ZZ を yb^xa mod p として生成すると、ZZ の候補は q-3 個の可能性のある値ではなく、r 個の可能性のある値のみとなります。この時点でパーティ 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 がこの値（ZZから導出した鍵）で平文を暗号化し、その暗号文をパーティ B が入手できる場合、パーティ B は r 個の候補を総当たりで探索するだけで、どの鍵がその暗号文を生成したかを特定できます。正しい値が見つかると、これにより xa mod r の値に関する情報が得られます。同様に、パーティ A が ZZ を使用して暗号文を復号し、パーティ B がその復号が正しく実行されたかどうかを判断できる場合にも、xa に関する情報を取得できます。これらの攻撃を成功させるために送信または受信しなければならないメッセージの実際の数は、素数 p の構造に依存します。しかし、わずか 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 が yb = g^xb * f の形式の公開鍵を選択した場合にも、同様の攻撃を行うことができます。ここで、f は小さな位数を持つ要素です。この状況において、パーティ A は ZZ = yb^xa = g^(xa*xb) * f^xa mod p を計算します。この場合も、パーティ B は g^(xa*xb) を計算できるため、f^xa mod 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 の公開鍵 yb を持っており、r が小さな整数の積に素因数分解できる（ただし r 自体は必ずしも小さな整数ではない）場合にも、攻撃は可能です。この場合、攻撃者はパーティ A によって計算された ZZ の値を知る必要があります。この値から、パーティ B は Pohlig-Hellman [PH] アルゴリズムを用いて、パーティ A の秘密鍵の mod r における値を求めることができます。
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 の「使用結果」に対する総当たり探索によって、秘密鍵に関する情報が回収されるためです。
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]の場合が常にそうであるように、受信者の鍵ペアが静的であることを前提としています。
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.
送信者の鍵がエフェメラル（一時的）である場合（すなわち、エフェメラル-静的（ephemeral-static）Diffie-Hellmanが使用されている場合）、保護は必要ありません。この状況では、メッセージの受信者のみが平文とそれに対応する暗号文を入手でき、したがって「小部分群」攻撃を用いて秘密鍵に関する情報を特定することができます。しかし、受信者は常にメッセージを復号することができ、送信者の鍵はエフェメラルであるため、仮に受信者が秘密鍵全体を知り得たとしても、他のメッセージが危険にさらされることはありません。ここで、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.
送信者の鍵が静的（スタティック）である場合（すなわち、静的-静的（static-static）Diffie-Hellmanが使用されている場合）、保護が必要です。なぜなら、この状況では、小部分群攻撃を仕掛ける受信者が、別の受信者（おそらく、その受信者によって制御されている有効な公開鍵を持つ別の宛先）宛ての平文を入手できる可能性があり、その結果として秘密鍵に関する情報を取得できるためです。さらに、平文に十分な冗長性（ASCIIなど）がある場合、攻撃者は鍵が正しいかどうかを検証するために平文を知る必要すらありません。得られた情報は、同じ静的鍵で保護された他のメッセージを攻撃するために使用される可能性があります。
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.
復号に関する情報が他の第三者に伝わる可能性がある場合は、保護が必要です。特に、何らかのプロトコルイベント（返信や署名付き受領書の返送など）によって、他の第三者が「復号が成功した」と判断できる場合には、保護が必要です。
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.
実装者は、このセクションで説明する手順の一部が特許または保留中の特許の対象である可能性があることに注意する必要があります。
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.
この方法は、[RFC2631]のセクション2.1.5で説明されており、その説明はここで繰り返されます。この方法を使用する場合は、共有された秘密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 mod pを計算します。結果== 1の場合、キーは有効です。それ以外の場合、キーは無効です。
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 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.
認証機関（CA）は、Diffie-Hellmanの公開キーを含む証明書に署名および発行する前に、セクション3.1で説明した公開キー検証方法を実行できます。このようにして、公開キーを使用する当事者は、信頼できる第三者がすでにキー検証プロセスを実行していることを保証できます。この方法は、静的なパブリックキーに対してのみ実行可能です。静的な静的diffie-hellmanが採用されると、CAが公開キーの検証を行ったときに送信者と受信者の両方が保護されます。ただし、はかない静的なdiffie-hellmanが採用されている場合、CAに公開キーの検証を実行することにより、送信者のみが保護できます。送信者は一時的な公開キーを生成するため、CAはその公開キーで検証を実行できません。
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が実際にこの検証を実行したことをユーザーに保証するためにメソッドが存在する必要があります。CAは、CAの証明書ポリシー（CP）および認定慣行声明（CPS）[RFC2527]を参照することにより、または証明書の拡張を通じて、証明書ユーザーに検証を実行したことをユーザーに通知できます。
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.
プライムPは、p-1 = 2*q*kが大きなプライムであるか、大きな素数の産物である（q以上の大きな平均）よりも選択できます。これにより、攻撃者が小さな順序モジュロPの要素（1およびP-1以外）を見つけることができなくなるため、小型グループ攻撃が妨げられます。このフォームのプライムを作成する1つの方法は、適切なプライムが取得されるまでプライムジェネレーションアルゴリズムを複数回実行することです。例として、Kの値は原始性をテストできます。Kがプライムの場合、Pの値を受け入れることができます。そうしないと、Pの値がK Primeで生成されるまで、Prime Generationアルゴリズムが再び実行されます。
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つがまだ失われる可能性があります。したがって、この方法は、単一のビットの秘密鍵を失うことが懸念事項である状況では適切ではないかもしれません。
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 = 2*q*k 1が小さい（つまり、わずかなビットのみ）ようにプライムPを選択することです。この場合、小さなサブグループ攻撃による漏れはわずか数ビットになります。繰り返しますが、これは、秘密鍵の数ビットでさえも紛失している状況が懸念事項である場合には適していません。このアプローチでは、Qは大きいです。DSAでは、Qはパフォーマンス上の理由で160ビットに制限されていますが、Diffie-Hellmanの場合はそうではないことに注意してください。
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.
さらに、秘密鍵の数ビットの損失を防ぐために、他の方法（つまり、公開キーの検証）をこの方法と組み合わせることができます。
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]で規定されています。これは、計算に j（補因子）を含めることによって ZZ の計算を修正するものであり、両当事者の公開鍵が有効な場合には通常の Diffie-Hellman と互換性があります。いずれかの当事者の公開鍵が無効である場合、結果となる ZZ は 1 または位数 q の要素となり、小部分群の要素は検出されるか打ち消されます。この方法では、gcd(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 を ZZ = yb^xa mod p として計算する代わりに、パーティ A は ZZ = (yb^j)^c mod p として計算します。ここで c = j^(-1) * xa mod q です。（パーティ 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.
Diffie-Hellman では通常そうであるように、j が q より大きい場合、この方法はセクション 3.1 の方法よりも効率が低くなることに注意してください。
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 は 1 または位数 q の要素となり、小部分群の要素は検出されるか打ち消されます。この方法では、gcd(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 を ZZ = yb^xa mod p として計算する代わりに、パーティ A は ZZ = (yb^j)^xa mod p として計算します。（パーティ B についても同様です。）しかし、この方法では得られる ZZ の値が [RFC2631] で計算されるものと異なるため、[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.
Diffie-Hellman では通常そうであるように、j が q より大きい場合、この方法はセクション 3.1 の方法よりも効率が低くなることに注意してください。
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.
実装者は、このセクションで説明する手順の一部が特許または出願中の特許の対象である可能性があることに注意してください。
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つの可能性として、攻撃者が双方の公開鍵を改ざんして、共有鍵を予測可能にするケースがあります。例えば、攻撃者は ya と yb の双方を小さな位数を持つ要素（例えば -1 など）に置き換えることができます。この場合、送信者と受信者の双方が、小さな、容易に総当たり探索可能な集合に属する同じ共有値を、一定の確率で計算することになります。
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、またはその他の整合性保護メカニズムの形式で行われます。この例として、Station-to-Station プロトコル [STS] があります。鍵の所有者が公開鍵を認証するため、第三者がそれを改ざんすることはできず、したがって攻撃を仕掛けることもできません。したがって、あるエンティティの秘密鍵を攻撃できる唯一の人物は、鍵合意におけるもう一方の認証されたエンティティとなります。しかし、双方の公開鍵はエフェメラルであるため、それらが保護するのは攻撃者がいずれにせよアクセス可能な現在のセッションのみです。
This entire document addresses security considerations in the implementation of Diffie-Hellman key agreement.
このドキュメント全体は、Diffie-Hellman 鍵合意の実装におけるセキュリティ上の考慮事項に対処しています。
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は、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができます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エグゼクティブディレクターに宛ててください。
[KALISKI] B.S. Kaliski, Jr., "Compatible cofactor multiplication for Diffie-Hellman primitives", Electronics Letters, vol. 34, no. 25, December 10, 1998, pp. 2396-2397.
[カリスキ] B.S.Kaliski、Jr。、「Diffie-Hellman Primitivesの互換性のある補因子乗算」、Electronics Letters、Vol。34、いいえ。25、1998年12月10日、pp。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. Law、A。Menezes、M。Qu、J。Solinas、およびS. Vanstone、「認証された鍵合意のための効率的なプロトコル」、テクニカルレポートCorr 98-05、Waterloo、University of Waterloo、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.
[リム] C.H.LimとP.J. Lee、「Prime Order Subgroupを使用した離散ログベースのスキームに対する重要な回復攻撃」、B.S。Kaliski、Jr。、編集者、CryptologyのAdvances -Crypto '97、講義ノートのComputer Science、Vol。1295、1997、Springer-Verlag、pp。249-263。
[P1363] IEEE P1363, Standard Specifications for Public Key Cryptography, 1998, work in progress.
[P1363] IEEE P1363、1998年公開キー暗号化の標準仕様、作業進行中。
[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.
[PH] S.C PohligおよびM.E. Hellman、「GF（P）およびその暗号化の重要性を計算するための改善されたアルゴリズム」、IEEEトランザクションに関する情報理論、Vol。24、1972、pp。106-110。
[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. Ford、「インターネットX.509公開キーインフラストラクチャ、証明書ポリシーおよび認証慣行フレームワーク」、RFC 2527、1999年3月。
[RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[RFC2630] Housley、R。、「暗号メッセージ構文」、RFC 2630、1999年6月。
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[RFC2631] Rescorla、E。、「Diffie-Hellman Key Asmatement Method」、RFC 2631、1999年6月。
[RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[RFC2633] Ramsdell、B。、「S/Mimeバージョン3メッセージ仕様」、RFC 2633、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. Diffie、P.C。Van OorschotおよびM. Wiener、「認証と認証されたキー交換」、デザイン、コード、暗号化、Vol。2、1992、pp。107-125。
Robert Zuccherato Entrust Technologies 750 Heron Road Ottawa, Ontario Canada K1V 1A7
Robert Zuccherato, Entrust Technologies, 750 Heron Road, Ottawa, Ontario, Canada K1V 1A7
EMail: robert.zuccherato@entrust.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
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.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
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.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。