web-dev-qa-db-ja.com

knoppix-data.aesにクリアテキストのsha1合計が存在することは、破損を示していますか？

この質問は、ライブLinuxディストリビューションKNOPPIX v6.2（2009-11-18）を使用したユーザーデータのオプションの暗号化に関するものです。これは、私が理解しているように、Debianに基づいています。

この古いバージョンはもう使用していませんが、起動プロンプトでKNOPPIX v6.2によって作成された永続データファイルknoppix-data.aesから古いデータを取得しようとしています。ファイルは4GiB未満の1バイトです。

私は、2000年代後半にさかのぼるLinux暗号化標準について知っている誰かが、このファイルに関する情報を提供できることを望んでいました（以下で説明します）。私はLinux暗号化標準にあまり精通しておらず、私が目にする無数の用語（ "LUKS"、 "dm-crypt"など）に少し圧倒されています-もしあれば、どれかはわかりません。 2000年代後半のKnoppixの私の状況に当てはまります。

明らかに、ファイル名の「.aes」はAES暗号化を示します。最初はパスワードを間違って入力しているのではないかと思っていましたが、今度はパスワードを正しく入力しようとしても無駄になる別の問題があるのではないかと思います。説明します：

16進エディタでファイルを表示すると、ファイルの先頭がファイル名とハッシュのクリアテキストリストであることがわかります。例：

f4374a5897aafd09a2439f6c3f4a961d5cc7c1a1 *autorun.bat
eaf953dce8de1442e4e32769260e22435a70f3bc *autorun.inf
(etc.)

（一例を挙げると、KNOPPIX/knoppix-logo-small.pngなど、明らかにKnoppixに関連する多くのファイルのハッシュも含まれています）

最初のバイトはプレーンテキストファイルと完全に一致しているようです/ mnt-system/KNOPPIX/sha1sums（KnoppixがインストールされているUSBドライブ上にあるため、明らかにKnoppixインストールの一部です）。その後、ヌルバイト（00）の広がりがあり、その後ランダムに意味不明になります。全体がランダムな意味不明になると思っていました。 AES暗号化のコンテキストでは、「。aes」ファイルの先頭のクリアテキストは不一致のように見えます。

テストとして、電源を切り、元のAESファイルの名前を変更してから、再起動して別のknoppix-data.aesを256 MiB、パスワード「123456789」で作成しました。これは最初にクリアテキストを含んでおらず、私はそれに書き込むことができます（そしてその後の起動で正常に復号化できます）。

しかし、この不透明なファイル形式（またはそのドキュメントがどこにあるか）についてはわかりませんが、（おそらく）AESアルゴリズムが含まれています（ただし、操作モード、キーの導出、ヘッダーなどの詳細はありません） 。特に、このクリアテキストのもの（ハッシュとファイル名）がファイルの先頭にある種のヘッダーとしてあるのは普通ですか？それとも、ファイルが何らかの理由で破損していることを示していますか（奇妙な状況でsha1sumsファイルと連結されているなど）？

答えが平文sha1の合計がそこにあるのは正常であるということである場合、それは私が平文を越えて移動するためにlosetupにオフセットを提供する必要があることを意味しますか？私は現在使用しています

echo "mypassword" | losetup -p 0 -e aes -k 256 /dev/loop2 knoppix-data.aes
mount /dev/loop2 /media/mydir/

復号化を試みるたびに再起動する必要がないようにします。これは、256 MiBテストバージョンのknoppix-data.aesで機能し、パスワードは「123456789」で、先頭にクリアテキストはありませんが、元の4 GiB =クリアテキストハッシュがあるファイル（ファイルシステムが指定されていないことについて文句を言います。これは、おそらく自動的に決定できないことを意味します。これは、おそらくクリアテキストがそこにある、またはlosetupそれを超えて移動するにはオフセットが必要なため）。

encryptionknoppix
2
Keith

まあ、腐敗が唯一の可能な説明のようです（誰かがcp file /dev/loopXまたは同様のものをしました）。 loop aesにはメタデータがないため、ファイルは全体を通してランダムである必要があります（おそらく、書き込まれたことのないセクター、つまり「空き領域」を除く）。

奇数のオフセットは必要ありません。上書きされなかった部分を復号化するために、元のオフセットを使用する必要があります。

残念ながら、loop aesはあまり一貫性のある標準ではありません。 cryptsetup FAQからのloop-aesの観察 も参照してください。

変更されたオフセットが適用される唯一のケースは、ファイルが実際にcat cleartextfile aesfile > newaesfileまたは同様のものによって生成された場合、つまり、データが全体であるがファイル内の新しいオフセットに移動された場合です。しかし、4Gシャープではなく、奇数のファイルサイズになるので、それを除外することができます。

ファイルシステムが指定されていないことについて文句を言う

それは、ファイルシステムヘッダーが上書きされた場合に予想されます。復号化された生データを調べて、意味不明なものが含まれていないかどうかを確認する必要があります。 aesファイルのクリアテキストが何であれ、どのパスワードを選択しても、復号化されたビューでは意味不明になります...

0
frostschutz