Hacker News Reader

Comment by camillomiller | Hacker News Reader

Ok, ELI5 for me please: how using a SHA256 function unsalted with 1 iteration - as suggested by Per Torsheim - would influence the fact that you can try more passwords per second? Isn't that a flaw of whatever kind of software password-trial limit more than a flaw of the algo used by iOS to encrypt the backup?

View on HN

You can't (usually) force attackers to use your code when performing an attack on encrypted data they hold. You might try to rate-limit password attempts with something like:

    if time_since_last_attempt < 1 {
        sleep(1)
    }
    key = sha256(password)
    check(key)

But an attacker can just replicate the algorithm without the sleep call, since it's doesn't influence the actual process by which you obtain the encryption key from the password.

The standard way to solve this is to use an inherently expensive process to turn the password into a key. In this case, it's something like:

    tmp = password
    for i in 0 to 10000 {
        tmp = sha256(tmp)
    }
    check(tmp)

Barring some breakthrough attack on SHA-256, an attacker must perform 10000 hashes for every attempt. If they don't, they won't derive the right key and they won't be able to decrypt the data.

Another approach is to use attack-resistant hardware which won't run the attacker's code and which has access to some hidden data which can be mixed in, and can't (easily) be extracted from the hardware. Then it looks like:

    if time_since_last_attempt < 1 {
        sleep(1)
    }
    hash = sha256(password)
    key = encrypt(hidden_data, hash)
    check(key)

Since the attacker can't obtain hidden_data, they can't run this code on their own hardware. Since the hardware doesn't accept the attacker's code, the attacker can't remove the sleep. This is how the iPhone's Secure Enclave works, and a less sophisticated version of this is why the FBI had so much trouble getting into that iPhone a while back even though it only had a four-digit passcode set.

Because the SHA-generated value is available to any program which can employ all the cores of the CPU and all the cores of the GPU to try the generated passwords in parallel, and one try is very, very cheap for SHA, compared to the "serious" algorithms, plus, anybody can buy special SHA breaking devices which are built all the time.

For example, this device, which was priced just 1300 USD tries

https://www.bitmaintech.com/productDetail.htm?pid=0002016091...

11.85T hashes per second, that's 1 with 13 zeroes per second and that shows what today is possible to achieve so cheap. Elcomsoft's software for previous, non-weak algorithm, managed to try 150000 passwords per second using the GPU, that is, this weakening is like giving an attacker some tens of thousands of computers for free, or tens of millions of computers for $1000.

Geez... Thanks

AFAIK bitcoin miners can't be used to crack hashes.

See https://security.stackexchange.com/questions/62800/is-it-pos..., https://rya.nc/asic-cracking.html

If the hash is SHA256 they can, read your links.

Sorry, the second link has better info on exactly why it won't work directly.

Thanks. Yes, I agree completely, when it's "directly." The mining devices aren't designed specifically to crack the passwords, but the solutions have the raw processing power and use the same hash algorithm, it's just that somebody would have to adapt the chips for that given task, and for that he could keep most of what's already optimized, namely the fast SHA256 calculations in hardware. It won't be particularly hard to adapt some current solution, and the known speed benefit and power use would approximately remain.

I think you'd need to design your own hardware, since the algorithm is hardcoded into these. And once you're doing that you'd lose the economy of scale that bitmain has.

You can bruteforce unsalted hashes by using rainbow tables.

Reply on news.ycombinator.com