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
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.
著作権（C）インターネット協会（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鍵共有方式を使用することは、「小サブグループ」攻撃として知られている特定の攻撃に対して脆弱です。方法は、しかし、これらの攻撃を防ぐために、存在します。この文書では、必要とする保護に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]を使用する場合、「小サブグループ」タイプの攻撃からの保護が必要であるような状況を説明します。このように、ディフィー・ヘルマンの-はかない静的および静的静的モードを中心に説明します。 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 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.
このメモに記載された方法はまた、ディフィー・ヘルマンベースの楕円曲線上の同様の攻撃からの保護を提供するために使用することができます。
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 *）モッズP
Note that the individual parties actually perform the computations:
個々の当事者が実際に計算を行うことに注意してください：
ZZ = (yb ^ xa) mod p = (ya ^ xb) mod p
ZZ =（YB ^ XA）のmod P =（YA ^ 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
yaは当事者Aの公開鍵です。 YA = G ^ XAモッズのp YBパーティーBの公開鍵です。 YB = G ^ XBモッズのp XAは、パーティAの秘密鍵です。 Xaは区間である[2、（Q - 2）] XBは、パーティBの秘密鍵です。 XBは区間である[2、（Q - 2）] pは大きな素数G H 1 <H <P-1のようなものと任意の整数である= H ^（（P-1）/ Q）MOD P、ありますH ^（（P-1）/ Q）MOD P> 1（gが次数q MOD Pた）Qは、P = Qの*のJ + 1ということ大きな素数JA大きい整数です。
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.
この議論では、「静的」公開鍵が認定されており、複数のキーの合意に使用されるものであり、「はかない」公開鍵が認定されていないが、一度しか使用されているものです。
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の順序は、x 1より大きいようにY ^ X MOD p = 1の最小値です。
For a complete description of these attacks see [LAW] and [LIM].
これらの攻撃の完全な説明については、[法律]および[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よりもはるかに小さい順Rを有していると仮定する。したがってYB ^ R = 1 MOD P。パーティAは、YB ^ XA MOD pとZZを生成する際に、今、唯一ZZに対するRの可能な値の代わりにQ-3の可能な値が存在することになります。この時点で、当事者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は、この値で平文を暗号化し、乙にその暗号文が利用できるようにする場合は、乙は徹底的に暗号文を生成したキーを決定するために、Rの可能性を検索する必要があります。正しいものが発見された場合、これは、XAモジュロrの値についての情報を与えます。パーティAは、暗号文を復号化するためにZZを使用し、パーティBは復号化が正しく行われたか否かを決定することができるならば、同様に、次にXAについての情報を得ることができます。成功するためには、これらの攻撃のために送信または受信されなければならないメッセージの実際の数は、素数pの構造に依存します。しかし、全体の秘密鍵は、わずか百一つとしてのメッセージの後に決定することができることを期待するのは無理ではありません。
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が小さい順の要素であるフォームYB = G ^ XBの* fとの公開鍵を選択した場合に同様の攻撃を実装することができます。このような状況では、甲は、ZZ = YB ^ XA = G ^（XA *のXB）*のF ^ XAモッズPを計算します。再び、パーティBは、G ^（XAの*のXB）を計算することができ、したがって、XAについての情報を決定するために、F ^ XA MOD Pの可能な値の小さな数を排出することができます。
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を有しているが、必ずしも小さい整数自体でない場合、攻撃も可能です。この場合、攻撃者は、乙は、Pohlig-Hellmanの[PH]アルゴリズムを使用して、パーティAの秘密鍵剰余Rのために解決することができ、この値から、党A.によって計算された値ZZを知る必要があります。
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.
送信者の鍵が一時的である場合には、（すなわち、はかない静電気の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.
送信者の鍵は（すなわち、静的な静的なディフィー・ヘルマンが使用されている）静的であれば、このような状況では小さなサブグループの攻撃を取り付け、受信者が別の受信者（と、おそらく1から平文を得ることができる可能性があるため、その後、保護が必要です有効な公開鍵はまた、秘密鍵の情報を得ることができたので、受信者によって制御される）と。また、攻撃者は鍵が正しいかどうかをテストするために平文を知る必要がない、平文が十分な冗長性（例えば、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節で説明した公開鍵の検証方法を実行することができます。このように、公開鍵を使用して、任意のパーティは、信頼できるサードパーティがすでにキー検証プロセスを実行していることを保証することができます。この方法は、静的な公開鍵でのみ実行可能です。スタティックスタティックディフィー・ヘルマンが採用されている場合、CAは、公開鍵検証を行った際に、送信者と受信者の両方が保護されています。エフェメラル-静的ディフィー・ヘルマンが採用されている場合しかし、唯一の送信者は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は、kが大きな素数であるか、または（大手段より大きいまたはqに等しい）の大きな素数の積であるK * P-1 = 2 * Qことを選択することができます。これにより、小サブグループ攻撃を阻止、小さい順モジュロpの（1以外のP-1）の要素を見つけることができることから、攻撃を防ぐことができます。この形式の素数を生成するための一つの方法は、適切な素数が得られるまで素数生成アルゴリズムを複数回実行することです。一例として、kの値は、素数について試験することができます。 kが素数である場合、pの値は、pの値は、k個の素数を用いて製造されるまで、そうでなければ素数生成アルゴリズムが、再び実行されるであろう、受け入れることができました。
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を選択することであるように、P = 2 * Q * kが小さい（すなわち、ほんの数ビット）であり、K + 1。この場合は、小さなサブグループ攻撃による漏洩がほんの数ビットになります。繰り返しますが、これは、秘密鍵のも、数ビットの損失が懸念される状況に適切ではないであろう。このアプローチでは、qは大きいです。 DSAにおいて、qはパフォーマンス上の理由のために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.
また、他の方法（すなわち、公開鍵の検証）は、秘密鍵の数ビットの損失を防ぐために、この方法と組み合わせることができます。
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の計算を変更することを含む、両当事者の公開鍵が有効である場合、通常のディフィー・ヘルマンと互換性があります。相手の公開鍵が無効な場合、結果として得られる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 = YB ^ XA MOD pとZZを計算する、パーティ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.
jは通常のDiffie-Hellmanのと同様に、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 = YB ^ XAモッズpとZZの計算、パーティーAは、ZZ =（YB ^ J）^ XAモッズ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.
jは通常のDiffie-Hellmanのと同様に、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.
このように、いくつかの短命-短期キー契約の保護に両方のエンティティのために必要な場合があります。一つの可能性は、彼らの共有キーは、予測可能になるように、攻撃者は、両方の当事者の公開鍵を修正することができるということです。たとえば、攻撃者は小さなためのいくつかの要素と屋及び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、または任意の他の完全性保護機構の形態であってもよいです。この例は、局間プロトコル[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.
【KALISKI] B.S. Kaliski、ジュニア、「のDiffie-Hellmanプリミティブの互換性の補因子乗算」、電子レター、巻。 34、ありません。 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.
【法律】L.法、A.メネゼス、M.ク、J. SolinasとS. Vanstone著、「認証鍵合意のための効率的なプロトコル」、技術報告CORR 98から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.・リー、「素のサブグループを使用して、離散対数ベースの方式の鍵回復攻撃」、B.S.暗号'97、コンピュータサイエンス、巻で講義ノート - Kaliski、ジュニア、編集者は、暗号学の進歩します。 1295年、1997年、シュプリンガー・フェアラーク、頁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]皮下Pohlig及びM.E.ヘルマン、情報理論、巻上、IEEEトランザクション「GF（p）及びその暗号意義上対数を計算するための改善されたアルゴリズム」。 24、1972年、頁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.フォード、 "インターネット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]レスコラ、E.、 "ディフィー・ヘルマン鍵共有方式"、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.ディフィー、P.C.バンOorschotおよびM.ウィーナー、「認証および認証鍵交換」、デザイン、コード及び暗号、体積。 2、1992、頁107から125まで。
Robert Zuccherato Entrust Technologies 750 Heron Road Ottawa, Ontario Canada K1V 1A7
ロバートZuccheratoエントラストテクノロジーズ750ヘロンロードオタワ、オンタリオカナダK1V 1A7
EMail: robert.zuccherato@entrust.com
メールアドレス：robert.zuccherato@entrust.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。