ベンチマークに必要なのは、端末、ワークロード、測定方法、不確実性です。速そうな数字だけでは足りません。
Android 上の ML-KEM-768 について、あらゆる環境に当てはまるバッテリー消費率を根拠を持って示すことはできません。負荷は実装、端末、セッションの確立方法、鍵の更新頻度、ネットワークの挙動によって変わります。デスクトップで暗号処理のベンチマークが高速だったとしても、モバイル向けメッセージアプリ全体のバッテリー持続時間を示したことにはなりません。
この記事では、標準から計算できることと、実測が必要なことを説明します。この記事のために Livara の Android バッテリーベンチマークを実施した事実はありません。以下の手順はテスト計画であり、実測結果を主張するものではありません。
標準から分かること
ML-KEM は鍵カプセル化メカニズムです。プロトコルが対称暗号に利用できる共有秘密の確立を支援します。FIPS 203 によると、ML-KEM-768 のカプセル化鍵は 1,184 バイト、暗号文は 1,088 バイトです。この 2 つのオブジェクトを合計すると 2,272 バイトになります。
この合計はメッセージングのハンドシェイク全体のサイズではなく、ネットワーク上で追加される通信量とも限りません。証明書、署名、従来型暗号の鍵素材、フレーミング、エンコード、キャッシュ済みの鍵、再送によって、実際に送信されるバイト数は変わります。「768」はパラメーターセットの識別子であり、共有秘密の長さが 768 ビットという意味ではありません。このセットが目標とするのは NIST のセキュリティカテゴリー 3 です。
| 項目 | アルゴリズムで決まるか、実測が必要か |
|---|---|
| カプセル化鍵と暗号文の長さ | 選択した ML-KEM パラメーターセットで決まる |
| 鍵生成、カプセル化、デカプセル化の時間 | 実際の実装と端末で測定する |
| セッション確立全体のバイト数 | フレーミングと再試行を含めてプロトコルを測定する |
| エンドツーエンドの送信遅延 | アプリとネットワークを合わせて測定する |
| ワークロードごとの消費エネルギー | 条件を制御した端末レベルの実験で測定する |
負荷が生じるのはセッションごとに一度だけか
そうとは限りません。プロトコルは初期設定時だけでなく、耐量子鍵の定期更新時にも KEM を使用する場合があります。グループのメンバー変更、新しい端末、セッションの失敗、復旧によって、追加の処理が発生することもあります。適切な単位はプロトコルのイベントであり、どの会話でも KEM 操作がちょうど一度だけ行われると仮定すべきではありません。
Livara が公開している LVR1 アーキテクチャでは、通常のメッセージチェーンの処理と並行して、ML-KEM のエポックが定期的に存在することを説明しています。そのため、有用なベンチマークでは定常状態のメッセージングと鍵更新イベントの両方を扱う必要があります。耐量子処理が二度と発生しないと主張してはいけません。
保存された暗号文のバイト数だけでも、エネルギー消費についてはほとんど分かりません。パケットが 1 つ増える場合と、すでに実行中の転送に数バイト追加される場合とでは、無線通信の挙動への影響が異なる可能性があります。
再現可能な Android 測定計画
1. 環境を記録する
端末の機種、Android のビルド、アプリのバージョン、暗号ライブラリのバージョン、ビルドモード、バッテリーの状態、温度状態を記録します。ネットワークの種類と電波状況も記録してください。ベンチマークの報告書で、非公開のアカウントデータやパケットの内容を公開してはいけません。
2. 暗号プリミティブとアプリのテストを分ける
プリミティブのテストでは、鍵生成、カプセル化、デカプセル化を個別に測定します。アプリ全体のテストでは、セッションの作成、メッセージの送信、接続中断からの復旧を測定します。両方の結果がある場合はそれぞれ報告し、一方をもう一方として扱わないでください。
繰り返し試行し、最速の実行だけを選ぶのではなく、中央値や高いパーセンタイルなど、結果のばらつきを報告します。ウォームアップ、実行時コンパイル、温度上昇によるサーマルスロットリングが結果に影響することがあります。
3. 現実的なワークロードを定義する
- ダイレクトメッセージのセッションを新しく確立する。
- 確立済みのセッションで、数とサイズを固定したメッセージを送信する。
- 文書化された鍵更新の境界をまたぐ処理をテストする。
- 対応している場合は、テスト用グループでメンバーを追加または削除する。
- 同じ条件で同じ添付ファイルを送信する。
- 一定時間アプリをアイドル状態にし、バックグラウンドの挙動を別に測定する。
合成したコンテンツと、所有者が同意したテスト用アカウントを使用します。グループのテストではメンバー数を明記してください。2 人のグループで得た結果を、説明なく大規模なグループに当てはめることはできません。
4. 時間に加えてエネルギーも測定する
Android Studio の Power Profiler は、対応ハードウェア上でアクティビティと電源レールの測定値を関連付けられます。Google は、これらが端末レベルの測定であり、他のアクティビティがノイズを生むと注意喚起しています。利用できる測定方法は端末によって異なります。
画面の明るさ、バックグラウンド処理、ネットワークの条件、テスト時間を制御します。同じワークロードを繰り返し、同条件で比較してください。採用した方法で暗号処理の寄与を切り分けられない場合は、バッテリー消費のすべてを ML-KEM に帰するのではなく、その限界を明示します。
測定環境を表したイラストであり、記録されたベンチマーク結果ではありません。
有用な結果表には何を含めるべきか
| 結果の項目 | 記録する情報の例 |
|---|---|
| ワークロード | 新規セッション、確立済みセッションのメッセージング、鍵更新 |
| 環境 | 正確な端末、アプリのビルド、ネットワーク |
| 試行 | 回数とウォームアップ実行の扱い |
| 時間 | 中央値、ばらつき、単位 |
| 通信量 | 実測バイト数と再送の条件 |
| エネルギー | 測定方法、期間、不確実性 |
| 制約 | テストで切り分けられなかったもの、対象外だったもの |
測定していないセルは空欄にするか、「未測定」と記入します。相対的な割合を作り上げた説明用のエネルギー棒グラフは、根拠にはなりません。
写真や動画の場合はどうか
大きな添付ファイルでは、通常、コンテンツのブロックごとに ML-KEM を使うのではなく、対称暗号を使用します。鍵確立は初期設定に影響し得ますが、ファイル処理、ストレージ、ネットワーク転送、再試行のロジックも操作全体に影響します。それぞれの相対的な寄与は実際のワークロードで測定しなければなりません。「絶対に体感できない」という一律の主張に妥当な根拠はありません。
よくある質問
ML-KEM-768 は常に P-256 より遅いのか
すべてのライブラリやハードウェアに通用する比較結果はありません。同じ条件で同じ操作を比較したうえで、ハイブリッドプロトコル全体を別途測定してください。
APK のチェックサムは性能測定の結果を検証するのか
信頼できる参照値と比較することで、テストに使用した正確なファイルを特定できます。ただし、テスト方法、実装の安全性、エネルギー測定の妥当性を検証するものではありません。
バッテリー節約のために暗号化を無効にすべきか
裏付けのない性能上の主張を理由に、必要なセキュリティ要件を犠牲にしてはいけません。まずバッテリー消費の実際の原因を特定し、サポートされている設定やアップデートを利用してください。
