web-dev-qa-db-ja.com

LUKSの場合：最も望ましい、最も安全な暗号？

LUKSを使用して2台のハードドライブを暗号化しようとしています。自分では暗号化できないので、Arch Linux wikiのガイドを使用します （こちらにあります） 。ガイドの例では、指定された暗号はaes-xts-plain 512ビットの鍵サイズ。 aes-xts-plain最良の選択ですか、それとも使用するより良い暗号がありますか？速度よりもセキュリティを優先します。

encryptionlinuxdisk-encryptionluks
22
Peter

ブロック暗号の使用法で理解する必要がある3つのコンポーネントがあり、それらはここで明示的に適用されます。

  • ブロック暗号プリミティブ。これは、よく知られているAES候補の暗号（AES、蛇、Twofish、Blowfishな​​ど）の1つかもしれません。
  • 動作モード。ブロック暗号をそのまま使用すると、ブロックごとに電子コードブックと呼ばれますが、暗号ブロックチェーンやカウンターモードなど、他にもさまざまな長所と短所があります。
  • ディスク暗号化に使用されるCBCに対して攻撃者が利用できるさまざまなフィンガープリント技術と戦う essiv などの初期化ベクトル生成スキーム。

したがって、オプションを選択すると、 aes-cbc-essiv、あなたは実際にAESを求めています。CBCモードで、ブロックごとの識別子に基づいて暗号化されたIVを使用しますが、aes-xts-plainは、XTSモードでAESを使用し、ブロックごとの情報から生成されたプレーンな古いIVを使用します。

それは、XTSが暗号化モードに組み込まれたホワイトニング（ESSIVと戦う）に対して十分な耐性があると信頼できるかどうかにかかっています。この段階では、XTSはより技術的な利点を備えたより近代的なモードですが、CBCと言うよりも暗号化テストが実施されていません。

ウィキペディアのXTSに関する注意点：

分割のため、AES 256およびAES 128暗号化を必要とするユーザーは、それぞれ512ビットおよび256ビットの鍵サイズを選択する必要があります。

このモードでは、各ブロックが目的のビットサイズのキーを使用するように、キーサイズの生成を選択する必要があります。 LUKSの情報、つまりcryptsetupでキーを分割する方法を確認していません。これは、希望する適切なレベルのセキュリティを確保するために実行したいことです。そのため、ガイドに従って、ブロックごとに256ビット暗号化が使用されています（512キーは2つの部分に分割されています）。

16
user2213

SUに関する最初の投稿で述べたように、必要なセキュリティのレベルは、攻撃者が有効な時間内にそれを壊す合理的な機会がないほど十分なセキュリティレベルでなければなりません（たとえば、個人データの場合、10年スパン）。

そのため、この例では、PCに国家機密や企業の機密データがないことを想定しているため、AES-XTS-PLAINは、攻撃者に対して妥当な時間枠で耐性があると予想されます。

8
Rory Alsop

最も好ましい暗号はaes-xts-plain64であり、デフォルトでディストリビュートワイド（RedHat、CentOS、Oracle Linux、Ubuntu）で使用されます。多くの人がaesを使用します。これは、多くのアプライアンス、アプリケーションがそれをサポートし、aesのパフォーマンスが Intelプロセッサー で加速できるためです。また、この種の高速化機能は、aesに他の暗号と比べて多くの利点をもたらします。 simple implementation of aesとhardware accelerated aesのパフォーマンス比較を読むことができます こちら 。また、aesを使用すると、広く使用されているという別の利点があるため、インターネットで攻撃が利用可能であれば、そのことをすぐに認識し、おそらく更新をすばやく取得できます。そして、aesの実装で利用可能ないくつかの受動的な攻撃があり、ディスク暗号化として ここから読み取ることができます

しかし、選択は異なる場合があります。また、暗号を選択する際は、選択する暗号がまだ危険にさらされていないことを確認する必要があります。 こちら から確認できます。 aesのような（I/Oの観点から）効率的ではないが、優れた代替手段として利用できる他の同様の暗号があります。 aesを使用する予定がない場合は、aesの後継が2つあり、これは secure thanaes is Anubis および serpent は、セキュリティのために速度を犠牲にすることができるためです。さいわい、luksで使用できます。そして、aesがaesで優先されるので、FISMAよりも国家機密を保護したい場合は十分です NIST-Special-Publication-800-53-Revision-4 。

暗号化アルゴリズムについては、私の考えではハッシュアルゴリズムについて真剣に考えるべきです。あなたがあなたの超安全なアルゴリズムより弱いハッシュを使うならば、あなたは多くを助けません。ハッシュがluks暗号化プロセスで重要な役割を果たすからです。したがって、sha1は使用しないでください。ただし、sha512は十分に安全です。ただし、 whirepool または最近のパスワードハッシュコンテストの優勝者 argon2i 。

luksに関する他の回答 から、

次のコマンドを使用して、カーネルでサポートされている暗号を一覧表示できます。

[root@arif]# ls /lib/modules/$(uname -r)/kernel/crypto/
algif_rng.ko.xz   blowfish_common.ko.xz   cmac.ko.xz               cts.ko.xz          gf128mul.ko.xz           michael_mic.ko.xz  rsa_generic.ko.xz      tgr192.ko.xz           xts.ko.xz
ansi_cprng.ko.xz  blowfish_generic.ko.xz  crc32_generic.ko.xz      deflate.ko.xz      ghash-generic.ko.xz      pcbc.ko.xz         salsa20_generic.ko.xz  twofish_common.ko.xz   zlib.ko.xz
anubis.ko.xz      camellia_generic.ko.xz  crct10dif_common.ko.xz   des_generic.ko.xz  jitterentropy_rng.ko.xz  pcrypt.ko.xz       seed.ko.xz             twofish_generic.ko.xz
arc4.ko.xz        cast5_generic.ko.xz     crct10dif_generic.ko.xz  dh_generic.ko.xz   khazad.ko.xz             rmd128.ko.xz       serpent_generic.ko.xz  vmac.ko.xz
async_tx          cast6_generic.ko.xz     cryptd.ko.xz             drbg.ko.xz         lrw.ko.xz                rmd160.ko.xz       sha512_generic.ko.xz   wp512.ko.xz
authencesn.ko.xz  cast_common.ko.xz       crypto_null.ko.xz        fcrypt.ko.xz       mcryptd.ko.xz            rmd256.ko.xz       tcrypt.ko.xz           xcbc.ko.xz
authenc.ko.xz     ccm.ko.xz               crypto_user.ko.xz        gcm.ko.xz          md4.ko.xz                rmd320.ko.xz       tea.ko.xz              xor.ko.xz

次のコマンドで、luksを使用して、使用できる暗号とハッシュとそれらのI/O比較を一覧表示できます。

[root@arif arif]# cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       289342 iterations per second for 256-bit key
PBKDF2-sha256     353293 iterations per second for 256-bit key
PBKDF2-sha512     227555 iterations per second for 256-bit key
PBKDF2-ripemd160  233224 iterations per second for 256-bit key
PBKDF2-whirlpool  236165 iterations per second for 256-bit key
argon2i       4 iterations, 917485 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id      4 iterations, 951672 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
#     Algorithm |       Key |      Encryption |      Decryption
        aes-cbc        128b       642.2 MiB/s      2495.8 MiB/s
    serpent-cbc        128b        89.3 MiB/s       542.6 MiB/s
    twofish-cbc        128b       100.4 MiB/s       343.1 MiB/s
        aes-cbc        256b       477.2 MiB/s      1979.2 MiB/s
    serpent-cbc        256b        89.3 MiB/s       538.9 MiB/s
    twofish-cbc        256b       173.3 MiB/s       343.1 MiB/s
        aes-xts        256b      1668.0 MiB/s      1664.1 MiB/s
    serpent-xts        256b       535.7 MiB/s       523.4 MiB/s
    twofish-xts        256b       332.6 MiB/s       339.8 MiB/s
        aes-xts        512b      1384.5 MiB/s      1380.7 MiB/s
    serpent-xts        512b       539.3 MiB/s       524.4 MiB/s
    twofish-xts        512b       335.0 MiB/s       340.1 MiB/s

次のコマンドで特定の暗号を比較できます。

[root@arif]# ciphers="aes-xts serpent-xts anubis-xts"

[root@arif]# echo "#     Algorithm |       Key |      Encryption |      Decryption";for i in $ciphers ; do cryptsetup benchmark --cipher $i|tail -n 1; done

#     Algorithm |       Key |      Encryption |      Decryption
        aes-xts        256b      1613.9 MiB/s      1642.8 MiB/s
    serpent-xts        256b       538.9 MiB/s       521.9 MiB/s
     anubis-xts        256b       182.0 MiB/s       182.1 MiB/s
4
Muhammad