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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
