On Wed, May 11, 2011 at 12:35 PM, DanH <danhi...@ieee.org> wrote: > 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").
If the attacker doesn't know that the key is derived from a password, may be not. But since it's a reasonable assumption that they have seen the application, which has an 'input password to encrypt message' dialog, they probably do. And if so, it's trivial to take a dictionary and compute all keys derivable from it. Then cracking the message becomes really easy. Adding a salt and multiple iterations does make this considerably more expensive/harder. (BTW, the usual term is actually 'brute force attack', not 'trial-and-error'.) > 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. No. Increasing a *human selected* password from 6 to say 12 characters, wouldn't really increase the entropy, people are just likely to pick a longer word or append '123' to their usual password. Plus the overhead of deriving a password is hardly 'considerable', especially considering that it will be done only once on encryption/decryption. -- 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
