RFC4419 日本語訳

Network Working Group                                          M. Friedl
Request for Comments: 4419                                     N. Provos
Category: Standards Track                                     W. Simpson
                                                              March 2006

コメントを求めるワーキンググループM.フリードルの要求をネットワークでつないでください: 4419年のN.Provosカテゴリ: 2006年の標準化過程W.シンプソン行進

                   Diffie-Hellman Group Exchange for
            the Secure Shell (SSH) Transport Layer Protocol

安全なシェル(セキュアシェル (SSH))トランスポート層プロトコルへのディフィー-ヘルマングループExchange

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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2006).

Copyright(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.

このメモはSecureシェル(SSH)プロトコルのために新しい主要な交換方法を説明します。 それで、SSHサーバはクライアントへのディフィー-ヘルマンの主要な交換を実行する新しいグループを提案できます。 提案されたグループは、修理される必要はなくて、時間を交換できます。

1.  Overview and Rationale

1. 概観と原理

   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は、「diffie-hellman-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.

ディフィー-ヘルマンの主要な交換は何れの当事者が単独で決定できない共有秘密キーを提供します。 その上、共有秘密キーは関与しているパーティーだけにおいて知られています。 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.

ディフィー-ヘルマンの主要な交換のセキュリティはDiscrete Logarithm Problem(DLP)を解決するという困難に基づいています。 SSHプロトコルが将来何年間も使用中になると予想して、私たちは、固定グループに関して離散対数を計算する大規模な前計算と、より効率的なアルゴリズムがSSHプロトコルへの軍事的脅威を引き起こすかもしれないと恐れます。

Friedl, et al.              Standards Track                     [Page 1]

RFC 4419                 SSH DH Group Exchange                March 2006

フリードル、他 標準化過程[1ページ]RFC4419セキュアシェル (SSH)DHは2006年の交換行進のときに分類します。

   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.

新しいグループを提案する能力は離散対数の、より効率的な計算に前計算を使用する誘因を減少させるでしょう。 サーバは絶えずバックグラウンドにおける新しいグループを計算できます。

2.  Requirements Notation

2. 要件記法

   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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?

3.  Diffie-Hellman Group and Key Exchange

3. ディフィー-ヘルマングループと主要な交換

   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=2q+1とqが主要であるなら、第1pは安全です。 新しい盛りはバックグラウンドで発生できます。

   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=2q+1で、オーダーは、qかpのどちらかでなければなりません--1。 --オーダーが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)のサブグループのためのジェネレータである、分がクライアントにとって、許容できるビットの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は「分」を送ります。|| n|| クライアントは、S、最小量の許容できるグループサイズを示す、グループの優先サイズ、およびビットの最大限度のグループサイズへの「最大限にしてください。」と受け入れるでしょう。

   2.  S finds a group that best matches the client's request, and sends
       "p || g" to C.

2. Sはクライアントの要求に最もよく合って、「p」を送るグループを見つけます。|| 「g」からC。

   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。 それは、g^x e=モッズpを計算して、「e」をSに送ります。

Friedl, et al.              Standards Track                     [Page 2]

RFC 4419                 SSH DH Group Exchange                March 2006

フリードル、他 標準化過程[2ページ]RFC4419セキュアシェル (SSH)DHは2006年の交換行進のときに分類します。

   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、g^y f=モッズpを計算します。 Sは「e」を受けます。 それはHで個人的なホストキーでK=e^yモッズp、H=細切れ肉料理(V_C| | V_S| | I_C| | I_S| | K_S| | 分| | n| | 最大| | p| | g| | e| | f| | K)(彼らのタイプに従って、これらの要素はコード化されます; 以下を見る)、および署名sを計算します。 Sは「K_S」を送ります。|| f|| C. 調印操作への「s」は2番目のハッシュ操作にかかわるかもしれません。

   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モッズ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.

サーバと1024<がk<と等しいkビットの係数の長さがあるクライアントSHOULDサポートグループ=8192。 分と最大のための推奨値は、それぞれ1024と8192です。

   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.

どちらの側も、範囲[1、p-1]にないeかf値を、送ってはいけませんし、また受け入れてはいけません。 この状態が違反されるなら、主要な交換は失敗します。 監禁攻撃を防ぐために、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.

サーバはそれが知っているグループを最も小さく返すべきです。すなわち、クライアントが要求したサイズより大きいです。 サーバがグループを知らないなら、それはクライアント要求より大きく、次に、それはSHOULD収益です。知っている中で最も大きいグループ。 すべての場合では、返上のサイズは少なくとも1024がビットであったならSHOULDを分類します。

   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_エムエスジー_KEY_DH_GEX_REQUEST uint32分、許容できるグループuint32 nのビットの最小量のサイズ、サーバが許容できるグループのビットでuint32最大、最大限度のサイズを送るグループのビットの優先サイズ

Friedl, et al.              Standards Track                     [Page 3]

RFC 4419                 SSH DH Group Exchange                March 2006

フリードル、他 標準化過程[3ページ]RFC4419セキュアシェル (SSH)DHは2006年の交換行進のときに分類します。

   The server responds with

サーバは応じます。

     byte    SSH_MSG_KEX_DH_GEX_GROUP
     mpint   p, safe prime
     mpint   g, generator for subgroup in GF(p)

_バイトSSH_エムエスジーKEX_DH_GEX_GROUP mpint p、安全な主要なmpint g、GFにおけるサブグループのためのジェネレータ(p)

   The client responds with:

クライアントは以下で応じます。

     byte    SSH_MSG_KEX_DH_GEX_INIT
     mpint   e

バイト、SSH_エムエスジー_KEX_DH_GEX_INIT mpint e

   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

HのバイトSSH_エムエスジー_KEX_DH_GEX_REPLYストリングサーバの公共のホストキーと証明書(K_S)mpint fストリング署名

   The hash H is computed as the HASH hash of the concatenation of the
   following:

細切れ肉料理Hは以下の連結のHASH細切れ肉料理として計算されます:

     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_エムエスジー_KEXINITストリングI_Sのペイロード、サーバのSSH_エムエスジー_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]に従って主要な交換を認証するのに使用されます。

4.  Key Exchange Methods

4. 主要な交換方法

   This document defines two new key exchange methods:
   "diffie-hellman-group-exchange-sha1" and
   "diffie-hellman-group-exchange-sha256".

このドキュメントは2つの新しい主要な交換方法を定義します: 「diffie-hellmanグループはsha1"を交換します、そして、「diffie-hellmanグループはsha256を交換します」。」

Friedl, et al.              Standards Track                     [Page 4]

RFC 4419                 SSH DH Group Exchange                March 2006

フリードル、他 標準化過程[4ページ]RFC4419セキュアシェル (SSH)DHは2006年の交換行進のときに分類します。

4.1.  diffie-hellman-group-exchange-sha1

4.1. diffie-hellmanグループ交換sha1

   The "diffie-hellman-group-exchange-sha1" method specifies
   Diffie-Hellman Group and Key Exchange with SHA-1 [FIPS-180-2] as
   HASH.

「diffie-hellmanグループ交換sha1"方法はSHA-1[FIPS-180-2]と共にHASHとしてディフィー-ヘルマンGroupとKey Exchangeを指定します。」

4.2.  diffie-hellman-group-exchange-sha256

4.2. diffie-hellmanグループ交換sha256

   The "diffie-hellman-group-exchange-sha256" method specifies
   Diffie-Hellman Group and Key Exchange with SHA-256 [FIPS-180-2] as
   HASH.

「diffie-hellmanグループ交換sha256」方法はSHA-256[FIPS-180-2]と共にHASHとしてディフィー-ヘルマンGroupとKey Exchangeを指定します。

   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].

[RFC4253]の「主要な交換からの出力」セクションの要件に従ってまた、主要な派生擬似ランダム機能(PRF)に主要な交換(この場合SHA-256)に使用される細切れ肉料理を使用しなければならないことに注意してください。

5.  Summary of Message Numbers

5. メッセージ番号の概要

   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

#定義、SSH_エムエスジー_KEX_DH_GEX_REQUEST_OLD30#、がKEX_DH_GEX_REQUEST34#、が定義するSSH_エムエスジー_を定義する、SSH_エムエスジー_KEX_DH_GEX_GROUP31#、がKEX_DH_GEX_INIT32#、が定義するSSH_エムエスジー_を定義する、SSH_エムエスジー_KEX_DH_GEX_REPLY33

   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_エムエスジー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.

No.30-49は、主要な交換特有であり、他のkex方法で再定義されるかもしれません。

6.  Implementation Notes

6. 実現注意

6.1.  Choice of Generator

6.1. ジェネレータの選択

   One useful technique is to select the generator, and then limit the
   modulus selection sieve to primes with that generator:

1つの役に立つテクニックは、ジェネレータを選択して、次に、係数選択ふるいをそのジェネレータがある盛りに制限することです:

      2   when p (mod 24) = 11.
      5   when p (mod 10) = 3 or 7.

2 p(モッズ風の24)=11であるときに。 5 p(モッズ風の10)=3か7であるときに。

Friedl, et al.              Standards Track                     [Page 5]

RFC 4419                 SSH DH Group Exchange                March 2006

フリードル、他 標準化過程[5ページ]RFC4419セキュアシェル (SSH)DHは2006年の交換行進のときに分類します。

   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を使用するのは、乗法性能で能率を増進するので、お勧めです。 原始根でさえないときに、それは使用可能です、まだ半分の可能な残りのスペースをカバーしているとき。

6.2.  Private Exponents

6.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].

主要な交換の速度を上がらせるように、クライアントとサーバの両方が彼らの個人的な解説者のサイズを減少させるかもしれません。 それは少なくとも共有秘密キーから発生する主要な材料の2倍長いはずです。 その他の詳細に関しては、バンOorschotとWiener[ヴァン-OORSCHOT]による紙を見てください。

7.  Security Considerations

7. セキュリティ問題

   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.

オーダーは、qかpのどちらかでなければなりません--発生しているサブグループの注文は係数として安全な盛りだけを使うのが重要です、彼らがジェネレータがgであることが私たちをわからせるときすなわち、小さい盛り、pで=2q+1を因数分解しないで、1。 --オーダーがpであるなら1、そして、より小さい部分集合を通して循環しないで、解説者は係数pの範囲中で均等に分配されたすべての可能な公共の値を発生させます。 ヴァンOorshotとWienerは、無作為の主要な係数pと共に背の低い個人的な解説者を使用するのに離散対数の計算が簡単に[ヴァン-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]のセキュリティ問題はこの主要な交換方法に適用されます。

Friedl, et al.              Standards Track                     [Page 6]

RFC 4419                 SSH DH Group Exchange                March 2006

フリードル、他 標準化過程[6ページ]RFC4419セキュアシェル (SSH)DHは2006年の交換行進のときに分類します。

8.  Acknowledgements

8. 承認

   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.レーティネンは「セキュアシェル (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.

ボーデメラーは、サーバが1つのグループだけを送ることを提案しました、クライアントとサーバの間で交換される必要がある実現の複雑さとデータ量を減少させて。

Friedl, et al.              Standards Track                     [Page 7]

RFC 4419                 SSH DH Group Exchange                March 2006

フリードル、他 標準化過程[7ページ]RFC4419セキュアシェル (SSH)DHは2006年の交換行進のときに分類します。

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-ビットの安全な第1pを発生させるように以下のアルゴリズムを記載します。 それが変更されたので、2は乗法群のモッズpのためのジェネレータです。

   1.  Do the following:

1. 以下をしてください:

       1.  Select a random (k-1)-bit prime q, so that q mod 12 = 5.

1. そのように、無作為(k-1)のビット第1q、そのqモッズ12 = 5を選んでください。

       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が主要である(使用して、例えば、試行除算とラビンミラーはテストします)か否かに関係なく、テストしてください。

   2.  Repeat until p is prime.

2. 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年のビットの安全な第1から成るグループとジェネレータとしての2を作成できます:

       DH *d = NULL;
       d = DH_generate_parameters(1024, DH_GENERATOR_2, NULL, NULL);
       BN_print_fp(stdout, d->p);

DH*dはヌルと等しいです。 d、= DH_は_パラメタ(1024、DH_GENERATOR_2、NULL、NULL)を発生させます。 BN_印刷_fp(stdout、d>p)。

   The order of the subgroup generated by 2 is q = p - 1.

2時までに発生するサブグループの注文はq=pです--1。

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パブ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))プロトコル構造」、RFC4251、2006年1月。

   [RFC4253]      Lonvick, C., "The Secure Shell (SSH) Transport Layer
                  Protocol", RFC 4253, January 2006.

[RFC4253]Lonvick、C.、「安全なシェル(セキュアシェル (SSH))トランスポート層プロトコル」、RFC4253、2006年1月。

   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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 Press、p。 537, 1996.

Friedl, et al.              Standards Track                     [Page 8]

RFC 4419                 SSH DH Group Exchange                March 2006

フリードル、他 標準化過程[8ページ]RFC4419セキュアシェル (SSH)DHは2006年の交換行進のときに分類します。

   [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.

[ヴァン-OORSCHOT]はCryptology -EUROCRYPT96年にOorschotとP.とM.Wiener、「背の低い解説者とのディフィー-ヘルマンの主要な協定」、Advancesをバンに積みます、LNCS1070、Springer-Verlag、ページ 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.マッシー、「ディフィー-ヘルマンキーの確率分布」、AUSCRYPT92、LNCS718、Springer-Verlag、ページのProceedings 492-504, 1993.

Authors' Addresses

作者のアドレス

   Markus Friedl
   EMail: markus@openbsd.org

マーカスフリードルEMail: markus@openbsd.org

   Niels Provos
   EMail: provos@citi.umich.edu

ニールズProvosはメールします: provos@citi.umich.edu

   William A. Simpson
   EMail: wsimpson@greendragon.com

ウィリアムA.シンプソンメール: wsimpson@greendragon.com

Friedl, et al.              Standards Track                     [Page 9]

RFC 4419                 SSH DH Group Exchange                March 2006

フリードル、他 標準化過程[9ページ]RFC4419セキュアシェル (SSH)DHは2006年の交換行進のときに分類します。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

Copyright(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Friedl, et al.              Standards Track                    [Page 10]

フリードル、他 標準化過程[10ページ]