Re: eCryptfs Design Document

[Phillip Hellewell <phillip@hellewell.homeip.net>]

> The salt in eCryptfs is 64 bits (8 octets, per the spec of the
> iterated and salted S2K; see Section 3.6.1.3 RFC 2440). Without the
> iterated hashing, the raw dictionary generation will require storage
> on the scale of 2^64 multiplied by the size of the dictionary. I think
> this is big enough to address any attacks that involve pre-computed
> dictionaries, as you have already pointed out.

I concur with Mike.  The salt is long enough to effectively thwart any
possibility of a pre-computed dictionary attack.

> The dictionary attack that I have in mind that I would like to make a
> ``bit'' harder is the dedicated attack against one particular file. If
> an attacker just wants to attack the passphrase on that file, then
> without iterated hashing, the difficulty is roughly proportional (in
> aggregate) to half size of the dictionary. If the passphrase is weak,
> then the file will likely be compromised anyway, but at least an
> iterated hash multiplies the amount of work that the dictionary
> attacker needs to do by the number of iterations.

Again I concur with Mike.  Iterative hashing is a very common technique,
and is very effective against this type of dictionary attack.  If you
hash 1000 times, then an attack that normally could check 1 million
passwords per second would now only be able to check 1000 passwords per
second.

Without iterative hashing, as computers get faster, so would dictionary
attacks, and then people would have to keep using longer and longer
passwords to be as effective.  Iterative hashing "levels the playing
field" in a way.

> Keep in mind that, for the current release of eCryptfs, the iterated
> hashing only happens once per mount, not once per file, and so there
> is very little cost to the user, and it has at least some security

Again, I agree with Mike.  The cost is extremely small, especially since
the hashing only happens once per mount.  As long as we make sure that
on an average computer it takes less than a second, or make it
configurable so the user can keep it as small as they want, then I can't
see anything but good coming from an iterative hash.

Now what would be really cool is if we could auto-configure the number
of iterations so that it always ends up taking 1/10 of a second to
perform a hash.  Then it will always hash a reasonable number of times
regardless of your computer speed.

Remeber, a user is not going to notice a 1/10 of a second pause when
they type in their password, but an attacker will definitely notice that
they are only able to guess 10 passwords per second!

Phillip

-- 
Phillip Hellewell <phillip AT hellewell.homeip.net>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/