ECDHE-RSA-AES-GCM-SHAのハッシュは何ですか？
おそらくSHAは、共有秘密からAESキーを導出するためのものです。ハッシュはどこで使用されますか？
ECDHはECCのみを実行します（ハッシュなし）。 RSAはマスキングとパディングを行いますが、これにはネゴシエートされたハッシュは含まれませんか？
AES-GCMの場合、メッセージ間でIVやその他のものをかき混ぜる必要はありません。キーの派生がそれを使用する唯一の場所であることがわかる限り、インクリメントできます。
私はTLSとSSHを念頭に置いています。 （プロトコルの詳細が少し異なることに気づきました。ハッシュが直接または暗号スイートとネゴシエートされるRFCの読み取りを混乱させるだけですが、それが何に使用されているかは明らかではありません。）
SSLの場合、 SSL 3.0 、 TLS 1.0 、 TLS 1.1 および TLS 1.2 があります。
SSL 3.0では、内部の 擬似ランダム関数 （PRF）を使用して、共有秘密（鍵交換メカニズムから取得）を対称鍵に拡張し、その後の対称暗号化を行います。このPRFは常にMD5とSHA-1の両方を使用します。
TLS 1.0とTLS 1.1では、PRFは新しい構成に置き換えられ、MD5とSHA-1の両方を使用していると思われます。
MD5とSHA-1は、SSL 3.0、TLS 1.0、TLS 1.1でも使用され、ハンドシェイクの署名（証明書ベースのクライアント認証を使用する場合のクライアントからの署名、DHE暗号スイートを使用する場合のサーバーからの署名）を計算します;署名されているものは、SHA-1（DSA/ECDSAの場合）または both MD5とSHA-1（RSAの場合）のどちらかでハッシュされます。
また、交換されたハンドシェイクメッセージは、MD5とSHA-1の両方でハッシュされ、ハンドシェイクを終了するFinishedメッセージを計算します。 SSL 3.0の場合、2つのハッシュは「そのまま」使用されますが、TLS 1.0および1.1では、追加のPRF呼び出しが含まれます。
ハンドシェイクを超えて、アプリケーションデータは何らかの対称アルゴリズムで整合性チェックを使用して暗号化され、その整合性チェックは通常HMACを使用します（SSL 3.0の場合、HMAC派生）これは、ネゴシエートされた暗号スイートで指定されたハッシュ関数に基づいています。 「MD5」で終わる暗号スイートはその時点でMD5を使用し、「SHA」で終わる暗号スイートはSHA-1を使用します。
TLS 1.2では、状況が変わります。 PRFはまだそこにありますが、 one ハッシュ関数のみを使用し、そのハッシュ関数は暗号スイートでネゴシエートされるものです。同じハッシュ関数を使用してFinishedメッセージのハンドシェイクメッセージをハッシュします（ちなみに、埋め込みのRAM不足の実装では、実装がClientHelloおよびServerHelloが解析されるまで、使用されるハッシュ関数がわからないため、ServerHelloの開始、または一連のハッシュ関数の開始。暗号スイートが「MD5」で終わる場合、ハッシュ関数はMD5です。 「SHA」で終わる場合は、SHA-1です。 「SHA256」で終わる場合、それはSHA-256です。
[〜＃〜] gcm [〜＃〜] が使用される場合、レコードごとのHMACはありません。整合性は、GCMモード自体から取得されます。したがって、暗号スイートで指定されたハッシュ関数は、PRFおよびその他のハンドシェイク関連の使用法にのみ使用されます。
ここでトリッキーなポイント：TLS 1.2より前のTLS用の標準GCM暗号スイートはありません。 TLSのGCM暗号スイートは、 RFC 5288 で始まります。その他は RFC 5289 といくつかの後続のRFCで定義されています。現在定義されているすべての暗号スイートは、 IANAレジストリ で公開されています。すべてのGCM暗号スイートはTLS 1.2+専用であり、さらに、すべてSHA-1ではなくSHA-256およびSHA-384のいずれかを使用します。これに対応して、2013年7月現在、TLSでSHA-1とGCMの両方を使用する標準的な方法はありません。 GCM（AESまたはその他のアルゴリズムを使用）が必要な場合は、TLS 1.2が必要で、ハッシュ関数（ハンドシェイク用）はSHA-256またはSHA-384です。おそらく、SHA-512を使用した暗号スイートも定義されている可能性がありますが、これはまだ発生していません。
もちろん、すべてのルールには例外があります。 SSLの公開鍵は、 X.509証明書 を介して交換されます。これは、多くの暗号化を使用する複雑なオブジェクトであり、SHA-1またはMD5さえ潜んでいることがよくあります。しかし、これは主にTLSの範囲外であり、特に、ネゴシエートされた暗号スイートの影響は受けません。理論的には、クライアントとサーバーはサポートされているハッシュ関数をネゴシエートする可能性がありますが、実際にはサーバーはCAから取得した the 証明書を送信するため、選択肢はほとんどありません。
SSHの場合、アルゴリズムは互いに独立してネゴシエートされます。すべてを包括する暗号スイートの真の概念はありません。 RFC 4253、セクション7.1 を参照してください。 RFC 5647 は、SSHでのAES/GCMの使用を定義しますが、内部で使用されるハッシュ関数については気にしません。もちろん、GCMが使用されている場合、バルクデータ暗号化用のハッシュベースのMACはありません（それがGCMのポイントです：それは独自のMACが付属しています）が、少なくとも キーに対してハッシュ関数が内部的に使用されます派生 （SSLで「PRF」と呼ばれるものと同様）。
RFC 6239 は、いわゆる NSA Suiteに続いて、SSHのアルゴリズムの sets を定義しようとするという点でより詳細です。 B 。これは、楕円曲線Diffie-Hellman（SSL用語の「ECDHE」：SSHでは、鍵交換は常に「一時鍵」を使用する）、AES/GCM ...およびSHA-256またはSHA-384ではなく、 SHA-1。また、RFC 6239に厳密に従っている場合、SSHサーバーの公開鍵（署名に使用される永続的なもの）は、RSAではなくECDSAを使用する必要があります。
したがって、できる、少なくとも理論的にはECDHE、RSA署名、AES/GCM および SHA-1でSSHを使用しますが、 GCMでは、SHA-256またはSHA-384に切り替えることもお勧めします。 SSH実装 が実際に行うことは、正確なソフトウェアバージョン、コンパイルオプション、ローカル構成に依存する傾向があり、テストが必要です。