I have next to no experience or knowledge of encryption, so I am asking this out of pure ignorance. Let's say that I got bit by ransomware (thank God I have not!). On my desktop is one solitary file that I downloaded off the internet. That file gets encrypted. I know where to get the exact copy of that file and re-download it. Wouldn't it be possible to compare the original and encrypted versions and work out the necessary key?

Suppose we use a very simply encryption algorithm, like the rotation cipher. A => B, B=>C, C=>D, etc. This would be a rotation of 1 to the right. The algorithm would be "Letter+1". Very easy to decrypt, right? Let's make it slightly more complicated by letting the number of letters we displace be a random value between 0-26. We get this random integer value by using

int offset = rand() % 26;
char ROT = (Letter + (char)offset) % 26; //let Z + offset loop around

Note that every time you run the rand() function, you're generating a sequence of random numbers. Because the rand() method is a pseudo-random number generator, the sequence of random numbers will always be the same, every time you run the application. Here's an example:

Random output sequence the first time the app is run: {23,14,21,7,16,3,21...}

Random output sequence the second time the app is run: {23,14,21,7,16,3,21...}

However, if you seed the random number generator, you're going to generate a different sequence of random numbers. But, every time you use the same seed, you'll generate the same sequence of random numbers. So, if we treat the key as the generator of the seed for random numbers, can we derive the key from a sequence of random numbers?

Even if I give you the code which generates the random numbers, the plain text which was encrypted, and the resulting cipher text, is it possible to derive the key from a simple ROT cipher without using brute force?

//from rand.cpp in the stdlib

// Seeds the random number generator with the provided integer.
extern "C" void __cdecl srand(unsigned int const seed)
{
    __acrt_getptd()->_rand_state = seed;
}

// Returns a pseudorandom number in the range [0,32767].
extern "C" int __cdecl rand()
{
    __acrt_ptd* const ptd = __acrt_getptd();

    ptd->_rand_state = ptd->_rand_state * 214013 + 2531011;
    return (ptd->_rand_state >> 16) & RAND_MAX;
}

I'm not a crypto-analyst, so I can't say with any authority, but I imagine it would be difficult?

If I was going to try to attack this encryption method, I'd brute force it and use a large bank of computers and have them start creating sequences of random numbers to try to match the known sequence of random numbers. We'd just create a loop which iterates through every possible random number seed until we find a perfectly matching sequence of random numbers. But hey, that's brute forcing and if we can force a brute force attack to be the best chance, then the encryption system wins. All we'd have to do is exponentially increase the time it takes for the brute force to be effective. 100,000 years on one computer, maybe 1 year with 100,000 computers?

What guarantee do you have that the original remain unchanged, even if you were able to decrypt it back? It feels like once a computer is compromised, it should might as well be reformatted completely.

He means for example if he downloads like... VS2015 community edition installer EXE from the internet...

And then later he gets ransomeware'd, the ransomware encrypts that installer file as part of its work. He has, for example another computer which can go and download the original EXE from the internet again to compare its un-molested contents vs. his randomware'd version from his infected computer.

He's saying the original version out on Microsoft's download page is NOT infected, so he can download it again to compare.

I got that. I am questioning what comes next.

If the purpose is to retrieve the original file, since you can already download the original from somewhere else, then you don't need to decrypt it.

If the purpose to somehow discover the decryption key so you can decrypt other encrypted files, then comes the question if the other files were unchanged before being encrypted.

If the purpose is solely a study of decryption, then why the randomware example?

I recently witnessed two computers hit by Crypt0l0cker ransomeware. One of the best thing to do is getting rid of vssadmin.exe in your computer as first thing virus does is using it delete shadow copies of files to ensure you'll not get most back. Other than that there are utilities like Hitman Pro although I am not sure howw effective they are.

And for encryption, most of them aren't RSA2048 or that strong as they claimed, for the oldie but goldie ransonwares it's feasible to try brute forcing as there are utilites helping it since mechanisms are partly revealed.

But for the newer variants, there is no public information. Your sole option afaik is reaching Dr. Web ransomware service, you send them files (they especially ask for XLS and DOC files so this might give some hints) and if they can get the key, they ask 120€ for decrypting and 2 years of Dr.Web software named as "Rescue Pack"

These ransomware programs use the systems ssl libraries to encrypt the data using a private and public key pair. The private key is uploaded to a remote server and removed from your pc so the only way to get it back is by paying usually in bitcoin.

These are not generally crackable simple xor encryption or similar as they are organised crime and they want your money.

Also, it's possible to get infected multiple times and encrypted multiple times with several layers. Not only would you then have to pay twice, you'd have to make sure you decrypt in perfect reverse order, and it's difficult to know the order of infection to know which one to pay off first.

Payment is taken via a portal accessible via onion network (basically darknet) so theres no way of tracing the server... You also have to install tor browser before you can get there and make a payment.

In short, get backups, use backups and love backups. You'll thank me later :)

Note that some of the earlier simpler ransomware kept the key on the hard drive. These can be decrypted but those versions aren't around much any more for obvious reasons.

Edit: I did have an article about this, but I can't find it any more :(

I got that. I am questioning what comes next.

If the purpose is to retrieve the original file, since you can already download the original from somewhere else, then you don't need to decrypt it.

If the purpose to somehow discover the decryption key so you can decrypt other encrypted files, then comes the question if the other files were unchanged before being encrypted.

If the purpose is solely a study of decryption, then why the randomware example?

I shouldn't have mentioned ransomware. It was the first thing that popped in my mind. The purpose was to discover the key. I was curious if this was possible. My understanding of encryption is to keep others from viewing a file. This, of course, would assume that the unauthorized viewer did not have access to the decrypted file, which makes sense. However, if you could correctly guess one file and then retrieve an unencrypted copy from somewhere, I was assuming that it might be possible to use it to find the key. I was unaware of the plain text attack that Olof mentioned. If this were possible, it would make encryption pretty much useless, so I can see why it is addressed.

This really was never a discussion about ransomware.

Edit: duplicate post removed!

If it's simple symmetric encryption using a non standard algorithm, yes you can reverse it by analysing the source file. It helps to have the key too.

For proper rsa style cryptography a proper peer reviewed algorithm with no key available and used properly, you simply aren't getting in without a key...

A variant of crypto virus had been easily decrypted as one of the servers had been exposed so most people could easily retrieve file using keylists. But it is not always an option (that current keylists will work) so other than trying known keys and possible workouts ( like using a subset as Alan Turing did in movie while breaking enigma ) I doubt other methods are feasible.

You know, even if you could somehow figure out the key from that and all... who said it's the same key being used on every file?

Having a known decrypted copy of some of the contents and the exact program used to encrypt the data will make the task easier. (Having reliable metadata on the files, such as specific time stamps and such can make things even easier in some cases.) But this is kind of like saying that having a good river you can float barges on makes moving an entire mountain an easier task.

And depending on the exact methods then even having all that might not help you a great deal. A river flowing in the wrong direction doesn't help you move a mountain to where you want it after all.

Not a crypto guy, but based on conversations with some friends who deal with some high level stuff then a huge question as to whether the numbers get any easier to crunch is whether the encrypted data is "in stream order" or "out of stream order". If you really really REALLY need to keep people from finding a way to break into the data, then you employ a scattering effect on it. If you think of encrypting a deck of cards in a specific order, then you lay them out on a table in their order, pick each one up and replace it with an encoded copy. Very fast and efficient, but everything is still in order.

If you really want to screw with people who are trying to decode stuff, then you pick a card up off the table, encode it, and then set that down in a different spot based on a pattern that changes depending on what order key you use. It is however slower to encode and decode as you have more jumping around. Not exactly great for a live stream or something. (Order key could be a secondary key, based off part of the main encryption key, or some other method.)

Why modern encryption methods work and are actually useful in the face of readily available computer systems that can crunch millions of numbers a second is that modern encryption methods simply allow so many orders of magnitude more possible options over and above that, so you can't simply load the data on a computer and tell it to "Try every possible key" and expect it to get back to you any time soon.

However, there is still the "Low hanging fruit" of the "reasonably secure", that is small/quick key encryption of in-order data. Pair that with a known 'first value', and you can setup a tiered system which generates 'potential keys', and feeds their results on to the next level. First level just 'tries all the values', and does a 'yes/no' check: Does the first decrypted data point match the expected value? Yes: Pass it on to Tier 2, no, ignore the key as it is garbage. Still god awful slow and hard, but it is still doable if you know what is supposed to be where in at least part of the message.

If you can't tell that in a trivial fashion, and have to also break the data scatter pattern... Well, then you're "Just a little screwed."

Try not to open dodgy files and have backups.That's the easier way to keep your files safe.

Not so easy when your servers are breached ... [ LINK ]