さっぱり、わからない。おそらく、恥ずかしいタイトルになっているのだろうが、全くわからないのだから仕方がない。ここ数日、電車の中では、次の資料をひたすら読んでいた。ちなみに、どちらもとても読みやすい。そこは、助かった。
経緯。誰が管理している、どんなシステムなのか、それはよくわからないのだが、次のような質問がやってきた。枝葉を全てとっぱらうと、そして、質問の意図を取り違えていなければ、まぁこういうことだ。
「暗号危殆化*1に対する影響がどんなものなのか知りたい。クライアントとサーバ間の SSL/TLS 通信で、どのような暗号技術が使われているのか教えてほしい」と。具体的には、「サーバ側にデプロイされた『サーバ証明書』と、サーバ側で設定された『暗号スイート』の情報を渡すから、使われうる『アルゴリズム』と『鍵長』を調べてほしい」と。
もちろん（？）私は、暗号学は素人だし、SSL/TLS についても、詳しいわけではない。10 年前に「マスタリングTCP/IP SSL/TLS編」を読んだっきりだ。
「暗号スイート」とは、SSL/TLS 通信で使う暗号の種類の組み合わせのこと。通信を始める際の「ハンドシェイク（HandShake プロトコル）」で、クライアントとサーバとで、やりとりされる（他にも、いくつかの情報がやりとりされる）。まず、クライアントが、対応可能な暗号スイートを送信し（ClientHello）、サーバが、決定した暗号スイートを応答する（ServerHello）。
暗号スイートの具体例を見た方が早い。こんな感じ。
暗号スイート TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
| 鍵交換 | 署名（認証） | 暗号化 | ハッシュ |
|---|---|---|---|
| ECDHE | ECDSA | AES-GCM 256 bit | SHA-384 |
暗号スイート TLS_RSA_WITH_AES_128_CBC_SHA
| 鍵交換 | 署名（認証） | 暗号化 | ハッシュ |
|---|---|---|---|
| RSA | RSA | AES CBC モード 128 bit | SHA-1 |
で、「鍵交換」と「署名（認証）」については、鍵長（に相当する値）が示されていない。
しかし、鍵長がなければ、これらの暗号の「ビット安全性*2」がわからない。困った。それで、色々調べていた。
IPA が発行した「SSL/TLS 暗号設定ガイドライン」の「6.3.3 DHE / ECDHE での鍵長の設定状況についての注意」に、次のようにあった（「プロフェッショナル SSL/TLS」にも、似たようなことが書いてあった）。
RSA での鍵交換を行う場合にはサーバ証明書に記載された公開鍵を使うことになっており、本ガイドラインの発行時点では鍵長 2048 ビットの公開鍵がサーバ証明書に通常記載されている。このことは、RSA での鍵交換を行う場合、サーバ証明書を正当に受理する限り、どのサーバもブラウザも当該サーバ証明書によって利用する鍵長が 2048 ビットにコントロールされていることを意味する。
https://www.ipa.go.jp/files/000045645.pdf
RSA での鍵交換に関しては、サーバ証明書の発行時に利用する鍵長を正しく決め、その鍵長に基づくサーバ証明書を発行してもらえばよく、ほとんどの場合、サーバやブラウザ等に特別な設定をする必要はない。
(途中略)
DHE、ECDH/ECDHE については、利用する鍵長がサーバ証明書で明示的にコントロールされるのではなく、個々のサーバやブラウザでの鍵パラメータの設定によって決められる。このため、どの鍵長が利用されるかは、使用する製品での鍵パラメータの設定状況に大きく依存する。
なるほど。鍵交換については、ほぼほぼ解決。まず、RSA であれば、サーバ証明書にひきづられることになると。そして、DHE、ECDH/ECDHE の場合は、少々やっかいだと。
DH パラメータについては、けっこう情報があった。例えば、Apache HTTP Server の古い（2.4.7 以前の）バージョンでは、DH パラメータは 1024 ビット固定で、ユーザは変更できないようだ。
そして、わからないことは、「DSA とか ECDSA の鍵長（に相当する値）がどうやったらわかるのか？」ということに。それで、このエントリは、こんなタイトルになった。ていうか、DSA とか ECDSA とか、ぜんぜん知らない。そこからか。
進展があったら、ココに追記する。
