RFC4432 日本語訳

Network Working Group                                          B. Harris
Request for Comments: 4432                                    March 2006
Category: Standards Track

コメントを求めるワーキンググループB.ハリス要求をネットワークでつないでください: 4432 2006年3月のカテゴリ: 標準化過程

              RSA Key Exchange for the Secure Shell (SSH)
                        Transport Layer Protocol

セキュア・シェル(セキュアシェル (SSH))トランスポート層プロトコルへのRSAの主要な交換

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 key-exchange method for the Secure Shell (SSH)
   protocol based on Rivest-Shamir-Adleman (RSA) public-key encryption.
   It uses much less client CPU time than the Diffie-Hellman algorithm
   specified as part of the core protocol, and hence is particularly
   suitable for slow client systems.

このメモはRivestシャミルAdleman(RSA)公開鍵暗号化に基づくSecureシェル(SSH)プロトコルのために主要な交換メソッドを説明します。 それは、コアプロトコルの一部として指定されたディフィー-ヘルマンアルゴリズムよりはるかに少ないクライアントCPU時間を費やして、したがって、特に遅いクライアントシステムに適しています。

1.  Introduction

1. 序論

   Secure Shell (SSH) [RFC4251] is a secure remote-login protocol.  The
   core protocol uses Diffie-Hellman key exchange.  On slow CPUs, this
   key exchange can take tens of seconds to complete, which can be
   irritating for the user.  A previous version of the SSH protocol,
   described in [SSH1], uses a key-exchange method based on
   Rivest-Shamir-Adleman (RSA) public-key encryption, which consumes an
   order of magnitude less CPU time on the client, and hence is
   particularly suitable for slow client systems such as mobile devices.
   This memo describes a key-exchange mechanism for the version of SSH
   described in [RFC4251] that is similar to that used by the older
   version, and about as fast, while retaining the security advantages
   of the newer protocol.

安全なシェル(SSH)[RFC4251]は安全なリモート・ログインプロトコルです。 コアプロトコルはディフィー-ヘルマンの主要な交換を使用します。 遅いCPUの上では、この主要な交換は完成する10秒を取ることができます(ユーザにとって、いらだたしい場合があります)。 [SSH1]で説明されたSSHプロトコルの旧バージョンは、クライアントの1桁より少ないCPU時間を費やすRivestシャミルAdleman(RSA)公開鍵暗号化に基づく主要な交換メソッドを使用して、したがって、特にモバイル機器などの遅いクライアントシステムに適しています。 このメモは、より新しいプロトコルのセキュリティ上の利点を保有している間に旧式のバージョンによって使用されるそれと同様の同じくらい[RFC4251]に、同じくらいおよそ速く説明されたSSHのバージョンのために主要な交換メカニズムについて説明します。

Harris                      Standards Track                     [Page 1]

RFC 4432                  SSH RSA Key Exchange                March 2006

2006年の交換行進のときに主要なハリス標準化過程[1ページ]RFC4432セキュアシェル (SSH)RSA

2.  Conventions Used in This Document

2. 本書では使用されるコンベンション

   The key words "MUST" and "SHOULD" in this document are to be
   interpreted as described in [RFC2119].

このドキュメントのキーワードの“MUST"と“SHOULD"は[RFC2119]で説明されるように解釈されることになっています。

   The data types "byte", "string", and "mpint" are defined in Section 5
   of [RFC4251].

データ型の「バイト」、「ストリング」、および"mpint"は[RFC4251]のセクション5で定義されます。

   Other terminology and symbols have the same meaning as in [RFC4253].

他の用語とシンボルには、同じくらいが、[RFC4253]のように意味しながら、あります。

3.  Overview

3. 概要

   The RSA key-exchange method consists of three messages.  The server
   sends to the client an RSA public key, K_T, to which the server holds
   the private key.  This may be a transient key generated solely for
   this SSH connection, or it may be re-used for several connections.
   The client generates a string of random bytes, K, encrypts it using
   K_T, and sends the result back to the server, which decrypts it.  The
   client and server each hash K, K_T, and the various key-exchange
   parameters to generate the exchange hash, H, which is used to
   generate the encryption keys for the session, and the server signs H
   with its host key and sends the signature to the client.  The client
   then verifies the host key as described in Section 8 of [RFC4253].

RSA主要な交換メソッドは3つのメッセージから成ります。 サーバはクライアントへのRSA公開鍵、K_Tを送ります。(サーバはそれに秘密鍵を保ちます)。 これは唯一このSSH接続のために生成された一時的なキーであるかもしれませんかそれがいくつかの接続に再使用されるかもしれません。 クライアントは、一連の無作為のバイト、Kを生成して、K_Tを使用することでそれを暗号化して、結果をサーバに送り返します。(それは、それを解読します)。 クライアントとサーバはそれぞれK、K_T、および交換ハッシュを生成する様々な主要な交換パラメタを論じ尽くします、H、サーバは、ホストキーでHに署名して、署名をクライアントに送ります。(それは、セッションのための暗号化キーを生成するのに使用されます)。 そして、クライアントは[RFC4253]のセクション8で説明されるようにホストキーについて確かめます。

   This method provides explicit server identification as defined in
   Section 7 of [RFC4253].  It requires a signature-capable host key.

このメソッドは[RFC4253]のセクション7で定義されるように明白なサーバ識別を提供します。 それは署名できるホストキーを必要とします。

4.  Details

4. 詳細

   The RSA key-exchange method has the following parameters:

RSA主要な交換メソッドには、以下のパラメタがあります:

       HASH     hash algorithm for calculating exchange hash, etc.
       HLEN     output length of HASH in bits
       MINKLEN  minimum transient RSA modulus length in bits

計算の交換ハッシュなどのためのHASHハッシュアルゴリズム ビットのビットのMINKLENの最小の一時的なRSA係数の長さにおける、HASHのHLEN出力の長さ

   Their values are defined in Section 5 and Section 6 for the two
   methods defined by this document.

それらの値はこのドキュメントによって定義された2つのメソッドのためにセクション5とセクション6で定義されます。

   The method uses the following messages.

メソッドは以下のメッセージを使用します。

   First, the server sends:

まず最初に、サーバは発信します:

       byte      SSH_MSG_KEXRSA_PUBKEY
       string    server public host key and certificates (K_S)
       string    K_T, transient RSA public key

バイトSSH_エムエスジー_KEXRSA_PUBKEYストリングサーバの公共のホストキーと証明書(K_S)ストリングK_T、一時的なRSA公開鍵

Harris                      Standards Track                     [Page 2]

RFC 4432                  SSH RSA Key Exchange                March 2006

2006年の交換行進のときに主要なハリス標準化過程[2ページ]RFC4432セキュアシェル (SSH)RSA

   The key K_T is encoded according to the "ssh-rsa" scheme described in
   Section 6.6 of [RFC4253].  Note that unlike an "ssh-rsa" host key,
   K_T is used only for encryption, and not for signature.  The modulus
   of K_T MUST be at least MINKLEN bits long.

主要なK_Tは[RFC4253]のセクション6.6で説明された「セキュアシェル (SSH)-rsa」体系通りにコード化されます。 「セキュアシェル (SSH)-rsa」ホストキーと異なって、K_Tが署名に使用されるのではなく、暗号化にだけ使用されることに注意してください。 K_Tの係数は少なくとも長さビットのMINKLENであるに違いありません。

   The client generates a random integer, K, in the range
   0 <= K < 2^(KLEN-2*HLEN-49), where KLEN is the length of the modulus
   of K_T, in bits.  The client then uses K_T to encrypt:

クライアントは無作為の整数を生成します、K、0<=K<2の範囲^(KLEN-2*HLEN-49)で、ビットで。(そこでは、KLENがK_Tの係数の長さです)。 次に、クライアントは暗号化するK_Tを使用します:

       mpint     K, the shared secret

mpint K、共有秘密キー

   The encryption is performed according to the RSAES-OAEP scheme of
   [RFC3447], with a mask generation function of MGF1-with-HASH, a hash
   of HASH, and an empty label.  See Appendix A for a proof that the
   encoding of K is always short enough to be thus encrypted.  Having
   performed the encryption, the client sends:

暗号化は[RFC3447]のRSAES-OAEP体系通りに実行されます、HASHとMGF1のマスク世代機能、HASHのハッシュ、および空のラベルで。 Kのコード化がであることができるいつも短いという証拠のためのAppendix Aがこのようにして暗号化されているのを見てください。 暗号化を実行したので、クライアントは発信します:

       byte      SSH_MSG_KEXRSA_SECRET
       string    RSAES-OAEP-ENCRYPT(K_T, K)

_バイトSSH_エムエスジーKEXRSA_SECRETストリングRSAES-OAEP-ENCRYPT(K_T、K)

   Note that the last stage of RSAES-OAEP-ENCRYPT is to encode an
   integer as an octet string using the I2OSP primitive of [RFC3447].
   This, combined with encoding the result as an SSH "string", gives a
   result that is similar, but not identical, to the SSH "mpint"
   encoding applied to that integer.  This is the same encoding as is
   used by "ssh-rsa" signatures in [RFC4253].

RSAES-OAEP-ENCRYPTの最後の台が八重奏ストリングとして[RFC3447]における原始のI2OSPを使用することで整数をコード化することであることに注意してください。 SSH「ストリング」として結果をコード化すると結合したこれは同様の、しかし、同じでない結果を与えます、その整数に適用されたSSH"mpint"コード化に。 これは[RFC4253]で「セキュアシェル (SSH)-rsa」署名で使用される同じコード化です。

   The server decrypts K.  If a decryption error occurs, the server
   SHOULD send SSH_MESSAGE_DISCONNECT with a reason code of
   SSH_DISCONNECT_KEY_EXCHANGE_FAILED and MUST disconnect.  Otherwise,
   the server responds with:

サーバはK.を解読します。If a復号化誤りは発生します、SHOULDがSSH_DISCONNECT_KEY_EXCHANGE_FAILEDの理由コードと共にSSH_MESSAGE_DISCONNECTを送って、切断しなければならないサーバ。 さもなければ、サーバは以下で反応します。

       byte      SSH_MSG_KEXRSA_DONE
       string    signature of H with host key

KEXRSA_DONEがHの署名に通すバイトSSH_エムエスジー_はキーを接待します。

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

ハッシュHは以下の連結のHASHハッシュとして計算されます:

       string    V_C, the client's identification string
                 (CR and LF excluded)
       string    V_S, the server's identification string
                 (CR and LF 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
       string    K_T, the transient RSA key
       string    RSAES_OAEP_ENCRYPT(K_T, K), the encrypted secret
       mpint     K, the shared secret

V_Cを結んでください、クライアントの識別ストリング(CRと除かれたLF)ストリングV_S、サーバの識別ストリング(CRと除かれたLF)ストリングI_C、クライアントのSSH_エムエスジー_KEXINITストリングI_Sのペイロード、サーバのSSH_エムエスジー_KEXINITストリングK_Sのペイロード、ホストキーストリングK_T、一時的なRSA主要なストリング_RSAES_OAEP ENCRYPT。(K_T、K)、暗号化された秘密がKをmpintする、共有秘密キー

Harris                      Standards Track                     [Page 3]

RFC 4432                  SSH RSA Key Exchange                March 2006

2006年の交換行進のときに主要なハリス標準化過程[3ページ]RFC4432セキュアシェル (SSH)RSA

   This value is called the exchange hash, and it is used to
   authenticate the key exchange.  The exchange hash SHOULD be kept
   secret.

この値は交換ハッシュと呼ばれます、そして、それは、主要な交換を認証するのに使用されます。 交換はSHOULDを論じ尽くします。秘密にされてください。

   The signature algorithm MUST be applied over H, not the original
   data.  Most signature algorithms include hashing and additional
   padding.  For example, "ssh-dss" specifies SHA-1 hashing.  In such
   cases, the data is first hashed with HASH to compute H, and H is then
   hashed again as part of the signing operation.

オリジナルのデータではなく、Hの上に署名アルゴリズムを適用しなければなりません。 ほとんどの署名アルゴリズムが論じ尽くしていて追加している詰め物を含んでいます。 例えば、「セキュアシェル (SSH)-dss」はSHA-1の論じ尽くすことを指定します。 そのような場合、データは最初にHを計算するためにHASHと共に論じ尽くされます、そして、次に、Hは再び署名操作の一部として論じ尽くされます。

5.  rsa1024-sha1

5. rsa1024-sha1

   The "rsa1024-sha1" method specifies RSA key exchange as described
   above with the following parameters:

「rsa1024-sha1"メソッドは上で以下のパラメタで説明されるようにRSAの主要な交換を指定します」

       HASH     SHA-1, as defined in [RFC3174]
       HLEN     160
       MINKLEN  1024

HASH SHA-1[RFC3174]HLEN160MINKLEN1024で定義されて、

6.  rsa2048-sha256

6. rsa2048-sha256

   The "rsa2048-sha256" method specifies RSA key exchange as described
   above with the following parameters:

"rsa2048-sha256"メソッドは上で以下のパラメタで説明されるようにRSAの主要な交換を指定します:

       HASH     SHA-256, as defined in [FIPS-180-2]
       HLEN     256
       MINKLEN  2048

HASH SHA-256[FIPS-180-2]HLEN256MINKLEN2048で定義されて、

7.  Message Numbers

7. メッセージ番号

   The following message numbers are defined:

以下のメッセージ番号は定義されます:

       SSH_MSG_KEXRSA_PUBKEY  30
       SSH_MSG_KEXRSA_SECRET  31
       SSH_MSG_KEXRSA_DONE    32

_セキュアシェル (SSH)_エムエスジー_KEXRSA_PUBKEY30セキュアシェル (SSH)_エムエスジー_KEXRSA_秘密31セキュアシェル (SSH)_エムエスジーKEXRSA_、32をします。

8.  Security Considerations

8. セキュリティ問題

   The security considerations in [RFC4251] apply.

[RFC4251]のセキュリティ問題は適用されます。

   If the RSA private key generated by the server is revealed, then the
   session key is revealed.  The server should thus arrange to erase
   this from memory as soon as it is no longer required.  If the same
   RSA key is used for multiple SSH connections, an attacker who can
   find the private key (either by factorising the public key or by
   other means) will gain access to all of the sessions that used that
   key.  As a result, servers SHOULD use each RSA key for as few key
   exchanges as possible.

サーバによって生成されたRSA秘密鍵が明らかにされるなら、セッションキーは明らかにされます。 その結果、サーバは、それがもう必要でないとすぐに、メモリからこれを消すように手配するべきです。 同じRSAキーが複数のSSH接続に使用されると、秘密鍵(公開鍵を縮約するか、他の手段による)を見つけることができる攻撃者はそのキーを使用したセッションのすべてへのアクセスを得るでしょう。 その結果、サーバSHOULDはできるだけわずかな主要な交換に、主要なそれぞれのRSAを使用します。

Harris                      Standards Track                     [Page 4]

RFC 4432                  SSH RSA Key Exchange                March 2006

2006年の交換行進のときに主要なハリス標準化過程[4ページ]RFC4432セキュアシェル (SSH)RSA

   [RFC3447] recommends that RSA keys used with RSAES-OAEP not be used
   with other schemes, or with RSAES-OAEP using a different hash
   function.  In particular, this means that K_T should not be used as a
   host key, or as a server key in earlier versions of the SSH protocol.

[RFC3447]は、RSAES-OAEPと共に使用されるRSAキーが他の体系、または異なったハッシュ関数を使用するRSAES-OAEPと共に使用されないことを勧めます。 特に、これは、K_Tがホストキーとして、または、SSHプロトコルの以前のバージョンで主要なサーバとして使用されるべきでないことを意味します。

   Like all key-exchange mechanisms, this one depends for its security
   on the randomness of the secrets generated by the client (the random
   number K) and the server (the transient RSA private key).  In
   particular, it is essential that the client use a high-quality
   cryptographic pseudo-random number generator to generate K.  Using a
   bad random number generator will allow an attacker to break all the
   encryption and integrity protection of the Secure Shell transport
   layer.  See [RFC4086] for recommendations on random number
   generation.

すべての主要な交換メカニズムのように、これはクライアントによって生成された秘密(乱数K)とサーバ(一時的なRSA秘密鍵)の偶発性に関するセキュリティのためによります。 クライアントが攻撃者が悪い乱数発生器で壊すことができるK.UsingにSecureシェルトランスポート層のすべての暗号化と保全保護を生成するのに高品質な暗号の疑似乱数生成器を使用するのは、特に、不可欠です。 乱数発生で推薦に関して[RFC4086]を見てください。

   The size of transient key used should be sufficient to protect the
   encryption and integrity keys generated by the key-exchange method.
   For recommendations on this, see [RFC3766].  The strength of
   RSAES-OAEP is in part dependent on the hash function it uses.
   [RFC3447] suggests using a hash with an output length of twice the
   security level required, so SHA-1 is appropriate for applications
   requiring up to 80 bits of security, and SHA-256 for those requiring
   up to 128 bits.

使用される一時的なキーのサイズは、キーが主要な交換メソッドで生成した暗号化と保全を保護するために十分であるべきです。 これにおける推薦に関しては、[RFC3766]を見てください。 RSAES-OAEPの強さは一部それが使用するハッシュ関数の扶養家族です。 セキュリティの最大80ビットを必要とするアプリケーションに、SHA-1が適切であることで、セキュリティー・レベルの2倍の出力の長さが必要であり、それらのためのSHA-256が最大128ビットを必要とすることで、[RFC3447]は、ハッシュを使用するのを示します。

   Unlike the Diffie-Hellman key-exchange method defined by [RFC4253],
   this method allows the client to fully determine the shared secret,
   K.  This is believed not to be significant, since K is only ever used
   when hashed with data provided in part by the server (usually in the
   form of the exchange hash, H).  If an extension to SSH were to use K
   directly and to assume that it had been generated by Diffie-Hellman
   key exchange, this could produce a security weakness.  Protocol
   extensions using K directly should be viewed with extreme suspicion.

[RFC4253]によって定義されたディフィー-ヘルマン主要な交換メソッドと異なって、クライアントはこのメソッドで共有秘密キーを完全に決定できて、K.Thisが重要でないと信じられています、サーバ(通常交換ハッシュの形のH)でデータを一部提供している状態で論じ尽くされるとKが今までに使用されるだけであるので。 SSHへの拡大が直接Kを使用して、それがディフィー-ヘルマンの主要な交換で生成されたと仮定することであるなら、これはセキュリティ弱点を生産するかもしれません。 Kを使用するプロトコル拡大は極端な疑念で直接見られるべきです。

   This key-exchange method is designed to be resistant to collision
   attacks on the exchange hash, by ensuring that neither side is able
   to freely choose its input to the hash after seeing all of the other
   side's input.  The server's last input is in SSH_MSG_KEXRSA_PUBKEY,
   before it has seen the client's choice of K.  The client's last input
   is K and its RSA encryption, and the one-way nature of RSA encryption
   should ensure that the client cannot choose K so as to cause a
   collision.

この主要な交換メソッドは交換ハッシュに対する衝突攻撃に抵抗力があるように設計されています、反対側の入力のすべてを見た後にどちらの側も自由にハッシュに入力を選ぶことができないのを確実にすることによって。 サーバの最後の入力は_SSH_エムエスジーKEXRSA_PUBKEYにあります、クライアントのクライアントが最後に入力したK.の選択がKとそのRSA暗号化であると考えて、RSA暗号化の一方向本質が、クライアントが衝突を引き起こすためにKを選ぶことができないのを確実にするべき前に。

9.  IANA Considerations

9. IANA問題

   IANA has assigned the names "rsa1024-sha1" and "rsa2048-sha256" as
   Key Exchange Method Names in accordance with [RFC4250].

IANAは「[RFC4250]に従ったKey Exchange Method Namesとしてのrsa1024-sha1"と"rsa2048-sha256"」を名前に割り当てました。

Harris                      Standards Track                     [Page 5]

RFC 4432                  SSH RSA Key Exchange                March 2006

2006年の交換行進のときに主要なハリス標準化過程[5ページ]RFC4432セキュアシェル (SSH)RSA

10.  Acknowledgements

10. 承認

   The author acknowledges the assistance of Simon Tatham with the
   design of this key exchange method.

作者はこの主要な交換メソッドのデザインがあるサイモンTathamの支援を承諾します。

   The text of this document is derived in part from [RFC4253].

[RFC4253]からこのドキュメントの原本を一部得ます。

11.  References

11. 参照

11.1.  Normative References

11.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月。

   [RFC3174]     Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
                 (SHA1)", RFC 3174, September 2001.

[RFC3174]イーストレークとD.とP.ジョーンズ、「米国安全なハッシュアルゴリズム1(SHA1)」、RFC3174 2001年9月。

   [RFC3447]     Jonsson, J. and B. Kaliski, "Public-Key Cryptography
                 Standards (PKCS) #1: RSA Cryptography Specifications
                 Version 2.1", RFC 3447, February 2003.

[RFC3447] イェンソン、J.、およびB.Kaliski、「公開鍵暗号化標準(PKCS)#1:」 RSA暗号仕様バージョン2.1インチ、RFC3447、2月2003日

   [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]     Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
                 Transport Layer Protocol", RFC 4253, January 2006.

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

   [RFC4250]     Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH)
                 Protocol Assigned Numbers", RFC 4250, January 2006.

[RFC4250] レーティネンとS.とC.Lonvick、「セキュア・シェル(セキュアシェル (SSH))プロトコル規定番号」、RFC4250、2006年1月。

   [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月。

11.2.  Informative References

11.2. 有益な参照

   [SSH1]        Ylonen, T., "SSH -- Secure Login Connections over the
                 Internet", 6th USENIX Security Symposium, pp. 37-42,
                 July 1996.

[SSH1] Ylonen、T.、「セキュアシェル (SSH)--インターネットの上でログインコネクションズを保証してください」、第6USENIX Security Symposium、ページ 37-42と、1996年7月。

   [RFC3766]     Orman, H. and P. Hoffman, "Determining Strengths For
                 Public Keys Used For Exchanging Symmetric Keys",
                 BCP 86, RFC 3766, April 2004.

[RFC3766] OrmanとH.とP.ホフマン、「対称鍵を交換するのに使用される公開鍵のために強さを測定する」BCP86、RFC3766、2004年4月。

   [RFC4086]     Eastlake, D., Schiller, J., and S. Crocker, "Randomness
                 Requirements for Security", BCP 106, RFC 4086,
                 June 2005.

[RFC4086]イーストレークとD.とシラー、J.とS.クロッカー、「セキュリティのための偶発性要件」BCP106、2005年6月のRFC4086。

Harris                      Standards Track                     [Page 6]

RFC 4432                  SSH RSA Key Exchange                March 2006

2006年の交換行進のときに主要なハリス標準化過程[6ページ]RFC4432セキュアシェル (SSH)RSA

Appendix A.  On the Size of K

Kのサイズの付録A.

   The requirements on the size of K are intended to ensure that it is
   always possible to encrypt it under K_T.  The mpint encoding of K
   requires a leading zero bit, padding to a whole number of bytes, and
   a four-byte length field, giving a maximum length in bytes,
   B = (KLEN-2*HLEN-49+1+7)/8 + 4 = (KLEN-2*HLEN-9)/8 (where "/" denotes
   integer division rounding down).

Kのサイズに関する要件が、K_Tの下でそれを暗号化するのがいつも可能であることを保証することを意図します。 「Kのmpintコード化は先行ゼロビットを必要とします、バイトの整数、および4バイトの長さの分野にそっと歩いて、バイトで表現される最大の長さを与えて、B=(KLEN-2*HLEN-49+1+7)/8+4=(KLEN-2*HLEN-9)/8、(どこ、」 /、」、指示、概数に切り下げられる整数分割)

   The maximum length of message that can be encrypted using RSAEP-OAEP
   is defined by [RFC3447] in terms of the key length in bytes, which is
   (KLEN+7)/8.  The maximum length is thus L = (KLEN+7-2*HLEN-16)/8 =
   (KLEN-2*HLEN-9)/8.  Thus, the encoded version of K is always small
   enough to be encrypted under K_T.

RSAEP-OAEPを使用することで暗号化できる最大の長さに関するメッセージはバイトで[RFC3447]によってキー長で定義されます。(バイトは(KLEN+7)/8です)。 その結果、最大の長さはL=(KLEN+7-2*HLEN-16)/8=(KLEN-2*HLEN-9)/8です。 したがって、Kのコード化されたバージョンはK_Tの下で暗号化できるくらいいつも小さいです。

Author's Address

作者のアドレス

   Ben Harris
   2a Eachard Road
   CAMBRIDGE
   CB4 1XA
   UNITED KINGDOM

ベン・ハリス・2a Eachard道路ケンブリッジCB4 1XAイギリス

   EMail: bjh21@bjh21.me.uk

メール: bjh21@bjh21.me.uk

Harris                      Standards Track                     [Page 7]

RFC 4432                  SSH RSA Key Exchange                March 2006

2006年の交換行進のときに主要なハリス標準化過程[7ページ]RFC4432セキュアシェル (SSH)RSA

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)によって提供されます。

Harris                      Standards Track                     [Page 8]

ハリス標準化過程[8ページ]