Hacker News Reader

Comment by rfoo | Hacker News Reader

Overall, cool work! Especially the search space reduction part.

I haven't dive into the code, but only 818000/60=13633 attempts per second for 64 SHA-256 rounds plus one AES-256 decryption on a 2080 doesn't sound right. Learn some GPU and tuning the code can likely increase the throughput a lot.

Mind you, that's only 25x naive Python implementation on (supposedly) 1 core.

Also, hashcat does >1M hash/s for even higher number of SHA256 iterations, and hundreds of million attempts per second on single block AES-256.

Edit: An optimized version of this is very likely deployable on consumer-grade hardware. May still not very useful due to the forensics requirement, though.

View on HN

Thanks! I wonder if the Python number is correct, I remember Python being prohibitively slow in comparison. But assuming it is:

There are 256 sha256 iterations on average, so the number is a bit better - but there's probably still a lot to improve (it's much more optimised than the naive version, but it was written by reverse-engineers, not GPGPU specialists). The PoC was also opensourced [0], it would be great if someone experienced could spot any obvious problems.

One major issue was that the key scheduling is basically

    do {
        key = sha256(key)
    while (key[0] != '\0')

So on average there are 256 SHA256s per key, but worst case it takes thousands of iterations. Coding this in a GPU-friendly way was non-trivial, and there are still some GPU cycles wasted.

> Edit: An optimized version of this is very likely deployable on consumer-grade hardware. May still not very useful due to the forensics requirement, though.

I think speeding the code three or four orders of magnitude more would go a long way towards pracical usage. I think the biggest issue was getting TID and precise enough time range. Brute-forcing a suspected TID values and widening the time search range would help a lot.

Disclaimer: I worked on that research, but I'm not an employe anymore.

[0]: https://github.com/CERT-Polska/phobos-cuda-decryptor-poc

One other thing. The article states pythons performance at keys-per-second, then all the other numbers are given in keys-per-minute. That means that pythons number looks really small in comparison, but if we take it (500 kps) and multiply it by 60, we get 30k keys-per-minute, or about 50% faster than the first CUDA baseline.

Now I'm quite fond of python, but largely I read this as the CUDA implementation having quite some room for improvement. Having almost no CUDA experience of my own, that is just a hunch, which I'm glad rfoo supports with (surely) a lot more experience than me.

I can't offer "four orders of magnitude", but "four" ;-)

PIDs on windows are always a multiple of four.

(I didn't see that mentioned in the blog post, but didn't check the code so maybe that's already in there.)

Edit: nvm I guess that's why it says 2^30 not 2^32...

Reply on news.ycombinator.com