一つ前の日記で、SSH 接続での AES-GCM の利用を勧めましたが、一部では AES-GCM は危険だと誤解している人がいるみたいなので、
少なくとも SSH での AES-GCM の利用は安全だという事を書いてみようと思います。

AES-GCM が危険だという誤解は、どうも『本当は怖いAES-GCMの話』というページの影響を受けているように思います。
この『本当は怖いAES-GCMの話』に書かれている内容自体には問題は有りません。
# タイトルが AES-GCM 全般が危険なように思わせる物になっているのは気に入りませんが
しかし、『本当は怖いAES-GCMの話』は殆どが TLS 1.2 での AES-GCM の利用について書かれており、
AES-GCM 全般、特に SSH での AES-GCM にはそのまま当て嵌められません。

数学的に安全が保証されているGCMですが、それはGCMが使うIV(初期ベクトル)が再利用されないこと、
すなわちIVがNonce(Number used once)であることが大前提となっています。この前提が崩れると
AES-GCMの安全性は大きく損なわれます。

この部分は GCM 全般について書かれています。GCM で IV (Nonce) が再利用された場合は安全性が大きく崩れるのは事実です。
しかし、これは GCM に限った話ではなく、他の (IV を使う) 暗号方式でも IV を再利用した場合は同様に安全性が損なわれます。
その為、GCM の利用時に限らず IV (Nonce) は再利用する事が無いように決める必要があります。

今回の調査で、幸いこの脆弱性の影響を受けるのは一部実装に限られており、(素のままの)OpenSSLは問題ありません。

この AES-GCM の IV 再利用の問題は、一部の実装の問題であり、正しく AES-GCM を使えば問題は無いという事ですね。
ただ、実装によっては AES-GCM で IV が再利用するがあるというのは、そのような状況が起こりえるようになっている
TLS 1.2 のプロトコルの問題とも言えます。SSH での状況については後述します。

TLSで暗号化されたデータの頭に明示的に8バイト分のIVが付与されています。当然この部分は暗号化されていないので攻撃者
からはHTTPSサーバがどのようなIVを使っているのか丸見えです。

IV 自体は(正しく運用されていれば)外部に見えても問題は有りません。しかし、IV が再利用された場合にそれを外部から
簡単に検出出来る事になるので、IV が外部に見えるという事が攻撃を行い易くしたというのは有ると思います。
SSH では通信内容には IV は含まれません。

さらなる調査結果から、７万以上のサーバが乱数を使って初期ベクトルを毎回生成しているのがわかりました。
この方式では、大量のデータの通信を行うと過去使った乱数値と同じ乱数を生成してしまう確率が格段に上昇します。

これは TLS 1.2 の AES-GCM では IV の生成方法が決まっていなかった為、大量の通信が行われる状況では問題が
発生する方法を取った実装があったという事ですね。
SSH では IV の生成方法が決まっており、実装によって問題が発生するような決め方をする事は出来ません。

乱数でNonceを生成するには時代的にもう合わなくなってきました。そのため他の実装では、通常IVにカウンター値を利用します
(Nonceは再利用されなければ予測可能であっても構わない）。この場合、IVは2^64まで一意に生成できるのでまぁ大丈夫でしょう。
OpenSSLでは一番最初の値を乱数で決め、それ以降はカウンターとしてインクリメントしていく実装になっています。

SSH での IV の生成方法は、この OpenSSL での方法に近いです。
初期値は鍵交換の結果から計算で生成され、それ以降はカウンターとしてインクリメントしていきます。
プロトコルとしてこのように決まっている為、他の方法が使えない(使おうとすると通信が行えない)ようになっています。
またカウンターが一周するはるか前に鍵の再交換によって別の鍵での通信になる為、一周して同じ値になっても問題は発生しません。
# 実際には鍵の再交換によって新しい IV の初期値が使われるようになるので、IV が一周する事は無いでしょう

このように、SSH の AES-GCM では IV が再利用される事がないような方法を使う事がプロトコルで決められているので、
特定の実装の問題を気にする事もなく安心して AES-GCM を利用する事が出来ます。