# Figure out the encryption being used [closed]

There is a web API (for a game) that sends and receives data encrypted in hex format. I'm interested in accessing the api outside of the game client (mobile app). When sending a request with an invalid query, the server sends an encrypted response (as a hex string) that is different every time (same length), but I'm fairly confident that the dencrypted message is the same.

I've been doing some research lately about d/encryption and have a feeling that it is impossible, but I figured I'd ask in case I'm mistaken.

Q: Given a (unlimited) series of hex strings that all decrypt to the same message, is it possible to figure out (brute force?) the encryption?

Here are some of the values:

• 6683A5C618FDA544DF87F6
• 1CD9EE2E62A7EE3E85CC1E
• 7AE3FDAA049DFD58BFDF9A
• 73863C600DF83C51DA1E50
• 39B4789847CA781BE85AA8
• 1C024088627C403E5E62B8
• Unlimited is a relative term, can you acquire several hundred billion messages before you die of old age? – Richie Frame Feb 21 '15 at 4:06
• So it would still run into the issue of 'impossible' with current technology. – Kpaekn Feb 21 '15 at 4:25
• impossible is also relative, against the strength of the algorithm. Even if you are able to easily identify it, it may be impossible to decrypt – Richie Frame Feb 21 '15 at 5:27
• If the algorithm doesn't suck, this will be impossible. Reversing the game executable is the most promising path. – CodesInChaos Feb 21 '15 at 9:06
• Since the game client can read the encrypted message, this is certainly possible. You just need to reverse engineer the client. – Aleph Feb 21 '15 at 9:56

In order to tell for certain which algorithm is used from the cipher text alone, you have to break the key as well. It is however possible to make some educated guesses about the algorithm.

Your strings are only 88 bits long. That rules out every asymmetrical algorithm that I know of.

If it is correct, that all of those strings encrypt the same message, then it would have to be a probabilistic encryption (which is also best practice security-wise).

A block cipher in CBC mode is one of the first probabilistic encryptions, that many cryptographers learned about. However a CBC mode encryption takes up at least two blocks worth of cipher text, and I know of no block cipher with blocks as short as 44 bits. I do know a few with 64 bit blocks, but except from very special cases, such short blocks should be considered obsolete by now. AES has a 128 bit block, meaning your messages are too short for even a single block.

Every probabilistic encryption uses an IV (possibly called a nonce in some contexts). In case of CBC the IV is a full block, but other modes like for example CTR can use a shorter IV. Additionally since CTR operates as a stream cipher, there is no requirement for full blocks being used in the enciphered data. Partial blocks will work just fine in CTR mode.

Your strings are likely 3 + 8 bytes, with either 3 bytes IV and 8 bytes data or vice-versa. An IV as short as 3 bytes is ridiculously insecure (which hasn't stopped it from being used in widely used protocols in the past).

If the messages are using 3 bytes of IV and the 8 bytes for some reason is a full cipher block, then it would have to be one of the ciphers with a 64 bit block. DES is one cipher with such a block size, Blowfish is another. To the best of my knowledge among the block ciphers with 64 bit block size, DES was the most widely used, and Blowfish was the most secure.

It could also be that there is 8 bytes of IV and 3 bytes of message. When encrypting with CTR it could make sense to split the input blocks into half IV and half counter. If IV and counter are 8 bytes each, the block size would have to be 128 bits. There are many ciphers with that block size. AES is one of them. If this is how the encryption works, that message would be 3 bytes long. It might be that the message being used is always either yes or no.

Encryption without integrity is almost always a bad idea. But since people are so often told about encryption and not so often about data integrity, it is not so unusual to encrypt data without integrity. 88 bits is very short if it is both probabilistic and protects integrity, so I guess it doesn't do both. So if you believe it really does provide probabilistic encryption, I guess it has no integrity.

Feeding mangled messages into the legitimate decryptor would provide clues as to whether any integrity checks are in place. Other than that, it is probably a lot less work to simply reverse engineer the code than to break the encryption.