Reply to post: Re: Shouldn't be up.

Re: Shouldn't be up.

I expect it is because if you encrypt a vast number of known files with the same key then it becomes easier to analyse and recover that key.

A "vast number of known files"? How many files does the typical victim have? You know of a known-plaintext attack against AES? And one that works with, what, a few hundred GB of data?

If the encryption is any good, then no, it does not become easier to recover the key - unless you happen to be in the possession of an unpublished and remarkably valuable attack against a modern symmetric cipher, in which case you presumably know enough to secure your systems against infection by ransomware in the first place.

So you encrypt each file with a unique key, then encrypt the table of files and keys with another key which you then ship off to the server.

Even if this were necessary (or useful), there's no need to generate a new completely independent key for each file and then send a whole list of them back to the server. This protocol is just as secure:

1. Let H be a cryptographic hash function with an output at least as long as the encryption algorithm's key length.

2. Generate random initial key K₀ which is sent to the server.

3. Encrypt the first file with K₀.

4. Subsequent keys are generated with K_i+1 = H(K_i). If necessary a padding function such as PKCS#7 padding can be used to extend the input to H.

The ransomware ... administrator? bandit? ... can generate the same series of K_n, since he has K₀ and knows what H was used. Assuming H has no known weaknesses, each K_i is equally strong. Even if, say, 10000 files are encrypted, it's not very expensive to try on average 2500 keys¹ to decrypt the first block of a file and see if it looks right², for a total of 25 million decryption operations for key-identification purposes.

I've never looked into ransomware in any detail. If I were writing it, I certainly wouldn't bother with this pointless multiple-key scheme; but if for some reason I did, I wouldn't generate an independent key for each file. That's just silly.

¹For the first file, you have to try on average 5000 keys to find the right one out of the 10000. For the last file, you only have one key left, because when you find a correct key you discard it after decrypting the file (each key was only used once). So the average is 2500 keys per file across all the files.

²Assuming that the ransomeware in question only encrypts files of a type it recognizes, and that most or all of these can be identified using bytes in the first block. Maybe we have to try a few false-positive keys or decrypt a couple blocks; that doesn't significantly increase the cost. And the cost is borne by the victim anyway, so why would the attacker care?