Open vstoykovbg opened 4 years ago
This issue has been automatically marked as "stale" because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions.
Is there any development of this feature? I think it's important, because some users may use relatively weak passwords and be at risk of brute force attacks. I recommend using by default a key stretching that take at least several seconds on a modern computer with at least 1GiB of RAM. Because most users will not change the default settings for the key stretching. When using ZFS over cryptsetup (luks) it's possible to use modern key stretching algorithms, however int's not very efficient on SSD drives because the SSD firmware can't "see" the free space.
Is there any development of this feature? I think it's important, because some users may use relatively weak passwords and be at risk of brute force attacks. I recommend using by default a key stretching that take at least several seconds on a modern computer with at least 1GiB of RAM. Because most users will not change the default settings for the key stretching. When using ZFS over cryptsetup (luks) it's possible to use modern key stretching algorithms, however int's not very efficient on SSD drives because the SSD firmware can't "see" the free space.
You can use the --allow-discards
option of cryptsetup
for trimming the free space.
I personally use this option for a really long time now... it just works ;-)
When using PBKDF2 with classic hash functions like SHA1 it is theoretically possible to use cheap ASICs for brute force dictionary attacks (because of the low RAM requirements).
The modern key derivation functions like Argon2 and Scrypt solve this issue by increasing the price of the attack.
I am using workarounds like this (external script for key derivation), but it's not practical to implement such workaround when using encrypted ZFS root filesystem.