我有一个标准的设置 ecryptfs-setup-private
。我试图弄清楚(未包装的)包装的密码[UWP]是否是我唯一需要担心的问题(加密文件本身除外)。
我的理解是,eCryptfs,fnek或fekek使用的任何密钥都是通过盐化和散列来源于UWP。这是否意味着在eCryptfs的代码中某处有一些硬编码的盐,或者如果我想在另一台计算机上解密我的数据,UWP不是唯一要记住的东西?
我有一个标准的设置 ecryptfs-setup-private
。我试图弄清楚(未包装的)包装的密码[UWP]是否是我唯一需要担心的问题(加密文件本身除外)。
我的理解是,eCryptfs,fnek或fekek使用的任何密钥都是通过盐化和散列来源于UWP。这是否意味着在eCryptfs的代码中某处有一些硬编码的盐,或者如果我想在另一台计算机上解密我的数据,UWP不是唯一要记住的东西?
Answers:
好的,我想我知道答案。
我卸载私人文件夹后删除了 ~/.ecryptfs
文件夹我能够使用。恢复数据 ecryptfs-recover-private
命令。它仅询问了mount密码,然后它能够解密数据和文件名。
现在,99,99%肯定没有捕获我也检查了eCryptfs的源代码。
Ecryptfs贴装和私营部门 调用脚本 这个 要么 那个 他们都分享以下代码:
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_DEFAULT_SALT_FNEK_HEX常量,用于 ecryptfs_insert_wrapped_passphrase_into_keyring() 作为硬编码的盐值起作用。
案件结案?
编辑:我发现了这个: https://bugs.launchpad.net/ecryptfs/+bug/376580/comments/3