Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Key distribution is a problem even for ransomware. It looks like the decryption key is a function of the Bitcoin address to which ransom is sent. That should eliminate the need for a server controlled by the ransomware people to return keys.

What does "check payment and receive keys" really do? Does it check the Bitcoin block chain to see if payment has been made, then calculate the decryption key? Is this entirely blockchain-based?



I'm guessing that when a cyber criminal is caught they add all retrieved private keys to the police's keychain. Even a symmetrically signed key (passworded) can be brute forced or the arrested can be court compelled to decrypt the key.


AES cannot be trivially brute forced. The key phrase is also unlikely to be trivial because the convenience has no value.


I don't understand, perhaps I'm misunderstanding the situation.

GP is saying that if the [private] key is password protected, it can be brute forced. Surely if a human is able to type in the password to the private key, you can bute force that password relatively easily?


With cooperation, yes, without it, no. A password doesn't need to be too long to grow the key space to large enough all the computers in the world couldn't scratch the surface.

Of course, there are many other factors that can significantly decrease or break the security of AES.

TL;DR xkcd.com/538


bute[sic] force that password relatively easily?

"Easily" conceptually, yes, but not computationally.


They have a captured database of key/Bitcoin addresses, so when you put in the address it looks up the key.

>What does "check payment and receive keys" really do?

Presumably it asks the server whether the payment was received, and if the answer is yes, the server sends it the key.


I'm not sure, I spent five minutes thinking about it, and it's pretty easy to come up with a design that relies on no servers, accepts payment through Bitcoin and the decryption keys are only ever stored with the operator and never divulged before payment.

Maybe malware operators aren't that experienced, who knows.


I don't know about Coinvault, but other systems would generate the private key on a server and send the public key to the computer for encryption. I don't see how you could have zero servers and still send the private key upon payment, though.

There was an early version that would generate the private key locally, which was discovered by Symantec (the original blog post isn't loading, but you can see it at https://archive.is/1AGHG) For an analysis of a more recent version that fixed this see http://www.secureworks.com/cyber-threat-intelligence/threats...

A TorLocker had flaws that allowed 70% of infections to be recovered, see https://securelist.com/blog/research/69481/a-flawed-ransomwa..., although they didn't explain what flaws there were.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: