Unencrypting encrypted text

[minestrone]

I have a DB that contains 150,000 12 char encrypted strings, I don't know the encryption mechanism and I am not sure if they have been salted. I'm basically wanting to explore the possibility of working out if the encryption can be reversed in a bulk process.

We know the 8 char strings that the encrypted text came from but they are on scanned PDFs and it would be a manual process to sort them which really is not an option.

I just wondered if anyone has any experience of this sort of thing, I am aware that there are tools that might be useful but really not sure where to start. I'm thinking maybe if we know the inputs and the output is only 12 chars then it could be reversed.

Obvious disclaimer that the data is ours and it's all above board, the code that did the encryption has been lost.

Cheers

[stek]

Try Kali Linux, it's a pen test/ethical hacking Linux with all these tools preinstalled - might not do what you want but worth a look.

It's free and there are prebuilt VM's as well....

[minestrone]

Cheers, ill give that a whirl, seems there is an EC2 image so I'll look at firing up an instance later in the week when I get some time and report back.

[DaveB]

I have a DB that contains 150,000 12 char encrypted strings, I don't know the encryption mechanism and I am not sure if they have been salted. I'm basically wanting to explore the possibility of working out if the encryption can be reversed in a bulk process.

We know the 8 char strings that the encrypted text came from but they are on scanned PDFs and it would be a manual process to sort them which really is not an option.

I just wondered if anyone has any experience of this sort of thing, I am aware that there are tools that might be useful but really not sure where to start. I'm thinking maybe if we know the inputs and the output is only 12 chars then it could be reversed.

Obvious disclaimer that the data is ours and it's all above board, the code that did the encryption has been lost.

Cheers

It sounds like it may be easier to convert the PDF's to text and write some code to sort them based on the unencrypted string.

Even if you can identify the encyption method used, without the original encryption key and salt you are still looking at a pretty much insurmountable problem as most "proper" encrption methods are one way. Even knowing the key and salt you can't reverse the encrption on the encypted text to get the original.

What you would have to do is use the key and salt to geneate a rainbow table of all possible encryption results from the original data space and then match that against the encrypted values to find the originals.

[minestrone]

I did think of looking into the PDF text but they are scanned letters, images and stuff like that.

I think there is enough evidence in the general quality of work from the creator in this system to suggest that they used the most basic encryption available without salting.

I remember working for a place that took passwords and added 50 onto each char.

[DaveB]

I did think of looking into the PDF text but they are scanned letters, images and stuff like that.

I think there is enough evidence in the general quality of work from the creator in this system to suggest that they used the most basic encryption available without salting.

I remember working for a place that took passwords and added 50 onto each char.

In which case it might be worth posting some plain text/encrypted text pairs (assuming you can identify them) on a technical puzzle solving forum, or even here to see if anyone can work out the cypher that was used. Once you know that the rest is easy if it really was just a rotation/char swap jobbie.

[DaveB]

Alternatively, find the guy that wrote it and get the rubber hoses out.

[minestrone]

I'm sure there was bobage involved in this work, anyways the text is car registrations.

DL13 UHU

->

Mw+w2j5CLBc=

All the encrypted text ends in a '=' which makes me think that 11 chars + '=' is the work of someone who is not exactly rigorous. The space might be removed before encryption but not sure really.

[stek]

I'm sure there was bobage involved in this work, anyways the text is car registrations.

DL13 UHU

->

Mw+w2j5CLBc=

All the encrypted text ends in a '=' which makes me think that 11 chars + '=' is the work of someone who is not exactly rigorous. The space might be removed before encryption but not sure really.

It's a white Vauxhall Astra SRi!

[SpontaneousOrder]

I'm sure there was bobage involved in this work, anyways the text is car registrations.

DL13 UHU

->

Mw+w2j5CLBc=

All the encrypted text ends in a '=' which makes me think that 11 chars + '=' is the work of someone who is not exactly rigorous. The space might be removed before encryption but not sure really.

= is the base64 padding to fill out the block size. You'll always get that if the size of your data doesn't fit the block size exactly.

**edit** 'block size' is the wrong terminology and I just realised it could make it sound like a symmetric AES block size or something.

Base64 works on 24 bit strings of 3 octets. And log2 of 64 = 6: i.e. 4 6 bit values per 24 bit string.

Those 6 bit values map to ASCII (not by the ascii code though) to get your Base64 representation of binary data.

If you don't have enough data at the end to make a full 24 bits, then padding is added ('==' or '=') as necessary.