Facing encryption

Question

I have an encrypted hex string:

AA969CF9657F77C597C8EAFF1594D59374E4977F

which I know corresponds to the plaintext:

http://jogos.meo.pt/

I want to know if it is possible to find out what encryption algorithm might have been used? Anybody could help me please?

Answer 1

You'll likely need to reverse engineer the code that does the decryption. Tools such as FindCrypt and the Krypto Analyzer ("KANAL") plugin for PEiD may help you with a starting point.

Answer 2

Partly repeating what I already wrote in my comment at crypto.SE…

The one thing you can learn from that data is that the known ciphertext (20 bytes in hex-representation)

AA969CF9657F77C597C8EAFF1594D59374E4977F

can be XORed with the (let's just call it) OTP

C2E2E8895F5058AFF8AF858C3BF9B0FC5A94E350

to get the hex-encoded version of the known plaintext http://jogos.meo.pt/ which is

687474703A2F2F6A6F676F732E6D656F2E70742F

As you don't know anything else, it's already hard to tell if an algorithm or an OTP was used. Is C2E2E8895F5058AFF8AF858C3BF9B0FC5A94E350 an OTP or the result of a PRNG, a hash, or something else? You can't tell by simply looking at this rather minimal piece of information.

Therefore, the only chance you have is to collect enough samples that will allow you to recognize a specific pattern. Yet, chances are that that pattern boils down to being a random OTP string of who-knows-what length. Personally, I can't “feel” any patterns by just looking at it… but you could check the obvious ones: keyed Vignere over a 256 byte base, etc.

Answer 3

Your ciphertext consists of 40 hexadecimal digits, which encode 20 bytes. Your plaintext is 20 ASCII characters long. The obvious assumption, therefore, is that the ciphertext has been calculated by taking the ASCII code of each plaintext character and either adding (modulo 256) or XORing a corresponding key byte with it.

Furthermore, the bytes in your ciphertext are not uniformly distributed over the range from 0 to 255, suggesting that what you have is not a secure stream cipher but something weaker.

Indeed, taking each byte of the ciphertext and subtracting the corresponding byte of plaintext yields:

42 22 28 89 2b 50 48 5b 28 61 7b 8c e7 27 70 24 46 74 23 50

or, in ASCII (using \xHH for characters outside the valid ASCII range):

B"(\x89+PH[(a{\x8C\xE7'p$Ft#P

Those extra characters might belong to some 8-bit extension of ASCII, such as Windows-1252, which would make the "keystream" look like this:

B"(‰+PH[(a{Œç'p$Ft#P

This looks plausibly like something someone might produce simply by mashing "random" keys on a non-English keyboard, so it's at least plausible that the "encryption" mightsimply consist of adding this key string to the plaintext byte by byte. However, without more samples, there's no real way to confirm this.