ecryptfs-setup-private
によって作成された標準セットアップがあります。 (ラップされていない)ラップされたパスフレーズ[UWP]が、(暗号化されたファイル自体を除いて)心配しなければならない唯一のことであるかどうかを理解しようとしました。
私の理解では、eCryptfs、fnek、またはfekekで使用されるすべてのキーは、ソルトおよびハッシュによってUWPから派生します。これは、eCryptfsのコードのどこかにハードコードされたソルトがあることを意味しますか、それとも、別のコンピューターでデータを復号化する場合に覚えておくべきことはUWPだけではないということですか?
わかりました、私は答えを知っていると思います。
プライベートフォルダをアンマウントして~/.ecryptfs
フォルダを削除した後、ecryptfs-recover-private
コマンドを使用してデータを回復することができました。マウントパスフレーズのみを要求し、データとファイル名の両方を復号化することができました。
さて、99,99%確実にキャッチがないことを確認するために、eCryptfsのソースコードもチェックしました。
Ecryptfs-mount-privatethis one または that one のようなスクリプトを呼び出し、それらはすべて次のコードを共有します。
rc = ecryptfs_read_salt_hex_from_rc(salt_hex);
if (rc) {
from_hex(salt, ECRYPTFS_DEFAULT_SALT_HEX, ECRYPTFS_SALT_SIZE);
} else
from_hex(salt, salt_hex, ECRYPTFS_SALT_SIZE);
}
-ここで ecryptfs_read_salt_hex_from_rc() 呼び出し rcryptfs_parse_rc_file() 次に、.ecryptfsrc
ファイルからソルトを読み取ろうとします。
また、そのファイルが存在しない場合、または読み取りの試行が失敗した場合は、デフォルト値の ECRYPTFS_DEFAULT_SALT_HEX が使用されます。ところで、ヘッダーファイルの次の行には、ハードコードされたソルト値として ecryptfs_insert_wrapped_passphrase_into_keyring() 関数で使用されるECRYPTFS_DEFAULT_SALT_FNEK_HEX定数があります。
名探偵コナン?
編集:私はこれを見つけました: https://bugs.launchpad.net/ecryptfs/+bug/376580/comments/