暗号化を削除しようとすると、Cryptsetup / LUKS2が私のデータを破損していました。なぜですか？
私はCryptsetup 2.3.3を使用しています。私はLUKS（幸いにも仮想マシンで）を試してみて、LUKS2暗号化パーティションにext4ファイルシステムを持っています。私は実行中のブロックデバイスから暗号化を非破壊的に削除するLUKSの機能をテストすることにしましたcryptsetup reencrypt --decrypt。分離されたヘッダーを使用しないため、デバイスからヘッダーを読み取れるようにデバイスを渡します。復号化では、「標準」警告が表示されます。
WARNING!
========
Unable to decide if device /tmp/file is activated or not.
Are you sure you want to proceed with reencryption in offline mode?
It may lead to data corruption if the device is actually activated.
To run reencryption in online mode, use --active-name parameter instead.
その後、エラーは報告されず、復号化が続行されます。これによりデータが失われます。
最初にパーティションをext4でフォーマットしたように、以前のLUKS2デバイス内のext4システムがオペレーティングシステムに表示されると予想しました。しかし、blkidパーティションはまだ TYPE="crypto_LUKS"。ところで、パスワード入力後にエラーが発生しました。
Keyslot open failed.
No usable keyslot is available.
そして、luksDumpsアクティブキーホームは表示されません。
cryptsetupが私のデータを破壊するのはなぜですか？
ベストアンサー1
cryptsetupLUKS2デバイスの復号化は正しく文書化されておらず、データの破損に役立つ可能性があるいくつかの非常に誤った設計選択が含まれています。
OPで説明されている質問の問題は、別々のcryptsetupヘッダーを使用していると仮定していますが、明示的にどこにも指定されていないことです。これらの間違いを防ぐための基本的な健全性チェックは含まれておらず、そのテストではこのケースに対処しません。
確認してみると、テストこれを行うには、すべて別々のヘッダーで生成されたデバイスを使用します。コマンドがオフライン復号化を許可していても、オンライン復号化のみをテストするようです。
別々のヘッダーを持つLUKS2デバイスで復号化をテストしました。復号化後、パーティションがext4ファイルシステムでフォーマットされていることが検出されました。
cryptsetupがデバイスにすでにヘッダーがあることを確認し、少なくともこの状況をユーザーに警告するのは簡単です。オフラインでは、暗号化されたブロックデバイスもパラメータとして渡されたかどうかを簡単に判断し、
--header正常に処理したり進行を拒否したりできます。しかし、どちらもそうではありません。
復号化（オフラインモードでのみ可能）はLUKS1で動作しますが、それを行うには（それ自体が混乱しているため）使用せず、代わりにという別のcryptsetup reencrypt --decryptコマンドを使用する必要がありますcryptsetup-reencrypt。このコマンドはデフォルトで LUKS1 をサポートしますが、LUKS2 はサポートしません。少なくとも、Fedora では、このコマンドは の一部としてパッケージ化されておらず、デフォルトではインストールされていないcryptsetup個別のパッケージとしてパッケージ化されています。cryptsetup-reencrypt
簡単に言うと：
- 2.3.3以降、LUKS2ドライブは、分離されたヘッダーを使用しない限り直接復号化できません。ヘッダーを持つデバイスを引数として渡すと
--headerエラーは発生せず、cryptsetupは自動的にデータを削除します。 - luks2からluks1に変換してから、別の
cryptsetup-reencryptコマンドを使用してパスワードを復号化できます。まだテストしていませんが、うまくいきます。
この問題をアップストリームとして報告しようとしましたが、gitlabは匿名で登録したいユーザーをブロックします。