Network Working Group M. Friedl
Request for Comments: 4419 N. Provos
Category: Standards Track W. Simpson
March 2006
Diffie-Hellman Group Exchange for
the Secure Shell (SSH) Transport Layer Protocol
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This memo describes a new key exchange method for the Secure Shell (SSH) protocol. It allows the SSH server to propose new groups on which to perform the Diffie-Hellman key exchange to the client. The proposed groups need not be fixed and can change with time.
このメモは、セキュアシェル（SSH）プロトコルのための新しい鍵の交換方法について説明します。これは、SSHサーバがクライアントへのDiffie-Hellman鍵交換を実行する上で新しいグループを提案することができます。提案されたグループは、固定する必要はなく、時間とともに変化することができます。
SSH [RFC4251] is a very common protocol for secure remote login on the Internet. Currently, SSH performs the initial key exchange using the "diffie-hellman-group1-sha1" method [RFC4253]. This method prescribes a fixed group on which all operations are performed.
SSH [RFC4251]はインターネット上での安全なリモートログインのための非常に一般的なプロトコルです。現在、SSH「はディフィー - ヘルマン-GROUP1-SHA1」法[RFC4253]を使用して初期鍵交換を行います。この方法は、すべての操作が実行されている固定群を規定します。
The Diffie-Hellman key exchange provides a shared secret that cannot be determined by either party alone. Furthermore, the shared secret is known only to the participant parties. In SSH, the key exchange is signed with the host key to provide host authentication.
Diffie-Hellman鍵交換は、単独のいずれかの当事者によって決定することができない共有シークレットを提供します。さらに、共有秘密は、唯一の参加者に知られています。 SSHでは、鍵交換は、ホスト認証を提供するために、ホスト鍵で署名されています。
The security of the Diffie-Hellman key exchange is based on the difficulty of solving the Discrete Logarithm Problem (DLP). Since we expect that the SSH protocol will be in use for many years in the future, we fear that extensive precomputation and more efficient algorithms to compute the discrete logarithm over a fixed group might pose a security threat to the SSH protocol.
Diffie-Hellman鍵交換をのセキュリティは、離散対数問題（DLP）を解くことの難しさに基づいています。私たちは、SSHプロトコルは将来的に多くの年の使用になることを期待しているので、我々は固定群上の離散対数を計算するために大規模な事前計算し、より効率的なアルゴリズムは、SSHプロトコルのセキュリティ上の脅威をもたらす可能性があることを恐れています。
The ability to propose new groups will reduce the incentive to use precomputation for more efficient calculation of the discrete logarithm. The server can constantly compute new groups in the background.
新しいグループを提案する能力は、離散対数のより効率的な計算のための事前計算を使用するインセンティブが低下します。サーバーは、常にバックグラウンドで新しいグループを計算することができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The server keeps a list of safe primes and corresponding generators that it can select from. A prime p is safe if p = 2q + 1 and q is prime. New primes can be generated in the background.
サーバーは安全素数と、それはから選択することができ、対応するジェネレータのリストを保持します。素数pは、p = 2Q + 1とqが素数である場合は安全です。新しい素数はバックグラウンドで生成することができます。
The generator g should be chosen such that the order of the generated subgroup does not factor into small primes; that is, with p = 2q + 1, the order has to be either q or p - 1. If the order is p - 1, then the exponents generate all possible public values, evenly distributed throughout the range of the modulus p, without cycling through a smaller subset. Such a generator is called a "primitive root" (which is trivial to find when p is "safe").
ジェネレータgは、生成サブグループの順序は小さな素数に因数分解しないように選択されるべきです。順序がpである場合 - 1 - それはP = 2Q + 1であり、順序はQまたはPのいずれかでなければならない1、次いで指数はすべての可能な公共の値を生成する、均等法pの範囲全体に分散、無しより小さなサブセットを巡回。このような発電機は、（pは「安全」である場合に見つけることが自明である）「原始根」と呼ばれています。
The client requests a modulus from the server indicating the preferred size. In the following description (C is the client, S is the server, the modulus p is a large safe prime, and g is a generator for a subgroup of GF(p), min is the minimal size of p in bits that is acceptable to the client, n is the size of the modulus p in bits that the client would like to receive from the server, max is the maximal size of p in bits that the client can accept, V_S is S's version string, V_C is C's version string, K_S is S's public host key, I_C is C's KEXINIT message, and I_S is S's KEXINIT message that has been exchanged before this part begins):
クライアントは、推奨サイズを示すサーバからのモジュラスを要求します。以下の説明において（Cはクライアントであり、Sはサーバであり、係数pが大きい安全素数であり、gはGF（P）のサブグループのジェネレータであり、minは許容されるビットのpの最小サイズでありますクライアントに、nは、クライアントがサーバから受け取りたいビットにおけるモジュラスpのサイズで、最大は、クライアントが受け入れることができるビットのpの最大の大きさで、V_SはSのバージョン文字列で、V_CはCのバージョンであります文字列は、K_SはSの公開ホスト鍵、I_CはCのKEXINITメッセージであり、そしてI_Sはこの部分が始まる前に）交換されたSさんKEXINITメッセージです。
1. C sends "min || n || max" to S, indicating the minimal acceptable group size, the preferred size of the group, and the maximal group size in bits the client will accept.
1. Cは最小許容グループサイズ、グループの好ましいサイズ、およびクライアントが受け入れるビットの最大群サイズを示す、Sに「分|| N ||マックス」を送信します。
2. S finds a group that best matches the client's request, and sends "p || g" to C.
2. Sが最高のクライアントの要求に合致するグループを見つけ、Cに「p個の|| gを」送ります
3. C generates a random number x, where 1 < x < (p-1)/2. It computes e = g^x mod p, and sends "e" to S.
3. Cは、乱数X 1 <X <（P-1）/ 2を生成します。これは、E = G ^ Xのmod Pを計算し、Sに "e" を送信します。
4. S generates a random number y, where 0 < y < (p-1)/2, and computes f = g^y mod p. S receives "e". It computes K = e^y mod p, H = hash(V_C || V_S || I_C || I_S || K_S || min || n || max || p || g || e || f || K) (these elements are encoded according to their types; see below), and signature s on H with its private host key. S sends "K_S || f || s" to C. The signing operation may involve a second hashing operation.
4. Sは、乱数Y、0 <Y <（P-1）/ 2、及びFを計算= G ^ Y MOD Pを生成します。 Sは "e" を受け取ります。これは、K = E ^ Y MOD P、H =ハッシュ（V_C || V_S || || I_C I_S || || K_S分|| N || ||最大のP || G || E || F ||を計算しますK）（これらの要素は、それらの種類に従って符号化されている;以下を参照のこと）、そのプライベートホストキーとHの署名S。 Sは、署名操作が、第二ハッシュ演算を含んでいてもよいCに「K_S || F || S」を送信します。
5. C verifies that K_S really is the host key for S (e.g., using certificates or a local database to obtain the public key). C is also allowed to accept the key without verification; however, doing so will render the protocol insecure against active attacks (but may be desirable for practical reasons in the short term in many environments). C then computes K = f^x mod p, H = hash(V_C || V_S || I_C || I_S || K_S || min || n || max || p || g || e || f || K), and verifies the signature s on H.
5. CはK_Sが本当に（例えば、公開鍵を取得するために証明書またはローカルデータベースを使用して）S用のホストキーであることを検証します。 Cも検証せずにキーを受け入れることを許可されています。しかし、そうすることは、アクティブな攻撃に対して安全でないプロトコルをレンダリングします（ただし、多くの環境で短期的に実際的な理由が望ましいかもしれません）。 | Cは、その後、K = F ^ X MOD P、H =ハッシュ（V_C || || V_S I_C || || I_S K_S ||分|| N ||最大|| P || G || E || Fを計算します| K）、及びH.上の署名Sを検証します
Servers and clients SHOULD support groups with a modulus length of k bits, where 1024 <= k <= 8192. The recommended values for min and max are 1024 and 8192, respectively.
サーバとクライアントは、minとmax 1024 <= K <= 8192推奨値は、それぞれ1024および8192であるkビットのモジュラスの長さを持つグループをサポートしなければなりません。
Either side MUST NOT send or accept e or f values that are not in the range [1, p-1]. If this condition is violated, the key exchange fails. To prevent confinement attacks, they MUST accept the shared secret K only if 1 < K < p - 1.
どちらの側が送信または範囲内にないEまたはFの値[1、P-1]を受け入れてはいけません。この条件に違反した場合、鍵交換が失敗します。閉じ込め攻撃を防ぐために、彼らは1 <K <P場合は、共有秘密Kを受け入れなければならない - 1。
The server should return the smallest group it knows that is larger than the size the client requested. If the server does not know a group that is larger than the client request, then it SHOULD return the largest group it knows. In all cases, the size of the returned group SHOULD be at least 1024 bits.
サーバは、それはそれは、クライアントが要求したサイズよりも大きい知っている最小のグループを返す必要があります。サーバはクライアントの要求よりも大きくなっているグループを知らない場合には、それはそれは知っている最大のグループを返すべきです。全ての場合において、返されたグループのサイズは、少なくとも1024ビットであるべきです。
This is implemented with the following messages. The hash algorithm for computing the exchange hash is defined by the method name, and is called HASH. The public key algorithm for signing is negotiated with the KEXINIT messages.
これは、次のようなメッセージで実装されています。交換ハッシュを計算するハッシュアルゴリズムは、メソッド名によって定義され、HASHと呼ばれています。署名の公開鍵アルゴリズムはKEXINITメッセージと交渉しています。
First, the client sends:
まず、クライアントが送信します。
byte SSH_MSG_KEY_DH_GEX_REQUEST uint32 min, minimal size in bits of an acceptable group uint32 n, preferred size in bits of the group the server will send uint32 max, maximal size in bits of an acceptable group
グループのビットにおけるバイトSSH_MSG_KEY_DH_GEX_REQUEST UINT32分、許容されるグループUINT32のビットで最小サイズN、好適なサイズのサーバが許容グループのビットでUINT32 MAX、最大のサイズを送信します
The server responds with
サーバが応答して
byte SSH_MSG_KEX_DH_GEX_GROUP mpint p, safe prime mpint g, generator for subgroup in GF(p)
バイトSSH_MSG_KEX_DH_GEX_GROUPのmpint pを、安全素数mpint gを、GFにおけるサブグループの発電機（P）
The client responds with:
クライアントがで応答します。
byte SSH_MSG_KEX_DH_GEX_INIT mpint e
バイトSSH_MSG_KEX_DH_GEX_INITのmpint電子
The server responds with:
サーバがで応答します。
byte SSH_MSG_KEX_DH_GEX_REPLY string server public host key and certificates (K_S) mpint f string signature of H
バイトSSH_MSG_KEX_DH_GEX_REPLY文字列サーバ公開ホスト鍵と証明書（K_S）Hのmpint F列の署名
The hash H is computed as the HASH hash of the concatenation of the following:
ハッシュHは、以下の連結のハッシュハッシュとして計算されます。
string V_C, the client's version string (CR and NL excluded) string V_S, the server's version string (CR and NL excluded) string I_C, the payload of the client's SSH_MSG_KEXINIT string I_S, the payload of the server's SSH_MSG_KEXINIT string K_S, the host key uint32 min, minimal size in bits of an acceptable group uint32 n, preferred size in bits of the group the server will send uint32 max, maximal size in bits of an acceptable group mpint p, safe prime mpint g, generator for subgroup mpint e, exchange value sent by the client mpint f, exchange value sent by the server mpint K, the shared secret
文字列V_C、クライアントのバージョン文字列（CRとNLを除く）は、文字列V_S、サーバのバージョン文字列（CRとNLを除く）は、文字列I_C、クライアントのSSH_MSG_KEXINIT列I_Sのペイロードは、サーバのSSH_MSG_KEXINIT列K_Sのペイロード、ホスト鍵グループのビットでUINT32分、許容されるグループUINT32のビットで最小サイズN、好ましいサイズサーバは、UINT32最大許容グループmpint pのビットの最大サイズ、安全素数mpint gで、サブグループmpint Eの発生を送信しますクライアントmpint fで送信された交換価値、サーバmpint Kにより送信された交換価値、共有秘密
This value is called the exchange hash, and it is used to authenticate the key exchange as per [RFC4253].
この値は、交換ハッシュと呼ばれ、[RFC4253]あたりのように鍵交換を認証するために使用されます。
This document defines two new key exchange methods: "diffie-hellman-group-exchange-sha1" and "diffie-hellman-group-exchange-sha256".
「ディフィー・ヘルマン・グループ交換-SHA1」と「ディフィー・ヘルマン・グループ交換-SHA256」：この文書は、2つの新しい鍵交換方法を定義します。
The "diffie-hellman-group-exchange-sha1" method specifies Diffie-Hellman Group and Key Exchange with SHA-1 [FIPS-180-2] as HASH.
"ディフィー・ヘルマン・グループ交換-SHA1" 方式は、SHA-1 [FIPS-180-2] HASHなどでのDiffie-Hellmanのグループおよび鍵交換を指定します。
The "diffie-hellman-group-exchange-sha256" method specifies Diffie-Hellman Group and Key Exchange with SHA-256 [FIPS-180-2] as HASH.
"ディフィー・ヘルマン・グループ交換-SHA256" 方式は、ハッシュとしてSHA-256を使ってDiffie-Hellmanのグループおよび鍵交換[FIPS-180-2]を指定します。
Note that the hash used in key exchange (in this case, SHA-256) must also be used in the key derivation pseudo-random function (PRF), as per the requirement in the "Output from Key Exchange" section in [RFC4253].
鍵交換で使用されるハッシュは、（この場合、SHA-256）[RFC4253]の「キー交換からの出力が」セクションに要件ごとに、鍵導出の擬似ランダム関数（PRF）にも使用されなければならないことに注意してください。
The following message numbers have been defined in this document. They are in a name space private to this document and not assigned by IANA.
次のメッセージ番号は、この文書で定義されています。彼らは、この文書にプライベートとIANAによって割り当てられていない名前空間です。
#define SSH_MSG_KEX_DH_GEX_REQUEST_OLD 30 #define SSH_MSG_KEX_DH_GEX_REQUEST 34 #define SSH_MSG_KEX_DH_GEX_GROUP 31 #define SSH_MSG_KEX_DH_GEX_INIT 32 #define SSH_MSG_KEX_DH_GEX_REPLY 33
#define SSH_MSG_KEX_DH_GEX_REQUEST_OLD 30の#define SSH_MSG_KEX_DH_GEX_REQUEST 34の#define SSH_MSG_KEX_DH_GEX_GROUP 31の#define SSH_MSG_KEX_DH_GEX_INIT 32の#define SSH_MSG_KEX_DH_GEX_REPLY 33
SSH_MSG_KEX_DH_GEX_REQUEST_OLD is used for backward compatibility. Instead of sending "min || n || max", the client only sends "n". In addition, the hash is calculated using only "n" instead of "min || n || max".
SSH_MSG_KEX_DH_GEX_REQUEST_OLDは、下位互換性のために使用されています。代わりに「分|| || nは最大の」送信のため、クライアントは「n」を送信します。また、ハッシュではなく、「分|| N ||最大」の「N」のみを使用して計算されます。
The numbers 30-49 are key exchange specific and may be redefined by other kex methods.
番号30から49は、鍵交換固有のものであり、他のKEX方法で再定義することができます。
One useful technique is to select the generator, and then limit the modulus selection sieve to primes with that generator:
一つの有用な技術は、発電機を選択し、その発生器をプライミングするモジュラス選択ふるいを制限することです。
2 when p (mod 24) = 11. 5 when p (mod 10) = 3 or 7.
2 P（MOD 24）= 11 5ときP（MOD 10）= 3または7。
It is recommended to use 2 as generator, because it improves efficiency in multiplication performance. It is usable even when it is not a primitive root, as it still covers half of the space of possible residues.
それは、乗算性能の効率を向上させることができるので、発電機として2を使用することをお勧めします。それはまだ可能性残基のスペースの半分をカバーしていて、それは、原始根でない場合であっても、それは使用可能です。
To increase the speed of the key exchange, both client and server may reduce the size of their private exponents. It should be at least twice as long as the key material that is generated from the shared secret. For more details, see the paper by van Oorschot and Wiener [VAN-OORSCHOT].
鍵交換の速度を上げるために、クライアントとサーバの両方が彼らのプライベート指数の大きさを減らすことができます。これは、共有秘密から生成されたキーマテリアルとして、少なくとも二倍の長さであるべきです。詳細については、バンOorschotおよびウィーナー[VAN-OORSCHOT]による論文を参照。
This protocol aims to be simple and uses only well-understood primitives. This encourages acceptance by the community and allows for ease of implementation, which hopefully leads to a more secure system.
このプロトコルは、シンプルであることを目指しのみ十分に理解プリミティブを使用しています。これはコミュニティによって受け入れを奨励し、うまくいけば、より安全なシステムにつながる実装を容易にします。
The use of multiple moduli inhibits a determined attacker from precalculating moduli exchange values, and discourages dedication of resources for analysis of any particular modulus.
複数のモジュラスの使用は、モジュラス交換値を事前計算から決定攻撃を阻害、任意の特定の弾性率の分析のためのリソースの献身を阻止します。
It is important to employ only safe primes as moduli, as they allow us to find a generator g so that the order of the generated subgroup does not factor into small primes, that is, with p = 2q + 1, the order has to be either q or p - 1. If the order is p - 1, then the exponents generate all possible public values, evenly distributed throughout the range of the modulus p, without cycling through a smaller subset. Van Oorshot and Wiener note that using short private exponents with a random prime modulus p makes the computation of the discrete logarithm easy [VAN-OORSCHOT]. However, they also state that this problem does not apply to safe primes.
彼らが発生したサブグループの順番は、p = 2Q + 1で、つまり、小さな素数に考慮しないように、私たちはジェネレータgを見つけることができて、注文がなければならない、弾性係数としてのみ安全素数を用いることが重要ですQまたはPのいずれか - 1.順序がpである場合 - 図1は、その後、指数はすべての可能な公共の値を生成する、均等に小さなサブセットを循環することなく、係数pの範囲全体に分散します。ヴァンOorshotとウィーナーは、ランダムプライムモジュラスpと短いプライベート指数を使用して、離散対数簡単[VAN-OORSCHOT]の計算を行いますことに注意してください。しかし、彼らはまた、この問題は安全素数には適用されないと述べています。
The least significant bit of the private exponent can be recovered when the modulus is a safe prime [MENEZES]. However, this is not a problem if the size of the private exponent is big enough. Related to this, Waldvogel and Massey note: When private exponents are chosen independently and uniformly at random from {0,...,p-2}, the key entropy is less than 2 bits away from the maximum, lg(p-1) [WALDVOGEL].
弾性率は安全素数[メネゼス]であるとき、プライベート指数の最下位ビットを回収することができます。プライベート指数の大きさが十分に大きい場合は、これは問題ではありません。この、Waldvogelとマッセイノートに関連する：プライベート指数からランダムに独立かつ一様に選択される場合、{0、...、P-2}、キーエントロピー未満、2ビット離れ最大、LG（P-1からなります）[WALDVOGEL]。
The security considerations in [RFC4251] also apply to this key exchange method.
[RFC4251]のセキュリティの考慮事項も、この鍵交換方式に適用されます。
The document is derived in part from "SSH Transport Layer Protocol" [RFC4253] by T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, and S. Lehtinen.
文書はT. Ylonenと、T. Kivinen、M.サーリネン、T.リンネ、及びS. Lehtinenのよる "SSHトランスポート層プロトコル" [RFC4253]から部分的に導出されます。
Markku-Juhani Saarinen pointed out that the least significant bit of the private exponent can be recovered efficiently when using safe primes and a subgroup with an order divisible by two.
マルック-Juhaniサーリネンは2で割り切れるために安全素数とサブグループを使用するときにプライベート指数の最下位ビットが効率的に回収することができることを指摘しました。
Bodo Moeller suggested that the server send only one group, reducing the complexity of the implementation and the amount of data that needs to be exchanged between client and server.
ボーデメラーは、サーバーが実装の複雑さと、クライアントとサーバー間で交換する必要のあるデータの量を減らすこと、一つのグループだけを送信することが示唆されました。
Appendix A: Generation of Safe Primes
付録A：安全素数の生成
The "Handbook of Applied Cryptography" [MENEZES] lists the following algorithm to generate a k-bit safe prime p. It has been modified so that 2 is a generator for the multiplicative group mod p.
「応用暗号のハンドブック」[メネゼス]は、kビットの安全な素数pを生成するには、次のアルゴリズムを示しています。 2乗法群MOD pのジェネレータであるようにそれが変更されています。
2. Compute p := 2q + 1, and test whether p is prime (using, e.g., trial division and the Rabin-Miller test).
2.計算する：P = 2Q + 1、およびpが素数であるかどうかを試験（使用して、例えば、試験部門とラビン - ミラーテスト）。
If an implementation uses the OpenSSL libraries, a group consisting of a 1024-bit safe prime and 2 as generator can be created as follows:
実装はOpenSSLライブラリを使用している場合は、次のように、発電機として1024ビットの安全素数と2からなるグループを作成することができます。
DH *d = NULL;
d = DH_generate_parameters(1024, DH_GENERATOR_2, NULL, NULL);
BN_print_fp(stdout, d->p);
The order of the subgroup generated by 2 is q = p - 1.
1 - 2によって生成されたサブグループの順序は、Q = Pです。
References
リファレンス
Normative References
引用規格
[FIPS-180-2] National Institute of Standards and Technology (NIST), "Secure Hash Standard (SHS)", FIPS PUB 180-2, August 2002.
[FIPS-180-2]国立標準技術研究所（NIST）、 "セキュアハッシュ規格（SHS）"、FIPS PUB 180-2の、2002年8月。
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[RFC4251] Ylonenと、T.とC. Lonvick、 "セキュアシェル（SSH）プロトコルアーキテクチャ"、RFC 4251、2006年1月。
[RFC4253] Lonvick, C., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
[RFC4253] Lonvick、C.、 "セキュアシェル（SSH）トランスポート層プロトコル"、RFC 4253、2006年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
Informative References
参考文献
[MENEZES] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook of Applied Cryptography", CRC Press, p. 537, 1996.
[メネゼス]メネゼス、A.、バンOorschot、P.、およびS. Vanstone著、 "応用暗号のハンドブック"、CRCプレス、P。 537、1996。
[VAN-OORSCHOT] van Oorschot, P. and M. Wiener, "On Diffie-Hellman key agreement with short exponents", Advances in Cryptology -EUROCRYPT'96, LNCS 1070, Springer-Verlag, pp. 332-343, 1996.
【VAN-OORSCHOT]バンOorschot、P.及びM.ウィーナー、 "ショート指数とのDiffie-Hellman鍵合意には" 暗号理論-EUROCRYPT'96、LNCS 1070、シュプリンガー・フェアラーク、頁332から343まで、1996年に進歩します。
[WALDVOGEL] Waldvogel, C. and J. Massey, "The probability distribution of the Diffie-Hellman key", Proceedings of AUSCRYPT 92, LNCS 718, Springer-Verlag, pp. 492-504, 1993.
【WALDVOGEL] Waldvogel、C.及びJ.マッシー "のDiffie-Hellmanキーの確率分布"、AUSCRYPT 92、LNCS 718、シュプリンガー・フェアラーク、頁492から504まで、1993の議事。
Authors' Addresses
著者のアドレス
Markus Friedl EMail: markus@openbsd.org
マルクスFriedlのEメール：markus@openbsd.org
Niels Provos EMail: provos@citi.umich.edu
ニールスはEMAILを試してください。provos@citi.umich.edu
William A. Simpson EMail: wsimpson@greendragon.com
ウィリアムA.シンプソンEメール：wsimpson@greendragon.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。