Re: A question on an article dealing with pass phrase and keys

On 29.08.2008, hayes.gr@xxxxxxxxx <hayes.gr@xxxxxxxxx> wrote:
I was reading the page below.
http://www.interhack.net/people/cmcurtin/snake-oil-faq.html
In the section Keys vs. Passphrases He mentions using a hashing
routine to change a pass phrase in to a key.

I have an issue with this. The hashing system is going to convert the
same input always into the same out put.
So is that not just adding another step to the encryption routine.

So big deal now someone using brute force still tries alpha numeric
first and it goes through the hash function first.
So it really didn't change the fact of what he was arguing about. You
are still only got a limited key size because the hash is still based
on the limits of the pass phrase.

The idea is your methods or code is known to your attacker you would
have to assume he also knows the method of hashing your key.

Or am I missing something?

Not really (though John Hadstate certainly makes some valid points in
his reply). Hashing the passphrase to produce a key will not increase
the size of the keyspace. Rather, the main reasons for doing it are:

* Most cryptosystems require keys with a fixed number of bits. A
human-memorable passphrase is likely to have very little entropy
per bit, and thus needs to be long to be secure. A hash function
allows one to take an arbitrarily long passphrase and "distill" it
into a shorter key with correspondingly more entropy per bit.

* As John notes, the hashing step adds a fixed per-key delay for an
attacker trying a brute force password guessing attack. Often,
this key setup delay can be made quite high (by using a slow hash
or, more commonly, iterating a faster one) without unduly
incoveniencing legitimate users.

* If the key is a hash of the password, a key recovery attack against
the cipher will not allow recovery of the original password unless
the hash used to derive the key is also broken (or brute forced).
This can be a useful extra layer of security, particularly as the
same methods used to slow down the key derivation (e.g. very large
number of rounds) can also make it very hard to crack.

* Tweaking the hash in various ways (e.g. HMAC) allows one to derive
multiple keys from one passphrase. While the resulting keys will
be mathematically related, with some care and a suitable secure
cryptographic hash one can make the relationship so complicated
that, in practice, one can almost regard the keys as independent.
This can be useful for various crypto applications, and certainly
safer than reusing the exact same key for multiple algorithms.

I'm sure I've left out some reasons, and I hope others will correct
any errors or omissions I've made. Anyway, IMHO the _real_ reason to
be suspicious of any crypto software that doesn't hash the key is that
it's so easy to do and buys you so much (in convenicence even when not
in security) that it would usually be stupid not to do it. Thus,
anyone designing a cryptosystem that uses a raw password as a key may
in fact be presumed stupid, or at least not at all familiar with
practical cryptography, and thus should not be assumed capable of
designing a secure cryptosystem.

--
Ilmari Karonen
To reply by e-mail, please replace ".invalid" with ".net" in address.
.

Quantcast