SSL証明書を購入する際に4096bitの証明書を買ったらCPU負荷が半端ない件

どうも何か4年に一度くらい暗号化でトラブっている開発者です。
今回は証明書の話なのですが、皆様証明書の暗号化bit数って気にされておりますでしょうか？
1024bit は既に購入ができなくなっており、今後1024bit 未満のHPは
ブラウザ側で警告を出すなどの方針をマイクロソフトは示しています。


そして現在、証明書の購入時には
2048bit or 4096bitとという実質2択の選択肢を提示されるわけです。
ここで私は思ったわけです。
新たに証明書を買うのであれば値段も変わらないので、2048bitの証明書よりも
4096bitの証明書を買ったほうが、より安全性をアピールできるのではないか？



結果
CPU使用率とトラフィック

2048bit




↓↓↓↓↓↓↓↓


4096bit





ま、まさかCPU負荷が2倍近くになるなんて予想外でした。



何か対策があるのかと思い調べてみたところ、
都市銀行やCIA, NSAですら2048bit！
一応、1024bitも未だに解読は行われておりませんし(解読は8年後くらいと予想されています)、
2048bitでも今後20年以上は解読されないと予想されています。

つまりどれだけ重要なデータを扱う機関でも
2048bit の証明証を使用しているわけです。


となると不思議に思うのが、4096bit って誰得なの？という点。


結論から言えば、暗号化は現在は1024bitあれば十分過ぎる状態で、
10年くらい破られなければ良い、という観点で見れば、
殆どのwebサイトが1300bit くらいの暗号化強度がCPU負荷的にもベストプラクティスなのでは？と思いました。

何か1024bitの次は2048bitじゃなきゃいけない理由ってあるのでしょうか？
CIAみたいな情報機関ならばともかくとして、一般人であればクレジットカードや個人情報に
そこまでの価値はないですよね。

仮に10年後に解読できたとしても
10年前のクレジットカード情報や個人情報がそこまで価値があるとも思えないですし、
費用対効果で考えれば情報は名簿屋で、お金さえ出せば最新情報が購入可能です。

私も何となく2048bitの証明書を購入しているわけですが(笑)、
検討した上でより低い、1500bitくらいの暗号化を行っている事例などがあれば教えて下さい。

今更ですがWeb負荷測定ツール abの使い方

基本的な使い方は以下のようにテストを行いたいURLに対して
リクエストを発行する。

$ ab -n 100 -c 10 https://ウェブサーバー名/test.html

-n はテストで発行するリクエストの回数でこの数値が大きければ
   より長時間テストを行うので精度は上がる。
   何かのタイミングを狙うのでなければ100で十分。
   特に本番環境に対して何かの確認を行うのであれば100以上にしてはいけない。

-c 同時に発行するリクエストの数。
   こちらが同時接続数を表すので、どれくらいの負荷に耐えられるのかは
   この数値を用いる。


実行例
$ ab -n 1000 -c 10 https://ウェブサーバー名/test.html
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking ウェブサーバー名 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Finished 1000 requests


Server Software:        Apache/2.2.3
Server Hostname:        ウェブサーバー名
Server Port:            443
SSL/TLS Protocol:       TLSv1/SSLv3,DHE-RSA-AES256-SHA,4096,256

Document Path:          /test.html
Document Length:        8592 bytes

Concurrency Level:      10
Time taken for tests:   47.588888 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      8915323 bytes
HTML transferred:       8592000 bytes
Requests per second:    21.01 [#/sec] (mean) ※ここの数値が秒間処理リクエスト数となる
Time per request:       475.889 [ms] (mean)
Time per request:       47.589 [ms] (mean, across all concurrent requests)
Transfer rate:          182.94 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      144  347 315.4    268    5541
Processing:    76  125  77.4    110    1033
Waiting:       48   92  69.8     80    1002
Total:        229  473 333.6    394    5622

Percentage of the requests served within a certain time (ms)
  50%    394
  66%    446
  75%    491
  80%    537
  90%    735
  95%    932
  98%   1264
  99%   1507
 100%   5622 (longest request)


アクセス中のサーバー側の $ vmstat 10
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0     76  96440 179424 1507060    0    0     0    52 1108  317 15  1 84  0  0
 0  0     76  96068 179424 1507080    0    0     0    22 1074  196  9  1 91  0  0
 1  0     76 100284 179424 1507100    0    0     0    38 1075  233  9  1 90  0  0
26  0     76  53556 179424 1503444    0    0     0    53 1533  336 98  2  0  0  0 #プロセスとcpuのsystemが上昇
12  0     76  56892 176776 1487420    0    0     0   109 1528  367 98  2  0  0  0 #が上昇
16  0     76  68892 176776 1487492    0    0     0    61 1572  424 98  2  0  0  0
11  0     76  73400 176780 1487548    0    0     0    73 1541  359 98  2  0  0  0


abでは問題無かったため、実運用してみたところ↓


$ vmstat 10
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0    908 100648  29800 1533076    0    0   256   228 1677 1101 65  3 32  0  0
 0  0    908 123352  29844 1535844    0    0   256    86 1699 1144 72  3 24  0  0
 0  0    908 130180  29876 1538132    0    0   205   100 1662 1090 64  4 32  0  0
 9  0    908 133224  29900 1540504    0    0   231    99 1639  998 62  3 35  0  0
18  0    908  98904  29944 1542428    0    0   154    81 1766 1127 85  4 11  0  0
 8  0    908 101620  30012 1545792    0    0   333   121 1714 1158 72  4 24  0  0
 4  0    908 109612  30060 1547788    0    0   182   214 1626 1139 70  4 26  0  0

abの場合、procやcpuが大変な状態になったのだが、
実運用してみたところ
ioの bi、boや systemの in、csが大変なことに。


更にload average 6とかの超高負荷時
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 3  0    908 340916  29040 1313884    0    0     0    83 1546 1083 78  4 18  0  0
11  0    908 344636  29064 1314032    0    0     0    81 1625 1124 88  4  8  0  0
 3  0    908 342404  29124 1314240    0    0     0   118 1550 1254 77  4 18  0  0
 3  0    908 355796  29136 1314516    0    0     0    73 1525 1050 73  3 24  0  0
 5  0    908 366212  29148 1314572    0    0     0   111 1474 1025 65  3 31  0  0
 2  0    908 368940  29208 1314756    0    0     0   159 1463 1022 64  3 33  0  0
 2  0    908 365840  29244 1314900    0    0     0   171 1476  952 66  3 30  0  0
 5  0    908 356664  29256 1315088    0    0     0    66 1495  996 66  3 31  0  0
 0  0    908 369064  29284 1315388    0    0     0    90 1531 1120 70  4 27  0  0
 3  0    908 381960  29332 1315460    0    0     0   103 1597 1166 79  4 18  0  0
 0  0    908 404156  29348 1315696    0    0     0    97 1502 1015 72  3 25  0  0
 3  0    908 392252  29400 1315912    0    0     0   164 1486  991 77  4 19  0  0
 1  0    908 403908  29424 1315940    0    0     0   112 1418  862 63  3 34  0  0
26  0    908 385432  29448 1316220    0    0     0   183 1567  928 84  4 12  0  0
 3  0    908 337196  29524 1316284    0    0     0   159 1532 1206 91  5  4  0  0
 1  0    908 356044  29540 1316552    0    0    36   120 1564 1107 77  4 18  1  0

Requests per secondが低いのでこれを10倍くらいにしたいです。
余談ですがアクセスが増大して負荷が問題になるっていうのは
エンジニアにとっては幸せな喜びなのかもしれないですね。