web-dev-qa-db-ja.com

「cryptsetupベンチマーク」の結果を解釈する方法は？

概要：_cryptsetup benchmark_を実行して結果を並べ替えることができますが、その解釈にガイダンスを求めます。たとえば、暗号化速度または復号化速度を重視する必要がありますか？鍵導出速度はどちらをオーバーライドする必要がありますか？そして、私のユースケースは、結果の重み付け/解釈にどのように影響しますか？

ドキュメントへのポインタは大歓迎です。私はウェブ検索を行いましたが、明確に見えるものは何も見ていません。特に、これはそうではないようです

  • a cryptsetup FAQ
  • archWiki [1]の関連セクションで議論されました

詳細：

今回はLUKS + LVM2を使用して、2007年代のラップトップにOSを再インストールする準備をしています（おそらくAESのプロセッサはサポートされていません）。 （これは、_Plain Old Partitions_が付いた残りの1つのボックスです。）シーケンスのいくつかのループを実行する時間はありません[LUKS + LVM2 + OSをインストールし、実際のディスクベンチマークを実行し、結果を測定する]。はるかに経験的なガイダンス。代わりに、_cryptsetup benchmark_を使用して、合理的な（さらには最適な:-) LUKS暗号仕様文字列を「前もって」選択しようとしていますが、「実際のストレージの暗号化速度を直接予測することはできません」[2]。 。

このボックスが_Sudo cryptsetup benchmark_を実行すると、出力が表示されます（問題にラベルを付けて分離し、速度の低下順に並べ替えた後）：

_# key derivation:
PBKDF2-sha1       557753 iterations per second
PBKDF2-sha256     356173 iterations per second
PBKDF2-ripemd160  336082 iterations per second
PBKDF2-sha512     256000 iterations per second
PBKDF2-whirlpool  112219 iterations per second

# encryption:
#  Algorithm | Key |  Encryption 
 serpent-xts   512b   144.7 MiB/s     
 serpent-xts   256b   144.0 MiB/s     
 twofish-xts   256b   132.1 MiB/s     
 twofish-xts   512b   132.0 MiB/s     
     aes-xts   256b   128.4 MiB/s     
     aes-cbc   128b   109.7 MiB/s     
 twofish-cbc   256b   108.2 MiB/s     
 twofish-cbc   128b   107.9 MiB/s     
     aes-xts   512b    96.7 MiB/s     
     aes-cbc   256b    86.5 MiB/s     
 serpent-cbc   256b    42.1 MiB/s     
 serpent-cbc   128b    42.1 MiB/s     

# decryption:
#  Algorithm | Key  | Decryption
 serpent-cbc   256b   160.0 MiB/s
 serpent-cbc   128b   159.5 MiB/s
 serpent-xts   512b   149.0 MiB/s
 serpent-xts   256b   148.4 MiB/s
 twofish-cbc   256b   142.1 MiB/s
 twofish-cbc   128b   141.6 MiB/s
 twofish-xts   256b   133.5 MiB/s
 twofish-xts   512b   133.4 MiB/s
     aes-cbc   128b   127.5 MiB/s
     aes-xts   256b   126.0 MiB/s
     aes-cbc   256b    96.0 MiB/s
     aes-xts   512b    95.2 MiB/s
_

上記の結果は

  1. 暗号化：_serpent-xts/512_が最も速く、_serpent-cbc/*_が最も遅い
  2. 復号化：_serpent-cbc/256_が最速、_serpent-xts/512_が3番目に速い
  3. キーの派生：_sha1_は_sha256_より大幅に高速です_sha512_より大幅に高速です

確かではありませんが、

  1. _sha1_は廃止されるため、今後の互換性のために、_sha1_よりも_sha256_のKDF速度の大幅な利点を軽減（ゼロに）する必要があります。
  2. 「承認されたユーザーの通常の使用例（ワークステーションでは、キー導出関数）は、セッションごとに1回だけ計算する必要があるため、[3]したがって、_sha256_のKDFの重要な利点を軽減する必要があります。 _sha512_。

具体的な質問は次のとおりです。

  1. キーの派生（|356173 - 256000| / ((356173 + 256000)/2)〜= 0.327）における_sha256_の重要な速度の利点、または_sha512_の適度な速度の利点（私はこれを想定しています）復号化と暗号化の両方でより安全ですか？

より一般的な質問は次のとおりです。

  1. ユースケースは、鍵の導出、復号化、および暗号化における速度の重要性の重みにどのように影響しますか？たとえば、ヘッドレスサーバーは、ヘッドフルワークステーションよりも復号化（または何でも）に多少の時間を費やしますか？読み取りでは復号化が行われ、書き込みでは暗号化が行われると想定していますが、使用例が読み取りと書き込みの相対的な発生率/重みにどのように影響するかはわかりません。

FWIW、私がセットアップしているボックスは、今のところ2列目のヘッドフルプロダクションボックスになるので、基本的に

  • エディターとブラウザーを実行する
  • sSH接続を行う
  • ビデオと音楽を再生する
  • linuxを試してみたい人のために貸し出します
  • 最初のストリングの生産用ラップトップにホースをかける場合は、準備ができている

（違いが生じた場合は、Debianが実行されます。）もちろん、私は一般に、パフォーマンスよりもパフォーマンスを遅くすることを優先します（信頼性は高くなります）。

さらに一般的な質問は次のとおりです。

  1. 鍵の導出、復号化、暗号化の速度の重要性を一般的にランク付けできますか？ KDFの速度はそれほど重要ではないと思います[3]。しかし、その復号化と暗号化の速度は、ほとんどのユースケースで同じ重みです。 （しかし、ICBW。）

  2. デフォルトの引数なしの_cryptsetup benchmark_の実行は[[aのみ測定]いくつかの一般的な構成] [2]であり、「他の暗号またはモードをベンチマークするには、_--cipher_および_--key-size_オプションまたはKDFテストの場合は_--hash_。 "[2]。 ArchWikiのこのセクション では、これを実行する方法についてもう少し詳しく説明していますが、どちらかのリストが1つまたは複数あることは知りません

4.1。デフォルト以外の暗号（暗号、ハッシュ、キーサイズ、モード）を_cryptsetup benchmark_に指定するための有効なオプションパラメータ。誰もがこれの決定的なドキュメントを指すことができますか？

4.2。その他、デフォルト以外の暗号技術は、現在のテクノロジーとカーネルサポートを考慮して、指定およびベンチマークする必要があります。あなたの提案は感謝します（適切なオプションパラメータも提供している場合:-)

  1. LUKSのパフォーマンスのために使用する「より良い」ツールはありますかpre- _cryptsetup benchmark_よりもチューニング？もしそうなら、何をどのように？

[1]：例： https://wiki.archlinux.org/index.php/Dm-crypt/Device_Encryption#Encryption_options_for_LUKS_mode 、 https://wiki.archlinux.org/index.php/Disk_encryption#Cryptographic_metadata

[2]：_info cryptsetup_または_man cryptsetup_を実行します

[3]：参照 https://wiki.archlinux.org/index.php/Disk_encryption#Cryptographic_metadata

luksbenchmarkcryptsetup
5
TomRoche

KDF速度は重要ですが、あなたの考えに反して、それは遅いはずです。

LUKSを使用すると、暗号化されたドライブには、デバイスの暗号化に使用される暗号化されたマスターキーを含むヘッダーが含まれます。このマスターキーは、デバイスを起動/開くときに、キースロット内のいずれかのキーを使用して復号化されます（cryptsetup luksDump /dev/sdxを使用して、LUKSヘッダーに含まれる情報を確認します。

LUKSデバイスを初めてフォーマットすると、パスフレーズ（またはキーファイル）を要求されます。次に、このパスフレーズを使用して、キースロット0に追加されるキーを作成および暗号化します。パスフレーズもハッシュされて保存されるため、デバイスを開いたときにLUKSが正しいパスフレーズを入力したかどうかを確認できます。攻撃者はより多くの組み合わせを短時間でテストできるため、高速ハッシュアルゴリズムを使用すると、パスフレーズを解読することが容易になるため、これは理解することが重要です。

したがって、最も低速で最も安全なハッシュアルゴリズム（sha512またはワールプール）を使用し、高い--iter-timeを使用する必要があります。 --iter-timeオプションを使用すると、ハッシュを1回繰り返すのにかかる時間を設定できます。反復時間が長くなる唯一の欠点は、暗号化されたデバイスを実際に開くのにそれだけ時間がかかることです。ルートデバイスで--iter-timeを10000（10秒）とすると、システムが実際の暗号化キーを取得するまでに10秒かかるため、起動を続行する前にパスワードを待機する必要があります。 。これはデバイスを開いたときに1回だけ発生するため、それ以上のパフォーマンスには影響しません。

実際の暗号化暗号では、基盤となる物理デバイスが読み取り/書き込みを実行できる速度と、マシンのワークロードの量によって異なります。暗号化/復号化はCPUによって実行されるため、最も遅いものを使用すると、同時に実行されている他のプログラムに影響を与える可能性が高くなります。現在のところ、aes-xts-plain64は最も安全なLUKS暗号と見なされているため、機密情報が非常に多い場合は、おそらくaes-xts-plain64とキーサイズ512を使用する必要があります（xtsではキーが2つに分割されるため）そのため、実際には256ビットのキーでAESを取得します）。

私があなたのセットアップについて勧告をしたとしたら、AES-128はまだ安全であると考えられているので、それは2s-10sの間の反復時間を持つハッシュアルゴリズムとしてのsha512であり、256のキーサイズでaes-xts-plain64を使用します。

5
Patrick Glandien