Figure out the encryption being used 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
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.