[android-developers] Re: hash functions

Of course, hashing a password, per se, doesn't really make it any
stronger. And doing things like using a salt don't do much if the
concern is simple trial-and-error cracking of a single encrypted
message (unless you're relying on "security by obscurity"). Salting
does help prevent known plaintext attacks and signature spoofing, but
those are not likely to be problems in low-volume messaging.
Iterating on an expensive hash can help discourage the trial-and-error
cracking attack, but it can add considerable overhead to the normal
path, and simply increasing the length of a weak password would be far
more effective.

On May 10, 5:34 pm, Bob Kerns <r...@acm.org> wrote:
> The fundamental problem with starting with a human-managed password is that
> there is not a lot of entropy -- the possible values are not distributed
> over a huge range, compared to what an attacker could try with
> trial-and-error.
>
> So just doing SHA1 or SHA256 for that matter, is not sufficient for a strong
> key generation algorithm.
>
> The first thing you need to address are dictionary attacks, where the
> attacker can pre-compute a large dictionary of keys from likely passwords.
> Here, you can inject randomness into the process. What you do is to start
> with a large random number, termed a 'salt'. This is not a secret -- you'll
> save it away in cleartext somehow, and then combine it with the user's
> password. While the attacker could afford to build a dictionary of keys
> based on passwords, a dictionary of possible salt values + passwords would
> be vastly larger.
>
> The other thing you need to do is to protect against trial-and-error
> attacks. To do this, what you do is make it expensive enough to compute the
> key that an attacker simply couldn't try enough to get anywhere. The usual
> way of doing this is to iterate some expensive function -- such as SHA1.
> More precisely, you iterate this:
>
> hash = f(hash)
>
> where f is some function that is expensive, and does not collapse the space
> of possible values into some smaller set. One way to accomplish this would
> be:
> f(hash) = hash <xor> sha1(hash).
>
> I went with SHA1 above, because I want to tie this to PBKDF2, which Nikolay
> referenced.
>
> What I outline above is roughly what PBKDF2 does for you. You can read the
> full details in rfc2898 <http://tools.ietf.org/html/rfc2898>, and I
> encourage you to do so. I did skip over a lot of detail to focus on the
> motivation and approach.
>
> So there are basically two parameters -- the salt (selected randomly) and
> the iteration count (selected to make it expensive but not too expensive).
>  iOS4 uses I believe something like 10000 iterations. Blackberry used 1, and
> was seriously pwned as a result.
>
> Together, these compensate for the narrow range of human-generated
> passwords.

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en