4 ms·

If you want to throw a wrench in a password cracker's gears, why can't you just run your 'crypt' function on its own output a thousand times in a row, so that a

by 13of40 10y ago

If you want to throw a wrench in a password cracker's gears, why can't you just run your 'crypt' function on its own output a thousand times in a row, so that anyone attempting to crack it will need to run it a thousand times with every candidate password? What I mean is 'crypt(crypt(crypt(p)))' should take three times as long as 'crypt(p)', right? And scale 'a thousand' to however many iterations takes one second on contemporary hardware.

zamalek 10y ago
Use scrypt or bcrypt: both are computationally expensive by design. Both are largely unapproachable on GPUs and ASICs.
- masklinn 10y ago
  > Both are largely unapproachable on GPUs and ASICs. Not true with respect to bcrypt. Bcrypt is not designed to be memory hard, it uses a constant and relatively small amount of memory (~4kB IIRC) which is only incrementally better than PBKDF2. However its memory access pattern means it needs fast RAM, which is what makes GPUs inefficient for it: they have lots of memory[0] but it's slow to access from the parallel cores[1]. You can absolutely have small amounts of fast ram in FPGA and ASICs. [0] and a good amount of memory/core, a 1080 has ~3MB/core, a 1070 has 4 (they both have 8GB RAM but the 1080 has 2560 CUDA cores versus 1920 for the 1070) [1] GPUs have very high memory throughput but very high latencies even for caches[2] e.g. on Kepler (a few generations back) the L1 was already 48 cycles, Skylake can go up to L3 in 42 cycles [2] which are shared by multiple cores and are very very small: from what I've found Pascal has 64KiB of L1 per SM (with each SM grouping 64 CUDA cores) and 4MB of L2 for the entire chip
  - zamalek 10y ago
    Thanks for the correction.
- 13of40 10y ago
  I think my question is still valid no matter what crypt function you use. Why can't you just stack it N times to make it N times harder to compute?
  - zamalek 10y ago
    In general, you can. Just remember that you are stacking it N times on a CPU and, depending on the function, there is hardware that can do it more efficiently than a CPU: you're technically inconveniencing yourself more (in comparison to a hacker) by using a cheap function. You're going to gain a lot more by using a function built for high computational cost from the outset. Furthermore, > It can be shown that the repeated hashing reduces the space of possible values, but should reach an inner "cycle" of size roughly sqrt(N) if the hash output values are in a space of size N[1] Using the correct type of function just makes more sense. [1]: http://security.stackexchange.com/a/23308 http://security.stackexchange.com/a/23308

by 13of40 10y ago

zamalek 10y ago

Use scrypt or bcrypt: both are computationally expensive by design. Both are largely unapproachable on GPUs and ASICs.

masklinn 10y ago
> Both are largely unapproachable on GPUs and ASICs. Not true with respect to bcrypt. Bcrypt is not designed to be memory hard, it uses a constant and relatively small amount of memory (~4kB IIRC) which is only incrementally better than PBKDF2. However its memory access pattern means it needs fast RAM, which is what makes GPUs inefficient for it: they have lots of memory[0] but it's slow to access from the parallel cores[1]. You can absolutely have small amounts of fast ram in FPGA and ASICs. [0] and a good amount of memory/core, a 1080 has ~3MB/core, a 1070 has 4 (they both have 8GB RAM but the 1080 has 2560 CUDA cores versus 1920 for the 1070) [1] GPUs have very high memory throughput but very high latencies even for caches[2] e.g. on Kepler (a few generations back) the L1 was already 48 cycles, Skylake can go up to L3 in 42 cycles [2] which are shared by multiple cores and are very very small: from what I've found Pascal has 64KiB of L1 per SM (with each SM grouping 64 CUDA cores) and 4MB of L2 for the entire chip
- zamalek 10y ago
  Thanks for the correction.
13of40 10y ago
I think my question is still valid no matter what crypt function you use. Why can't you just stack it N times to make it N times harder to compute?
- zamalek 10y ago
  In general, you can. Just remember that you are stacking it N times on a CPU and, depending on the function, there is hardware that can do it more efficiently than a CPU: you're technically inconveniencing yourself more (in comparison to a hacker) by using a cheap function. You're going to gain a lot more by using a function built for high computational cost from the outset. Furthermore, > It can be shown that the repeated hashing reduces the space of possible values, but should reach an inner "cycle" of size roughly sqrt(N) if the hash output values are in a space of size N[1] Using the correct type of function just makes more sense. [1]: http://security.stackexchange.com/a/23308 http://security.stackexchange.com/a/23308