Hacker News Reader

Comment by murbard2 | Hacker News Reader

The attackers seem to have a poor grasp on cryptography. The entire point of RSA is that they don't have to generate the key locally. Just ship your ransomware with the attacker's public key, generate a symmetric key K locally, encrypt the data with K, encrypt K with the public key, offer to decrypt K for a ransom.

There seems to be an inverse correlation between smart and evil in human beings which is reassuring, but only mildly.

View on HN

I'm going to point at the elephant in the room and say that, there are probably quite a few reading this post and screaming in their mind, don't help them!!

There seems to be an inverse correlation between smart and evil in human beings which is reassuring, but only mildly.

Indeed, this isn't the first time ransomware with bad crypto has lead to a win for the good guys:

http://blog.cassidiancybersecurity.com/post/2014/02/Bitcrypt...

http://0xec.blogspot.com/2016/04/reversing-petya-ransomware-...

Not to interfere with any internal screaming, but I think (hope?) most would agree that a secondary elephant in the room is that suppressing knowledge so as not to help the "bad guys" tends to be the worse evil.

I don't see how that applies in this case. This is just someone saying hey bad guy, here is an idea on how to perform your dastardly act "better."

Having this public doesn't really defend against it any way. And if someone were to perform this act, it would be easy enough to figure out what was going on.

I think it's fine to publicise better attack methods, so we can figure out how to defend against the next potential version.

We should be moving to better solutions regardless, like append-only backups.

I believe it applies, as someone who doesn't know much about crypto AND is interested in protecting myself, this small tidbit of information moves me closer to being an aware and self-defensive computer user.

Any bad guys with sufficient ambition and intelligence are going to get as far as they're going to get, and if you're afraid of talking in public because a "bad guy" might overhear you and become smarter, you really are living on the wrong side of matters.

The knowledge he is writing is so basic anyone must understand.

You're saying like "We should not teach programming publicly since bad guy may misuse the knowledge."

This is different. He I specifically addressing what the bad guys should do. If he talked in more technical terms without spelling out what the bad guys should do, your argument would be legitimate.

> Just ship your ransomware with the attacker's public key, generate a symmetric key K locally, encrypt the data with K, encrypt K with the public key, offer to decrypt K for a ransom.

It seems that what they're doing is generating a local Kpub/Kpriv pair, encrypting Kpriv itself and then offering to decrypt it. The files are encrypted with Kpub (approximately, see comments below for details). This has the advantage that they can encrypt all they want without knowing Kpriv, which only needs to live in memory long enough to get encrypted.

With your approach the (symmetric) key used to encrypt the files is still unprotected in memory for at least a short period of time.

I'm surprised ransomware doesn't use the TPM to protect their private keys - given that more computers have it now.

No. Encryption is done with the public key only. No knowledge of the private key is required. The private key is only used for decryption and can be delivered to the victim after payment is made.

> Encryption is done with the public key only.

The post said encryption is performed with a new symmetric key K, and then K is encrypted with the attacker's asymmetric public key.

Remember asymmetric encryption doesn't scale for large amounts of data - which is why systems like TLS and full-disk-encryption still use symmetric keys - the asymmetric cryptoschemes are only really used during handshaking and for the exchange of symmetric keys.

Probably obvious, but they would not want to send a private key which could be used to help other victims. If they generated a symmetric key locally and encrypted it with their provided public key, they could decrypt the symmetric key for you in exchange for payment.

So, to check if I understood.

The generated key is encrypted and the user has access to it. So, you send the encrypted key and pay the randsome to get the unecrypted private key. Is that so?

Almost, the last bit should read:

>... get The unencrypted secret symmetric (session/encryption) key

So ransomware ships with public key PubK, generates symmetric key K, encrypts user files - plaintext message M to get encrypted files, cipher text C:

K=128 random bits, generated on target system

C=aes(K, M)

Then the key K is encrypted with the public key PubK, yielding encrypted key, Ks. Finally K is deleted from memory/overwritten.

Ks can be decrypted by private key PrivK - known only to the author of the ransomware.

Now, the victim sends Ks and payment to the author/attacker.

The attacker decrypts Ks using PrivK, and gets K, which is sent back to the victim - who can presumably supply K to the ransomware. Ransomware then uses K to decrypt C, yielding M - the unencrypted files.

That's fair but should note that smart != depth of cryptographic knowledge. I am not saying that these are geniuses, programmers or even necessarily evil but (so far) they haven't been caught.

So if these were poor teenagers who mostly copy pasted code and built the rest on the fly then as long as (opportunity cost < ransom > (chance of getting caught * penalty)) then it was "smart".

That's what is good and bad these days; powerful tools empower motivated people.

> There seems to be an inverse correlation between smart and evil

Hopefully you're right.

Of course smart != depth of cryptographic knowledge, but smart => acquiring said cryptographic knowledge when building a tool that deals with cryptography. If they were just teenagers, maybe you have a point.

What is the fundamental difference? The pitfall that makes it possible to decrypt is that the key which is needed to decrypt is not cleared from memory. Your proposed strategy has exactly the same problem.

What would work is hardcoding a large number of public keys in the binary. Then upon paying the ransom the attacker could give the private key to the victim.

That is not how async crypto works. If you only provide the public key (as opposed to creating a keypair locally) you could print it out to the victim and it wouldn't matter, as it can only be used to encrypt.

Which is exactly my point. Ideally, you want to encrypt with a key that is different from the key that you need to decrypt, so that you can encrypt without ever having the key that is needed to decrypt in memory. This is impossible with symmetric cryptography.

You're right. On the other hand, asymetric encryption if a disk will be dog slow.

Cryptography expert usually recommend not to use the same key (here the ransomware's public key) for transport and storage. Maybe the symmetric key should not even be stored locally.

But the drawback is that with this approach the same symmetric key would be used to encrypt all files leaving it longer in memory. If 1 symmetric key is used per file it would mean that the ransomware would need to be queried for every file.

Using a locally generated asymmetric key encryption key AKEK to encrypt the files means that:

- The AKEK Pubkey can be kept in memory and the AKEK private key be sent immediately to the control center.

- A different symmetric key can be used to encrypt every file and the control center can be queried only once to retrieve the AKEK private key

On an unrelated note, I wonder if people thought about doing a DDOS on the onion service ... ?

>On an unrelated note, I wonder if people thought about doing a DDOS on the onion service ... ?

Wouldn't this, if successful, just prevent victims from paying to decrypt their files?

Sure, it would stop the attackers from getting any bitcoin, but the victims' data would still be encrypted.

Well the thing is, if they had alot more knowledge about this stuff, they'd probably make way more money "going straight", though I'm sure there are some exceptions to this.

Alas, in order to optimize profits you wouldn't want to use a shared key pair. The risk of course that once your private key is disclosed then you'll potentially thwart future revenue.

In the scenario described, you're not giving back your private key, you're returning the decrypted key the victim needs to decrypt their data.

That key won't work for other victims.

The more capable either avoid observation, or simply ensconce themselves within the existing economic power structure, hiding in plain sight while accruing accolades.

This is deemed "success."

Reply on news.ycombinator.com