Re: eCryptfs Design Document

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux