---

SSL/TLSのパフォーマンス測定に！openssl speedコマンド徹底入門

1. はじめに

現代のインターネットにおいて、セキュリティと信頼性はサービス提供の根幹をなす要素です。ウェブサイトの閲覧からオンラインショッピング、API連携、VPN接続に至るまで、あらゆる通信でSSL/TLSプロトコルが広く利用されています。SSL/TLSは、通信経路を暗号化し、データの盗聴や改ざんを防ぎ、通信相手の認証を行うことで、安全な通信を実現します。

しかし、SSL/TLSによる暗号化・復号化やその他の暗号処理は、特にサーバー側において無視できない計算リソースを消費します。この計算コストが大きすぎると、サービスの応答速度が低下したり、より高性能なサーバーが必要になったりするなど、パフォーマンス上の課題を引き起こす可能性があります。特にトラフィックの多いサービスや、多数のTLSセッションを同時に確立する必要があるシステムでは、このパフォーマンスへの影響は顕著になります。

サーバー管理者や開発者にとって、SSL/TLSに関連するパフォーマンスの問題を理解し、最適化することは非常に重要です。ボトルネックとなっている処理を特定し、より効率的な暗号アルゴリズムを選択したり、ハードウェアアクセラレーションを導入したりすることで、ユーザー体験を損なうことなくセキュリティを確保できます。

このようなパフォーマンス分析において、基盤となる暗号処理速度を測定するための強力なツールが、OpenSSLライブラリに付属するopenssl speedコマンドです。openssl speedは、特定の暗号アルゴリズムがCPU上でどれくらいの速度で実行できるかをベンチマークするためのコマンドであり、SSL/TLS通信における計算負荷の大部分を占める暗号処理の性能を定量的に把握することを可能にします。

この記事では、このopenssl speedコマンドの基本的な使い方から、様々なオプションを活用した詳細な測定方法、そして測定結果の具体的な解釈とパフォーマンスチューニングへの活用方法までを、網羅的に解説します。約5000語というボリュームで、初心者から経験者まで、このコマンドを深く理解し活用できるようになることを目指します。

2. SSL/TLSとパフォーマンスの基礎

openssl speedコマンドの詳細に入る前に、SSL/TLSがどのようにパフォーマンスに影響を与えるのか、その基本的な仕組みを簡単に見ていきましょう。

SSL/TLS通信は、大きく分けて以下の2つのフェーズから構成されます。

1. ハンドシェイクフェーズ:

   • クライアントとサーバーが互いに通信能力（プロトコルバージョン、サポートする暗号スイート）を確認し合います。
   • サーバーは自身の証明書をクライアントに提示し、クライアントはそれを検証します。
   • 共通鍵暗号で使用するセッション鍵を安全に生成・共有します。この過程で、公開鍵暗号（RSA, Diffie-Hellman, ECDHなど）やデジタル署名（RSA署名, ECDSA署名など）といった、計算コストの高い処理が行われます。
   • ハンドシェイクが完了すると、以降の通信で使用する共通鍵が確立されます。
   • ハンドシェイクは新しいTLSセッションが確立されるたびに発生します。TLS 1.3では、ハンドシェイクのラウンドトリップ回数が削減されるなど、パフォーマンス向上のための改良が加えられています。

2. レコードプロトコルフェーズ:

   • ハンドシェイクで確立されたセッション鍵を用いて、実際のアプリケーションデータ（HTTPリクエスト/レスポンスなど）が共通鍵暗号によって暗号化および復号化されます。
   • データの完全性を保証するために、ハッシュ関数に基づくメッセージ認証コード（MAC）や、TLS 1.2以降で広く使われる認証付き暗号（Authenticated Encryption with Associated Data, AEAD、例: AES-GCM, ChaCha20-Poly1305）が使用されます。
   • このフェーズでの計算コストは、通信されるデータ量に比例します。

パフォーマンスの観点から見ると、以下の点が重要です。

• ハンドシェイクコスト: 新しいセッション確立時に発生する公開鍵暗号処理が重い。特に、短期間に多数の新しい接続が発生する環境では、ハンドシェイクの効率が全体のパフォーマンスに大きく影響します。鍵長（RSA 2048bit vs 4096bitなど）やアルゴリズム（RSA vs ECDSA）によって計算コストが大きく異なります。
• データ処理コスト: レコードプロトコルでの共通鍵暗号化/復号化、ハッシュ計算。データ量が多いほど負荷が増大します。使用する共通鍵暗号やハッシュアルゴリズム、そして実装（OpenSSL）の効率、さらにハードウェアアクセラレーションの有無が性能を左右します。

OpenSSLは、これらの暗号処理を提供する最も広く利用されているライブラリの一つです。SSL/TLSサーバーソフトウェア（Apache, Nginx, Envoyなど）やクライアントソフトウェアは、通常、OpenSSLライブラリをバックエンドとして使用しています。openssl speedコマンドは、このOpenSSLライブラリが提供する各暗号アルゴリズムの、純粋な計算性能を測定するために設計されています。

3. openssl speedコマンドの基本

openssl speedコマンドは、OpenSSLライブラリが実装する各種暗号アルゴリズムについて、特定の環境下（CPU、OS、OpenSSLのバージョンとビルド方法など）での処理速度をベンチマークするためのツールです。主に、CPU上で実行される純粋な暗号計算の性能を測定します。

3.1. コマンドの実行形式と目的

openssl speedコマンドの基本的な実行形式は以下の通りです。

bash
openssl speed [options] [algorithms...]

• options: 測定方法を制御するための様々なオプションを指定します。
• algorithms: 測定したい特定の暗号アルゴリズム名を指定します。省略した場合、openssl speedはデフォルトで様々な一般的なアルゴリズムを測定します。

目的は、特定のハードウェアとソフトウェアの組み合わせにおいて、各暗号アルゴリズムがどれくらいの速度で処理できるかを定量的に把握することです。これにより、以下のことが可能になります。

• 異なるサーバーハードウェア間での暗号処理性能の比較。
• OSやOpenSSLのバージョン、ビルドオプションが性能に与える影響の評価。
• 特定の暗号アルゴリズム間の相対的な性能比較。
• ハードウェアアクセラレーション（AES-NI, AVX命令セットなど、または専用暗号チップ）の効果の確認。

3.2. 基本的な使い方 (openssl speed 引数なし)

最もシンプルな使い方は、引数なしでopenssl speedを実行することです。

bash
openssl speed

このコマンドを実行すると、openssl speedは自動的にOpenSSLがサポートするいくつかの代表的な共通鍵暗号、ハッシュ関数、公開鍵暗号アルゴリズムを選択し、それぞれについてベンチマークを実行します。

出力は通常、以下のような形式になります（実際の出力はOpenSSLのバージョンや環境によって異なります）。

“`
You have chosen to measure the speed of the OpenSSL’s EVP library.
You have chosen to measure the speed of the OpenSSL’s Digest library.
You have chosen to measure the speed of the OpenSSL’s Cipher library.
You have chosen to measure the speed of the OpenSSL’s Public Key library.
The test will run for 3 seconds.

Doing aes-128 cbc for 3s on 16 size blocks…
…
Doing aes-256 cbc for 3s on 16 size blocks…
…
Doing sha256 for 3s on 16 size blocks…
…
Doing rsa 2048 bits for 3s sign, 3s verify …
…
Doing ecdsa prime256v1 for 3s sign, 3s verify …
…

OpenSSL 1.1.1k 25 Mar 2021
built on: Thu Mar 25 07:41:47 2021 UTC
options: …
compiler: …
The ‘numbers’ are in 1000 bytes per second computed from the time
taken to transform an 8192 byte block.

type bytes speed
aes-128-cbc 8192 150234.88k
aes-192-cbc 8192 134587.15k
aes-256-cbc 8192 121029.22k
…
sha1 8192 300458.80k
sha256 8192 240550.76k
sha512 8192 170890.85k
…
rsa 2048 bits 0.000004s 0.000005s
rsa 4096 bits 0.000025s 0.000095s
dsa 2048 bits 0.000011s 0.000016s
dh 2048 bits 0.000027s 0.000027s
ecdh prime256v1 0.000003s 0.000003s
ecdsa prime256v1 0.000003s 0.000004s
…

You may need to rerun this command multiple times to get reliable results.
“`

3.3. 出力結果の読み方

出力には大きく分けて2つのセクションがあります。

1. テスト実行中の進行表示: “Doing algorithm for Ns on M size blocks…” のような形で、現在実行しているテストとその条件（アルゴリズム、測定時間、ブロックサイズ）が表示されます。
2. サマリー結果: テスト完了後、測定されたアルゴリズムごとの速度が表形式で表示されます。

サマリー結果の表形式は、アルゴリズムの種類によって少し異なります。

• 共通鍵暗号とハッシュ関数:
  Type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128 cbc 128915.50k 148136.11k 154059.52k 155498.16k 156487.74k 156684.20k
sha256 65080.79k 130629.72k 195884.19k 229713.15k 242343.83k 242630.23k

  • Type: アルゴリズム名（例: aes-128 cbc, sha256）。
  • ヘッダー行 (16 bytes, 64 bytes, …): 測定に使用したデータブロックのサイズ。openssl speedはデフォルトでいくつかの異なるブロックサイズでテストを実行します。これは、暗号処理の性能がデータサイズに依存するためです。特に小さなデータではアルゴリズムの初期化や処理ごとのオーバーヘッドが支配的になり、大きなデータではスループットが重要になります。
  • 表の値: 各ブロックサイズでの処理速度です。単位は通常 キロバイト/秒 (kbytes/sec) または メガバイト/秒 (Mbytes/sec) で表示されます (k や M という接尾辞が付きます)。これは「1秒間に何キロバイト/メガバイトのデータをそのアルゴリズムで処理できるか」を示します。

• 公開鍵暗号:
  rsa 2048 bits 0.000004s 0.000005s
rsa 4096 bits 0.000025s 0.000095s
dsa 2048 bits 0.000011s 0.000016s
dh 2048 bits 0.000027s 0.000027s
ecdh prime256v1 0.000003s 0.000003s
ecdsa prime256v1 0.000003s 0.000004s

  • Type: アルゴリズム名と鍵長または曲線名（例: rsa 2048 bits, ecdsa prime256v1）。
  • 表の値: 公開鍵暗号の場合は、通常 1回の操作にかかる平均時間（秒） で表示されます（例: 0.000004s）。多くの場合、署名/暗号化と検証/復号化の速度が並んで表示されます。上記の例では、最初の秒数が署名/暗号化、次の秒数が検証/復号化に対応することが多いです（表示される列数はアルゴリズムによって異なります）。
  • この秒数から、1秒あたりの操作数 (operations per second, ops/sec) を計算することもできます。たとえば、操作に0.000004秒かかる場合、1秒あたり 1 / 0.000004 = 250,000 ops/sec となります。公開鍵暗号の性能は、データ量ではなく操作回数に依存するため、ops/sec または秒/ops という単位が適しています。

基本的なopenssl speedコマンドの実行は、その環境におけるOpenSSLの暗号処理性能の全体像を素早く把握するのに役立ちます。しかし、より詳細な分析や特定のアルゴリズムの性能比較を行いたい場合は、様々なオプションを指定する必要があります。

4. openssl speedコマンドのオプション詳細

openssl speedコマンドには、測定対象のアルゴリズムや測定方法を細かく制御するための多数のオプションが用意されています。ここでは主要なオプションを詳しく見ていきます。

4.1. 測定対象の指定

引数なしで実行した場合、openssl speedはデフォルトのアルゴリズムセットを測定しますが、以下のオプションや引数で特定のアルゴリズムを指定できます。

• -evp ALGORITHM: OpenSSLのEVP (Enhanced Volume Protection… ではなく、EnVelope Protectionという文脈で使われることもありますが、実際には “high-level cryptographic functions” を指すことが多い) レイヤーで定義されているアルゴリズムを指定します。これはOpenSSLで推奨されるモダンなインターフェースです。多くの共通鍵暗号（AEADモード含む）、ハッシュ関数、公開鍵暗号の処理を抽象化して扱います。

  • 使い方: openssl speed -evp aes-256-gcm
  • 複数のアルゴリズムを指定する場合はスペースで区切ります: openssl speed -evp aes-256-gcm sha256
  • 利用可能なEVPアルゴリズムのリストは openssl list -evp で確認できます。
  • 例: aes-128-cbc, aes-256-gcm, chacha20-poly1305, sha256, sha512, rsa, ecdsa, ed25519 など。
  • 公開鍵アルゴリズム (rsa, ecdsa, ed25519など) を-evpで指定した場合、デフォルトの鍵長や曲線でテストが実行されます。特定の鍵長や曲線でテストしたい場合は、後述の専用オプション (-rsa, -ecdsaなど) を使用するのが一般的です。

• -cipher ALGORITHM: 特定の共通鍵暗号アルゴリズムを指定します。これはEVPレイヤーよりも低レベルなインターフェースです。

  • 使い方: openssl speed -cipher aes-256-cbc
  • 利用可能な共通鍵暗号アルゴリズムのリストは openssl list -cipher-algorithms で確認できます。
  • 例: aes-128-cbc, aes-256-gcm, chacha20, des-ede3-cbc など。現在では-evpを使う方が推奨されますが、特定の古いアルゴリズムをピンポイントで測定したい場合などに利用可能です。

• -digest ALGORITHM: 特定のハッシュアルゴリズムを指定します。これもEVPレイヤーよりも低レベルなインターフェースです。

  • 使い方: openssl speed -digest sha256
  • 利用可能なハッシュアルゴリズムのリストは openssl list -digest-algorithms で確認できます。
  • 例: sha1, sha256, sha512, md5 など。現在では-evpを使う方が推奨されます。

• 個別の公開鍵アルゴリズムオプション: 特定の公開鍵アルゴリズムと、さらに鍵長や曲線名を指定するための専用オプションがあります。

  • -rsa BITS: RSAアルゴリズムの速度を測定します。カンマ区切りで複数の鍵長を指定できます。
    • 使い方: openssl speed -rsa 2048,4096
    • 測定対象: 鍵ペア生成、署名、検証（公開鍵暗号の場合は暗号化、復号化）。
  • -dsa BITS: DSAアルゴリズムの速度を測定します。鍵長を指定します。
    • 使い方: openssl speed -dsa 2048
    • 測定対象: 鍵ペア生成、署名、検証。
  • -dh BITS: Diffie-Hellman鍵交換の速度を測定します。鍵長を指定します。
    • 使い方: openssl speed -dh 2048
    • 測定対象: 鍵ペア生成、鍵共有（agreement）。
  • -ecdh CURVE: ECDH (Elliptic Curve Diffie-Hellman) 鍵交換の速度を測定します。楕円曲線名を指定します。カンマ区切りで複数の曲線名を指定できます。
    • 使い方: openssl speed -ecdh prime256v1,secp384r1
    • 利用可能な曲線名のリストは openssl list -ec-curves で確認できます。
    • 測定対象: 鍵ペア生成、鍵共有。
  • -ecdsa CURVE: ECDSA (Elliptic Curve Digital Signature Algorithm) の速度を測定します。楕円曲線名を指定します。カンマ区切りで複数の曲線名を指定できます。
    • 使い方: openssl speed -ecdsa prime256v1
    • 利用可能な曲線名のリストは openssl list -ec-curves で確認できます。
    • 測定対象: 鍵ペア生成、署名、検証。
  • -ed25519, -ed448, -x25519, -x448: Edwards曲線DSAおよびCurve25519/448ベースの鍵交換の速度を測定します。これらのアルゴリズムは特定の曲線のみを持つため、曲線名の指定は不要です。
    • 使い方: openssl speed -ed25519 openssl speed -x25519
    • 測定対象: 鍵ペア生成、署名、検証 (EdDSA)、鍵共有 (X25519/X448)。

これらのオプションを組み合わせて、特定のアルゴリズム群のみを測定することも可能です。例えば、「AES-256-GCMとSHA-256、そしてRSA 2048bitの速度を測定したい」場合は、以下のように指定します。

bash
openssl speed -evp aes-256-gcm sha256 -rsa 2048
（注：-evpと-rsaなどの公開鍵オプションは分けて指定する必要があります）

4.2. 測定方法の指定

測定の条件や方法を制御するためのオプションです。

• -bytes N[,N...]: 共通鍵暗号およびハッシュ関数のテストで使用するデータブロックのサイズを指定します。デフォルトではいくつかの異なるサイズ（8, 16, 64, 256, 1024, 8192, 16384など）で測定されます。このオプションを使うと、特定のサイズのみを測定したり、デフォルトにはないサイズで測定したりできます。カンマ区切りで複数のサイズを指定可能です。

  • 使い方: openssl speed -bytes 4096 -evp aes-256-gcm (4096バイトブロックのみで測定)
  • 使い方: openssl speed -bytes 512,2048 -evp sha256 (512バイトと2048バイトブロックで測定)
  • このオプションは、CPUキャッシュラインサイズの影響や、様々なメッセージサイズにおけるスループット特性を詳細に分析したい場合に有用です。

• -seconds N: 各アルゴリズムの測定時間を秒単位で指定します。デフォルトは3秒です。より信頼性の高い結果を得たい場合は時間を長く設定しますが、全体の測定時間も長くなります。クイックチェックの場合は短く設定できます。

  • 使い方: openssl speed -seconds 10 (各アルゴリズムを10秒ずつ測定)

• -multi N: N個のスレッドを使用してベンチマークを実行します。CPUコア数の多い環境で、OpenSSLの並列処理性能やスケーラビリティを確認するために使用します。ただし、すべてのアルゴリズムがマルチスレッド測定に対応しているわけではありません。特に公開鍵暗号の多くのテストはシングルスレッドで実行されます。

  • 使い方: openssl speed -multi 4 (4スレッドで測定)
  • 使い方: openssl speed -multi 8 -evp aes-256-gcm (8スレッドでAES-256-GCMを測定)
  • マルチスレッドテストの結果は、CPUコア数に対して性能がどの程度スケールするかを示しますが、これはあくまで理想的な並列計算環境での数値であり、実際のアプリケーションでのマルチスレッド性能を直接反映するものではありません。

• -engine ID: 特定のハードウェアアクセラレーションエンジン（暗号コプロセッサなど）を利用してベンチマークを実行します。OpenSSLは、様々なハードウェアやOSカーネルが提供する暗号処理機能を「エンジン」として抽象化し、利用することができます。

  • 使い方: openssl speed -engine ID ALGORITHM または openssl speed -engine ID
  • 利用可能なエンジンのリストは openssl engine コマンドで確認できます。例えば、Linuxではカーネルの暗号APIを利用するcryptodevエンジンがよく利用可能です。特定のハードウェアベンダー（Intel QATなど）は独自のエンジンを提供している場合があります。
  • 例 (Linuxのcryptodevエンジンを使う場合): openssl speed -engine cryptodev -evp aes-256-gcm
  • エンジンを利用するためには、そのエンジンが適切にインストール・設定されている必要があります。多くの場合、エンジンを指定しない場合は、CPUの命令セット（AES-NIなど）による最適化が利用されます。-engineオプションを使うことで、CPU命令セットによる最適化 vs 特定のハードウェアエンジン の性能比較が可能です。

• -elapsed: 各アルゴリズムのテストに実際に費やされた経過時間を表示します。デフォルトの-secondsオプションは各アルゴリズムごとにCPU時間を測定しようとしますが、-elapsedは壁時計時間で測定します。システムに他のプロセスが実行されている場合など、実際のタスク完了時間を知りたい場合に役立ちます。

• -mr: 出力形式をマシンリーダブル（Machine Readable）な形式にします。スクリプトなどから結果をパースして利用する場合に便利です。出力形式はCSVに似ていますが、詳細な仕様はOpenSSLのバージョンによって異なる場合があります。

  • 使い方: openssl speed -mr -evp aes-256-gcm
  • 出力例 (抜粋):
    # TYPE cipher
# evp aes-256-gcm
# bytes 8 16 64 256 1024 8192 16384
aes-256-gcm 8 163302.51k 268529.25k 338023.94k 368500.95k 381809.19k 383091.63k
aes-256-gcm 16 ...
...
# TYPE public
# evp rsa
# bits 2048
rsa 2048 bits public 0.000004s 0.000005s
# bits 4096
rsa 4096 bits public 0.000025s 0.000095s

• -decrypt, -encrypt: 対称暗号の速度を測定する際に、復号化のみ、または暗号化のみを測定します。デフォルトでは両方が測定されます。通常は両方測定で問題ありませんが、特定のユースケース（例: TLSサーバーは主に復号化と暗号化の両方を行いますが、特定のアプリケーションでは一方のみが多いなど）に合わせて個別に測定したい場合に利用できます。

• -timing-precision N: 測定の精度を制御します。デフォルト値で多くの場合は十分です。

これらのオプションを適切に組み合わせることで、非常に詳細なパフォーマンス分析を行うことができます。

5. 具体的な測定例と結果の解釈

ここでは、いくつかの具体的な測定例とその結果の解釈方法を紹介します。

5.1. 基本テストと異なるブロックサイズの影響

まずは基本のopenssl speedを実行してみます。

bash
openssl speed

出力から、共通鍵暗号 (aes-128 cbcなど) やハッシュ関数 (sha256など) が、データブロックサイズが大きくなるにつれて速度が向上し、あるサイズでピークに達していることがわかります。

Type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-256 cbc 52354.82k 98124.28k 124589.41k 137895.68k 143567.09k 144102.14k
sha256 32540.39k 64589.12k 98754.60k 115402.33k 121054.98k 121189.55k

解釈:
* 小さいブロックサイズ（例: 16バイト、64バイト）での速度が比較的遅いのは、アルゴリズムの初期化処理や、処理単位ごとのオーバーヘッドが相対的に大きいためです。
* ブロックサイズが大きくなるにつれてスループットが向上するのは、パイプライン処理が効率化されたり、アルゴリズム本体の計算が支配的になったりするためです。
* あるサイズ（例: 8192バイトや16384バイト）で速度が飽和するのは、CPUの演算能力やメモリ帯域幅、CPUキャッシュサイズなどがボトルネックになるためです。OpenSSLは内部で大きなバッファを使ってデータを処理しているため、大きなブロックサイズでの測定は、まとまったデータを処理する際の実効的なスループットに近い値を示します。
* 実際のTLS通信では、レコードプロトコルで暗号化されるデータのサイズは可変です。HTTP/2や大きなファイル転送などでは大きなレコードが使われることがあり、ウェブサイトの小さなリソースを多数取得する場合は小さなレコードが多く使われます。これらの異なるデータサイズにおける性能特性を理解することは重要です。-bytesオプションで特定のサイズを測定することで、より詳細な分析が可能です。

5.2. 特定のアルゴリズムの性能比較

TLS 1.3で広く使われるAES-256-GCMとChaCha20-Poly1305の性能を比較してみましょう。

bash
openssl speed -evp aes-256-gcm chacha20-poly1305

出力例:

Type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-256-gcm 85402.11k 168502.34k 225687.90k 248950.12k 256789.45k 257890.33k
chacha20-poly1305 112350.67k 220123.55k 280567.99k 305678.11k 315789.40k 316800.55k

解釈:
* 上記の例では、ChaCha20-Poly1305がAES-256-GCMよりも高速です。
* ただし、この結果は環境に強く依存します。特に、CPUがAES-NI命令セットをサポートしている場合、AESの処理がハードウェアで高速化されるため、AES-GCMがChaCha20-Poly1305よりも大幅に高速になることが多いです。AES-NIがない環境（古いCPUや一部のARM CPUなど）では、ソフトウェア実装の効率が良いChaCha20-Poly1305がAES-GCMよりも高速になる傾向があります。
* この測定結果は、サーバーでどちらのアルゴリズムを優先的に使用するか（Cipher Suiteの設定など）を決定する際の重要な判断材料となります。例えば、古いクライアントもサポートする必要があり、かつAES-NI非対応のサーバーを使っている場合は、ChaCha20-Poly1305を優先するとパフォーマンスが向上する可能性があります。

5.3. 公開鍵暗号の速度比較 (RSA vs ECDSA)

SSL/TLSハンドシェイクの主要なコスト要因である公開鍵暗号の性能を比較します。RSA 2048/4096 bit と ECDSA P-256/P-384 曲線を測定してみましょう。

bash
openssl speed -rsa 2048,4096 -ecdsa prime256v1,secp384r1

出力例 (抜粋):

sign verify sign verify sign verify
rsa 2048 bits 0.000004s 0.000005s 0.000004s 0.000005s 0.000004s 0.000005s
rsa 4096 bits 0.000025s 0.000095s 0.000025s 0.000095s 0.000025s 0.000095s
...
sign verify sign verify sign verify
ecdsa prime256v1 0.000003s 0.000004s 0.000003s 0.000004s 0.000003s 0.000004s
ecdsa secp384r1 0.000008s 0.000012s 0.000008s 0.000012s 0.000008s 0.000012s
(注: 公開鍵暗号の出力形式はOpenSSLのバージョンによって若干異なります。上記は秒/ops形式の例です。複数列あるのは、OpenSSL 1.1.1以前で表示されていた様々なサイズの署名/検証結果の名残かもしれません)

解釈:
* 値が小さいほど高速であることを意味します（1操作にかかる時間が短い）。
* RSAは鍵長を長くすると（2048bitから4096bit）、署名/暗号化、特に検証/復号化の時間が大幅に増加していることがわかります。鍵長を倍にすると、計算量はそれ以上に増加します。
* ECDSAは、同等レベルのセキュリティ強度を持つRSA（例: ECDSA P-256はRSA 2048bit相当、ECDSA P-384はRSA 3072bit相当）と比較して、一般的に高速です。上記の例でも、RSA 2048bitよりECDSA P-256v1が高速です。
* 公開鍵暗号の署名（サーバーが証明書を提示する際など）や鍵交換（DH, ECDH）はハンドシェイク時に発生します。この部分が遅いと、TLS接続確立までの時間が長くなり、ユーザーはウェブサイトの表示遅延などを感じやすくなります。サーバー側では、多数の同時接続要求があった場合にCPUが高負荷になり、接続スループットが低下する可能性があります。
* RSA 4096bitやより大きな鍵長はセキュリティ強度は高いですが、パフォーマンスへの影響も大きくなります。セキュリティ要件とパフォーマンス要求のバランスを考慮して鍵長を選択する必要があります。ECDSAは、より短い鍵でRSAと同等以上のセキュリティ強度を提供しつつ、高速な処理が可能なため、最近のTLS設定では推奨されることが多いです。

5.4. ハードウェアアクセラレーションの効果測定

CPUにAES-NIなどの命令セットが搭載されているか、または専用の暗号コプロセッサが利用可能な場合、openssl speedでその効果を測定できます。

まず、openssl engineコマンドで利用可能なエンジンを確認します。
bash
openssl engine
(output example)
(rdrand) Intel RDRAND engine
(dynamic) Dynamic engine loading support
(cryptodev) Linux kernel cryptouser
もしcryptodevなどのエンジンが表示されたら、それを利用して速度を測定できます。

AES-256-GCMについて、エンジンなし（通常、CPUの最適化が使われる）と、cryptodevエンジンを使った場合で比較してみましょう。

bash
openssl speed -evp aes-256-gcm # 通常の測定 (CPU最適化)
openssl speed -engine cryptodev -evp aes-256-gcm # cryptodevエンジンを使った測定

出力例:

“`

openssl speed -evp aes-256-gcm

Type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-256-gcm 180540.11k 350123.55k 450678.99k 480123.45k 490567.89k 491234.56k

openssl speed -engine cryptodev -evp aes-256-gcm

(Note: cryptodev might report results differently or might not be available for all modes/sizes)
Type 8192 bytes
aes-256-gcm 550123.45k # If cryptodev is faster
“`

解釈:
* 通常測定（エンジンなし）の結果は、OpenSSLが利用可能な最も高速な方法（通常はCPU命令セットによるアセンブラ最適化）での性能を示します。もしAES-NI対応CPUであれば、ここで非常に高速な数値が得られるはずです。
* -engineオプションで特定のエンジンを指定した場合、そのエンジン経由での性能が測定されます。
* 両者を比較することで、ハードウェアアクセラレーションがどの程度有効か、そして使用しようとしているエンジンが期待通りの性能を出しているかを確認できます。上記の例では、cryptodevエンジンを使った方が高速である（または同等）ことがわかります。もしエンジンを使った方が遅い、あるいは測定できない場合は、エンジンの設定や対応状況に問題がある可能性があります。
* OpenSSLがAES-NIなどのCPU命令セットを自動的に利用しているかどうかは、openssl speedコマンドの出力ヘッダーにあるoptions:やcompiler:の行を見るか、OpenSSLのビルド設定を確認する必要があります。多くの配布版OpenSSLは、対応ハードウェアであれば自動的に利用するようにビルドされています。

5.5. マルチスレッドの効果測定

CPUコアが多い環境で、共通鍵暗号処理などが複数のコアで並列実行された場合にどの程度性能が向上するかを測定します。

例えば、4コアCPUでAES-256-GCMのマルチスレッド性能を測定してみます。

bash
openssl speed -multi 4 -evp aes-256-gcm

出力例:

“`
Doing EVP:aes-256-gcm for 3s on 8192 size blocks with 4 threads…
…
The ‘numbers’ are in 1000 bytes per second computed from the time
taken to transform an 8192 byte block.

type bytes speed
aes-256-gcm 8192 1800567.89k # Total speed across 4 threads
“`

解釈:
* -multi Nオプションで測定されるのは、N個のスレッドが並列に処理を行った場合の「合計」のスループットです。
* 上記の例で、シングルスレッド (openssl speed -evp aes-256-gcm の結果) が約 490Mbytes/sec (490567.89k) だったとすると、4スレッドで 1800Mbytes/sec (1800567.89k) という結果は、約 1800 / 490 = 3.67倍 のスケーラビリティを示しています。
* 理想的にはスレッド数に比例して性能が向上します（4スレッドなら4倍）。しかし、実際にはCPUキャッシュの共有、メモリ帯域幅の制限、OpenSSL内部のデータ構造へのアクセス競合（ロックなど）により、リニアなスケーリングは難しいことが多いです。3.67倍という結果は良好なスケーラビリティと言えます。
* この結果は、多数の同時接続を処理するTLSサーバーのスループットを推測する上で参考になります。共通鍵暗号処理がボトルネックになっている場合、CPUコア数を増やすことが有効な対策となるか、その際の性能向上率をある程度予測できます。ただし、前述の通り、これは純粋な暗号処理のスケーラビリティであり、システム全体の並列性能とは異なります。

6. 結果の分析とチューニングへの活用

openssl speedで得られた結果は、様々な角度から分析し、システムのパフォーマンスチューニングや設計判断に活用できます。

6.1. 測定結果からわかること

• CPUの純粋な暗号処理性能: 使用しているCPUが、各暗号アルゴリズムをどれくらいの速度で処理できるか。異なるCPUモデルや世代間での比較に利用できます。
• アルゴリズム間の相対的な性能: 特定のアルゴリズムセット（例: TLS 1.2でよく使われるもの vs TLS 1.3で推奨されるもの）の中で、どれが最も高速か、あるいは最も低速か。
• データサイズによる性能特性: 共通鍵暗号やハッシュ処理において、小さなデータと大きなデータでスループットがどのように変化するか。
• ハードウェアアクセラレーションの効果: CPU命令セット（AES-NIなど）や専用エンジンが、特定のアルゴリズム（主にAESやその他の対称暗号、一部のハッシュ）に対してどの程度性能向上に貢献しているか。
• マルチスレッドスケーラビリティ: CPUの複数のコアを使って暗号処理を並列実行した場合、全体のスループットがどの程度向上するか。

6.2. ボトルネックの特定

openssl speedの結果だけではシステム全体のボトルネックを特定することはできませんが、「CPU上の暗号処理がどの程度重いか」という重要な情報を提供します。

• もしopenssl speedで測定した主要な暗号アルゴリズムの速度が非常に遅い場合（特に同等のハードウェアと比較して）、CPU性能そのもの、OpenSSLのビルド設定（アセンブラコードの無効化など）、あるいはOSレベルの問題（CPUIDフラグが無効になっているなど）が考えられます。
• システムのCPU使用率が高く、かつopenssl speedで測定した暗号処理速度が絶対的に低い場合、暗号処理がボトルネックになっている可能性が高いです。
• 逆に、openssl speedで非常に高速な結果が得られているにも関わらず、TLS処理を含むアプリケーション全体のパフォーマンスが低い場合は、ネットワーク、ディスクI/O、アプリケーションコードの効率、データベースアクセス、OSのコンテキストスイッチングなど、暗号処理以外の部分にボトルネックがある可能性を探る必要があります。

6.3. アルゴリズム選択の指針

測定結果は、TLS設定においてどの暗号アルゴリズムや鍵長/曲線を選択するか、優先順位をどうするかを決める際の重要な情報源となります。

• 例えば、AES-NI対応CPUを使用しているサーバーであれば、AES-GCMが非常に高速であることがopenssl speedで確認できるため、これを最優先の暗号スイートとして設定することで、データ通信のスループットを最大化できます。
• AES-NIがない環境であれば、ChaCha20-Poly1305の方が高速な場合が多く、こちらを優先することで性能向上が期待できます。
• ハンドシェイク速度を重視する場合、ECDSAはRSAよりも高速であることが多いので、ECDSA証明書を使用し、ECDHE鍵交換を優先することで、接続確立時間を短縮できる可能性があります。ただし、これにはクライアント側の対応状況も考慮が必要です。
• 鍵長の選択もパフォーマンスに直結します。RSA 4096bitはRSA 2048bitよりもセキュリティ強度が高い一方で、署名・検証速度は著しく低下します。多くのユースケースではRSA 2048bitまたはECDSA P-256/P-384が適切なバランスを提供します。

6.4. ハードウェアアクセラレーションの有効性の確認

-engineオプションを使った測定により、特定のハードウェアアクセラレーターやOSカーネルの暗号機能がOpenSSLから正しく利用されており、期待される性能向上を実現しているかを確認できます。もし期待されるほど高速化されていない場合は、ドライバのインストール、エンジンの有効化設定、OpenSSLのビルド設定などを確認する必要があります。

6.5. OpenSSLのビルドオプションの影響

OpenSSLはコンパイル時に様々な最適化オプションやハードウェアサポートフラグを指定できます。配布パッケージとしてインストールされたOpenSSLが、使用しているハードウェアに合わせて最適化されているかを確認することは重要です。例えば、CPUの命令セット（AES-NI, AVX, ARMv8 Crypto Extensionsなど）を利用するには、通常、ビルド時に適切な設定が必要です。openssl speedの結果が、同じハードウェアの他の環境（異なるOS、別の配布版OpenSSLなど）と比較して著しく遅い場合、OpenSSLのビルドオプションが適切でない可能性が考えられます。

6.6. 実アプリケーションへの適用方法

openssl speedで得られる数値は純粋な暗号処理の理論的なピーク性能に近い値です。実際のTLSサーバーアプリケーションでは、この暗号処理に加えて、以下の要素が性能に影響します。

• TLSハンドシェイク全体の処理: 公開鍵暗号処理だけでなく、証明書検証、セッションID/TLSチケットの管理、プロトコルネゴシエーションなどが含まれます。
• ネットワークI/O: データの送受信にかかる時間。
• OSのオーバーヘッド: TCP/IPスタック処理、ソケットI/O、コンテキストスイッチング、メモリ管理。
• アプリケーションロジック: HTTPリクエスト/レスポンス処理、コンテンツ生成、データベースアクセスなど。
• 並列処理の実装: 多数の同時接続をどのように扱うか（スレッドモデル、イベント駆動モデルなど）。

したがって、openssl speedの結果だけで実アプリケーションの性能を正確に予測することはできません。しかし、以下のように活用できます。

• 相対比較: 異なるアルゴリズムやハードウェア構成間の相対的な性能差を理解し、より性能の良い選択肢を特定する。
• ポテンシャル評価: 「もし暗号処理がボトルネックならば、このCPU/このアルゴリズムを使えばこれくらいまで速くなる可能性がある」という上限値を把握する。
• 問題切り分け: 「openssl speedでは速いのに、実際のアプリケーションでは遅い」という状況であれば、ボトルネックは暗号処理以外にあると判断できる。

実アプリケーションでのパフォーマンス測定には、ApacheBench (ab), wrk, httperf, nuttcpなどのツールや、プロファイリングツール、OSの性能監視ツール（top, vmstat, iostatなど）を組み合わせて使用する必要があります。

7. openssl speedの限界と注意点

openssl speedは強力なツールですが、その測定結果を解釈する際にはいくつかの限界と注意点を理解しておく必要があります。

• 理想的な単一処理ベンチマーク: openssl speedは、主にCPU上で実行される特定の暗号アルゴリズムの計算を集中的に、かつ可能な限り高速に実行することで性能を測定します。これはシステムリソース（CPU、キャッシュ、メモリ）がほぼベンチマーク処理のために専有される、理想的な環境での測定と言えます。
• 実際のTLS通信との違い: 実際のSSL/TLS通信は、前述のようにハンドシェイクとレコードプロトコルが組み合わさり、さらにネットワークI/O、OSのスタック処理、アプリケーションロジックなどが複雑に絡み合います。openssl speedはこれらの要素（特にネットワークやOSのオーバーヘッド）をほとんど考慮しません。
• ハンドシェイク速度の直接測定ではない: 公開鍵暗号（RSA, ECDSAなど）の速度は測定できますが、これはハンドシェイクの一部要素に過ぎません。証明書検証、鍵派生、プロトコルメッセージの処理など、ハンドシェイク全体の完了速度や、秒間に処理できるハンドシェイク数を直接測定するものではありません。
• システム全体のボトルネック特定には不十分: CPU上の暗号処理性能は重要な要素ですが、ストレージI/O、ネットワーク帯域幅、メモリ容量、アプリケーションのシングルスレッド性能など、システム全体の性能に影響するボトルネックは他にも多数存在します。openssl speedの結果は、ボトルネックがCPU上の暗号処理であるかを判断する材料の一つに過ぎません。
• マルチスレッド測定の解釈: -multiオプションはOpenSSLライブラリ内部での並列処理性能を測定しますが、これは必ずしもTLSサーバーアプリケーション全体のマルチスレッド性能や同時接続処理能力を直接反映するわけではありません。アプリケーションのアーキテクチャ（プロセス/スレッドモデル、イベントモデルなど）によって、並列処理のスケーラビリティは大きく異なります。
• 測定のブレ: システム上の他のプロセスのアクティビティ、OSのスケジューリング、CPUの省電力機能などが影響し、測定結果が実行ごとに多少ブレる場合があります。重要なパフォーマンス分析を行う際は、複数回実行して平均値や安定した値を確認することが推奨されます。また、バックグラウンドで他の負荷が高い処理が実行されていないクリーンな環境で測定するのが理想的です。
• OpenSSLのバージョン依存性: サポートされるアルゴリズム、出力形式、内部実装の最適化などはOpenSSLのバージョンによって異なります。異なる環境で測定結果を比較する場合は、OpenSSLのバージョンを揃えることが重要です。

これらの限界を理解した上で、openssl speedを他のパフォーマンス測定ツールやシステム監視ツールと組み合わせて利用することで、より効果的なパフォーマンス分析とチューニングが可能になります。

8. まとめ

openssl speedコマンドは、SSL/TLS通信の基盤となる暗号処理の性能を測定するための、非常に有用で強力なツールです。CPU上での暗号化、復号化、ハッシュ計算、公開鍵暗号処理といった、計算負荷の高い操作が、特定のハードウェアとOpenSSLのバージョンにおいてどれくらいの速度で実行できるかを定量的に把握することを可能にします。

この記事では、openssl speedの基本的な使い方から始め、以下の主要なオプションについて詳細に解説しました。

• 測定対象アルゴリズムを指定する -evp, -cipher, -digest オプション、および公開鍵アルゴリズムごとの -rsa, -ecdsa, -dh などのオプション。
• 測定方法を制御する -bytes, -seconds, -multi, -engine オプションなど。

具体的な測定例を通して、異なるデータサイズでの性能特性、主要な暗号アルゴリズム間の相対的な速度差、公開鍵長や楕円曲線が性能に与える影響、そしてハードウェアアクセラレーションの効果をどのように確認するかを示しました。

得られた測定結果は、使用するハードウェアにおける暗号処理のポテンシャルを理解し、TLS設定において最適なアルゴリズムや鍵長を選択する際の重要な判断材料となります。特に、CPUが提供する命令セット（AES-NIなど）や専用暗号コプロセッサの効果を定量的に把握することは、サーバー選定やシステムチューニングにおいて非常に役立ちます。

しかしながら、openssl speedはあくまで理想的な条件下での純粋な暗号処理性能を測定するものであり、実際のTLS通信全体のパフォーマンスを直接反映するものではないという限界も理解しておく必要があります。実際のシステムでは、ネットワーク遅延、OSのオーバーヘッド、アプリケーションロジック、並列処理の実装など、様々な要素が複雑に絡み合って全体の性能が決まります。

したがって、openssl speedは、システム全体のボトルネックを特定するための唯一のツールではなく、他のシステム監視ツール、プロファイリングツール、そして実際の負荷をかけて測定するアプリケーションレベルのベンチマークツール（wrk, ApacheBenchなど）と組み合わせて利用することが最も効果的です。

SSL/TLSのパフォーマンスは、ユーザー体験、サーバーの応答性、運用コストに直結する重要な課題です。openssl speedコマンドを使いこなし、暗号処理の性能特性を深く理解することは、これらの課題に対処し、安全かつ高性能なシステムを構築・運用するための第一歩となるでしょう。定期的な測定と分析を通じて、常にシステムのパフォーマンスを最適に保つように努めましょう。

この詳細な入門記事が、皆様のSSL/TLSパフォーマンス測定とチューニングの一助となれば幸いです。

---