Michael Halcrow wrote:
The mount-wide passphrase in the user session keyring is actually not
necessary to keep around after the mount process is finished in this
release, and we will likely alter the design and implementation for
the 0.1 release to just remove it once the file key encryption key is
associated with the eCryptfs superblock object on mount.
I see, so for now you import the key from the keyring into the
superblock at mount time, but in the future you will directly use the
key from the keyring as needed?
In future releases, we will be storing multiple passphrase and public
key authentication tokens in the user's eCryptfs keyring, and so the
use of the kernel keyring will make a lot more sense. We are trying to
make things as simple as possible for the 0.1 release so as to limit
the complexity involved in analysis and debugging.
Are you saying that you salt the passphrase, hash that, then hash
the hash, then hash that hash, and so on? What good does repeatedly
hashing the hash do? Simply hashing the salted passphrase should be
sufficient to obtain a key.
This approach is only used to help make dictionary attacks against the
passphrase a bit harder.
Isn't that what adding the salt is for? You add 16 bits of salt so that
a pre hashed dictionary would require 65,536 different hashes per
passphrase permutation. That places more computation burden on
generating such a dictionary, but more importantly it places a large
storage burden on the dictionary.
Recursively hashing only places greater computation on the creation of
the dictionary, which is of no consequence as the dictionary only has to
be created once. If you want to fight dictionary attacks, you should
add a longer salt rather than recursively hash. Taking the salt from 16
bits to 32 bits also requires the attacker to compute 65,536 times more
hashes per passphrase permutation at dictionary creation time, but ALSO
requires that they store 65,536 times more hashed values in the dictionary.
Another thought that crossed my mind is that it is likely possible to
factor the recursive hash function and simplify it such that it can be
computed almost as quickly as the single hash rather than taking 65,536
times longer.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
