Most effective way to decrypt data when encryption method is unknown?

Question

I have a large amount of data that was encrypted by a third party tool before it was backed up, now we no longer have access to the tool and I NEED the data what is the most effective way to try and determine how the data was encrypted?

Answer 1

Unless you have the crypto keys, won't this be a pointless exercise?

Answer 2

You need to both:

• find out the method of encryption; and
• find out the key used to encrypt.

Easiest way is (if possible) go to the person or company that did it and ask them.

I don't envy you this task since, unless the encryption is something useless like XOR, you've got a serious job on your hands.

For a start, you may want to tell us the name of the tool. Withholding information from the question is just going to make it even harder for you, and you don't need that :-)

Answer 3

The world would be a crazy place if someone knew the perfect answer.

Answer 4

If the third party tool was any good you might have to kiss the data goodbye. How much is the data worth? How much will it cost to recover? Would the cost of acquiring the tool again be less than the value of the data? If so, just buy it again!

You should look for any professional audits of the third party tool's effectiveness and security. They might shed some light on the methods used.

Quite honestly, if you can't gain access to the tool again, your best bet is to contact a professional data recovery firm. If the product you were using is reasonably common you might have encountered it before. Of course if it is any good they probably wont be able to help unless you still have whatever keys were used available.

Answer 5

Track down the people who made the tool, or people who used it when you did have access to it. Hypnotize them to regress them to an earlier time so they can recall what it was.

Answer 6

Unless you can contact the third party vendor or can search online to see what type of encryption is used, you are out of luck.

And even if you did find out, unless the key you used was extremely short or easy to guess, brute forcing it may take you a long long time.

Answer 7

You NEED to get hold of the third-party tool that was originally used to encrypt the data.

If you can't get hold of the tool then you NEED information regarding the algorithms, keys etc that were used, preferably from the vendor.

Answer 8

I think all the normal ideas have been covered already, but here's a couple of long-shots.

Try taking a look at the raw data, especially the first four bytes. Run a search for the first four hex bytes and see if you get lucky and get a hit (ie. see if the vendor used a magic byte in the header).

Another thing you can try is running the raw file through a utility like 'strings' (or just browsing the file if it's relatively small). See if maybe the tool embedded a copyright notice or the like in the resulting file -- it's at least worth a shot.

Of course, you could also try posting the file to the internet and seeing what other people can come up with, but I'm guessing that would defeat your purpose (ie. it's confidential data -- why else would it have been encrypted in the first place).

Answer 9

If the data was encrypted, presumably it was to protect against exactly what you're now trying to do: access the plaintext without the appropriate credentials.

Either this can't be feasibly done, in which case the encryption tool has done its job well; or it can be feasibly done, and you need to start being very worried (in proportion to the value you attach to keeping the data secret) about who else has been able to do it without your knowledge.

Answer 10

It sounds like you're also facing apathy within your own organization, if they are uncooperative about even naming the tool.

I'd tell management that it's vital to know which tool it was. Somebody's got to either know, or have some paperwork that would help. Ask around, emphasize the importance, and document who you asked. In a case like this, take the usual CYA measures.

After that, I'd stop worrying about it. You might want to make a few attacks on it just to look good, and it's possible you'd get lucky. However, if nobody else in the company cares about something important to the company, I find it too stressful to care about it much myself.

Answer 11

Hope is not lost. There's a good change you can figure out what encryption was used, and possible decrypt it. First thing, in Cygwin or unix, type the file command:

$ file mydata
mydata: SQLite 3.x database

File will look at the first few bytes and attempt to determine it's contents. There's a few possibilities of how the data is encrypted:

• 100% encrypted data and structure
• data encrypted, but not the structure
• neither is encrypted, but a password check is added to the program.

If you lucky, the file command will know the file of file and the structure of the data won't be encrypted. This is common, as when the program updates the data it usually doesn't want to rewrite the whole file. Additionally, if the data isn't the actual database, but rather an export, it may be compressed. File will tell you if it uses a common compression format.

Next, use the 'strings' command.

$ strings mydata

This will output any clear text data. If you see evidence of your data, then no decryption may be necessary. Some programs simply implement a password check and don't do any encryption at all. This can be true even when the vendor states that they are 'encrypting' your data.

If your still dealing with a random bunch of bytes, and strings and file just told you it's binary data, then you need start poking around the data.

The next two important things are to look at the total length of the file. The modulus of the file size can tell you something about the encryption algorithm. The second thing is to look at the histogram of the data.

$ ruby -e 'ARGF.each_byte {|b| puts b >> 4; }' <  mydata | sort -n | uniq -c

If the bytes are evenly distributed across the range 0-255, then your dealing with a proper encryption algorithm. If your data is lopsided, then the encryption can probably be easily detected and broken. For example, look at this output:

     15 0
     54 2
     93 3
    248 4
    165 5
    177 6
    135 7

The frequency count is in the first bucket, and the data in the second. Here you can see the data contains no character above 127. This means the data is close to ASCII text. Run the histogram again, and put the data in one byte buckets. Simply leave off the right shift operator.

$ ruby -e 'ARGF.each_byte {|b| puts b; }' <  mydata | sort -n | uniq -c

Now, you might see an ASCII distribution, or maybe the data is base64 encoded or base96 encoded. You can run the stream through a decoder, and try all the above steps again.

If you find you dealing with an industrial strength algorithm, then you need to figure out which one. If you have any copy of the program, the code itself will usually give up the algorithm used quite easily. If not, you have to look at things like the length. If the data length is always modulus 8, then it's probably encrypted with a symmetrical block cypher like blowfish.

If you can determine the cypher used, then you must figure out the key. If the program required a password, then the key is likely based off from the password, or is the password itself. If your lucky, the program would not ask for a key, and only the program itself would know the key. In this case, if you can get your hands on the program, then you could extract the key out of the program, as it must contain the key in order to encrypt and decrypt.

My experience has been most vendor software doesn't use real encryption, and programmers attempt to do something like XOR'ing the data before writing it. If it uses real encryption, the software usually would come with a disclosure about export restrictions.

Answer 12

Since you know the person that has the information you need, your best bet is rubber hose cryptanalysis.