標準的な操作に固執し、LUKS の機能をまったく必要としない場合、専門家ではない私はどのようなリスクを負うことになりますか?
LUKS パーティションには、そのようなパーティションが ext2 や vfat などとして認識されないようにするためのヘッダーがあります。単純な dm-crypt パーティションは、たまたま暗号化されていないファイルシステムのように見えてしまう可能性があり、誤って書き込まれてファイルシステムを破壊する可能性があります。
LUKS は、正しいパスフレーズを入力したかどうかをチェックします。間違ったパスフレーズを入力すると、普通の dm-crypt はこれを認識しません。代わりに、暗号化マッピングが誤って暗号化されていないファイルシステムのように見える可能性があり、誤って書き込まれてデータが破壊される可能性があります。
LUKS は使用される暗号化のタイプを保存しますが、dm-crypt は毎回同じオプションを指定する必要があります。暗号化されたデバイスを一定期間使用しなかった後、パスワードの記憶にいくつかのギャップがあり、暗号化オプションも忘れていたことが判明した場合は、二重にうんざりしています (これは私が個人的に経験したことです)。 LUKS が存在する前に、暗号化されたデータはそれほど重要ではなかったので、1 時間ほど入力に失敗した後、再フォーマットしました)。
また、cryptsetup の開発中に essiv が は dm-crypt のデフォルトではなく、LUKS のデフォルトであり、あなたが読んでいるドキュメントはそれをほのめかすことを意図している可能性があります.
最後に、LUKS のいくつかのオプションは、セキュリティの観点から重要なことを行います。たとえば、gmail で認証中に眠りに落ち、誤ってドライブのパスワードを入力したとします。 dm-crypt では、デバイス全体を再暗号化せずにパスワードを変更する方法はありません (また、システム クラッシュや電源喪失イベントが発生すると、ホース システムが保証されたままになるため、その場で行うのは危険です)。 LUKS を使用すると、パスワードを変更できます。
ここで言及する必要があると思います。
cryptsetup と LUKS の問題について検索された質問のほとんどは、LUKS パーティションの開始部分である LUKS ヘッダーに損傷を与えた人々からのものです。 LUKS ヘッダーが失われたり破損したりした場合 (これは思ったよりも頻繁に発生します)、キーを持っていてもデータを回復することは不可能です!このような惨めな状況に直面する前に、LUKS セキュリティ モデルによって課せられる問題と制限を理解していることを確認してください。
それは質問に正確に答えないかもしれません.なぜプレーンな dm-crypt は専門家だけのものなのですか?しかし、LUKS を使用して上記のシナリオを経験し、多くのユースケースで単純な dm-crypt がはるかに優れていることに気付いた場合、一部の人々の観点からは、あなたは「専門家」です。確実に暗号化します (そしてパスワード ハッシュを行います)。何をしているのかわかっている場合は、暗号化パラメーターを自分に合ったものに変更できます。
専門のシステム運用者は、LUKS ヘッダーがないため、多くのツールがドライブが暗号化されていることを認識できないことを理解する必要があります。一部の人にとって、それは価値のある機能です。誰もが暗号化されていることを知っていて、暗号名とモード (キーなしで有効な/バックアップ LUKS ヘッダーから簡単に取得できる) を知っている場合、わざわざ何かを暗号化する必要はありません。多くの場合、LUKS は安全性と信頼性がはるかに低くなります。
Atsby は、aes cbc (essiv なし) は安全でないと見なされるという点で、プレーンな dm-crypt の別の古いビューに触れました。それは専門家の暗号学者のものです。これは、私見です。ファイルベースのファイルシステム暗号化に ESSIV を使用した XTS と AES-CBC の比較