4 ms·

This is what you really want if you care a lot about avoiding the small domain problem (brute forcing H(myguess) so that I finally find H(myguess) == password_h

by antirez 17y ago

This is what you really want if you care a lot about avoiding the small domain problem (brute forcing H(myguess) so that I finally find H(myguess) == password_hash): Just use an algorithm that is acceptably slow when used to authenticate users, but unacceptably slow when using for brute forcing. For instance HMAC(1,HMAC(2,HMAC(3,MAC(4,HMAC(..N,HMAC("yourPublicZZaaalt","yourpassword")))))) Use N big enough so that you need a few milliseconds to run this code as optimized C. If you are smart, design it so that CUDA wont help. Now you are done. Brute forcing will take just too much if the password is not too obvious. It will be still possible to test 10000 hashes in a reasonable time maybe, but forget to run John The Ripper against it.

tptacek 17y ago
Don't use HMAC, but, sure: iterate SHA1 a couple thousand times. This is the approach taken by PBKDF. A better approach is to use bcrypt or scrypt. It's not a security objective of SHA1 or HMAC-SHA1 to take a long time to run --- in fact, they have the opposite design goal. Bcrypt and scrypt have both been designed to be "cryptographically slow": speeding them up in the general case would (forgive an oversimplification) require a new result in cryptography that would be more significant than "optimizing brute force cracking".
- antirez 17y ago
  I proposed HMAC just in order to avoid that there is some strange property about H(H(H(H(H(...))) probably not true for SHA1 and many other believed secure hash functions and block cyphers. Btw another slow thing that can be used is Blowfish, as it has a slow key scheduling stage, but don't know if it's slow enough. Another approach can be to take any Feistel Network based block cypher and turn it from M rounds to M*N rounds. There are many ways to turn a secure cryptographic primitive into a monkey asses slow cryptographic primitive that seriously limits the effectiveness of brute force.
  - tptacek 17y ago
    Bcrypt is a pessimized version of Blowfish. If you're working at this level of granularity, it should be for a research paper, not something people actually use.
    - antirez 17y ago
      Ah was not familar with "Bcrypt" thank you very much for the info. I'll look a bit better into it.
codeslinger 17y ago
The attack isn't using brute force. The defense is against rainbow tables, not brute force.

by antirez 17y ago

tptacek 17y ago

Don't use HMAC, but, sure: iterate SHA1 a couple thousand times. This is the approach taken by PBKDF. A better approach is to use bcrypt or scrypt. It's not a security objective of SHA1 or HMAC-SHA1 to take a long time to run --- in fact, they have the opposite design goal. Bcrypt and scrypt have both been designed to be "cryptographically slow": speeding them up in the general case would (forgive an oversimplification) require a new result in cryptography that would be more significant than "optimizing brute force cracking".

antirez 17y ago
I proposed HMAC just in order to avoid that there is some strange property about H(H(H(H(H(...))) probably not true for SHA1 and many other believed secure hash functions and block cyphers. Btw another slow thing that can be used is Blowfish, as it has a slow key scheduling stage, but don't know if it's slow enough. Another approach can be to take any Feistel Network based block cypher and turn it from M rounds to M*N rounds. There are many ways to turn a secure cryptographic primitive into a monkey asses slow cryptographic primitive that seriously limits the effectiveness of brute force.
- tptacek 17y ago
  Bcrypt is a pessimized version of Blowfish. If you're working at this level of granularity, it should be for a research paper, not something people actually use.
  - antirez 17y ago
    Ah was not familar with "Bcrypt" thank you very much for the info. I'll look a bit better into it.

codeslinger 17y ago

The attack isn't using brute force. The defense is against rainbow tables, not brute force.