For someone who has a key and ciphertext, is it possible to find out what encryption algorithm was used?

Question

For someone who has a key and ciphertext, is it possible to find out what encryption algorithm was used?

Answer 1

In order to find out which encryption method was used, the first thing you can do is look at the length of the key and ciphertext in order to limit and rank the likelihood of the possible candidates:

• With a keysize of n bits, obviously only encryption schemes apply that support keys of this size. For example: if n is 168, you can be pretty sure the 3DES block cipher is used (you don't yet know the mode of operation, though); if n equals 128 or 256, the list of likely ciphers is a bit longer.
• If the ciphertext length is a multiple of 128 bits (a common scenario), there is a good chance a block cipher that uses this block size (probably AES) was used in the extremely common CBC mode. When the ciphertext size is not a multiple of 128 or 64 bits, you can be pretty sure you're looking at something encrypted with either a stream cipher, or a block cipher using something like CTR or GCM mode.
• Certain ciphers are very common (particularly AES-CBC), test these first.

Next, you can simply try the candidates one by one until you end up with a plaintext that does not look like random gibberish. If an authenticated encryption scheme is used, you don't even need to look at the plaintext because the algorithm tells you when it is correct.

Of course you will still need to somehow distinguish 'random gibberish' from a proper plaintext. Because the number of common encryption schemes that are commonly used is quite limited, it is probably enough to just print the decryption result to a text file and let a human look at them. If you want to check for valid plaintexts in an automated manner, you will either need to utilise some knowledge about the encrypted material (for instance, that it contains a UTF-8 encoded text or that it is a JPEG image) or run some simple statistical test. Note that you will probably not succeed at all if the plaintext is actually a sequence of randomly generated bytes not known by you.

Some matters can make this process more complicated: almost all encryption schemes require an IV or nonce that are essential for decrypting the ciphertext. This IV/nonce is probably prepended or appended to the ciphertext, but if not it might depend on the context of the cryptographic protocol. If you really have no idea what the IV/nonce might be, you could always try a few small numbers, hoping that sequence numbering is used to determine the IV.

Also note that the data you think is a ciphertext might actually contain more that just encrypted data. Besides the IV or nonce mentioned above, a MAC (message authentication code) or authentication tag may have been appended or prepended. If it is appended, it will probably not be problematic; but if your ciphertext starts with it you might accidentally start decrypting it and thus obfuscating the rest of the plaintext.

Last but not least there are also cascaded ciphers: multiple encryption algorithms with which the data is encrypted in succession. If you want to check all of them (up to a certain maximum of ciphers used), they could grow your search space significantly. However, only a limited number of different cascaded encryption schemes are used in practice, so this will probably not be much of a problem.

If all of this fails, it may be the case that an obscure cipher is used that you have no knowledge of. In this case you can hope it's crappy DIY-encryption and you can start trying to perform some actual cryptanalys on it.

Answer 2

"Possible" is the operative word. Solving cryptanalysis puzzles requires time, computer resources, and expertise. Your question also relates to cost-effectiveness. Could the NSA, if they urgently needed the answer, solve the stated problem? They're not telling, but they have square miles of computing resources and many highly-qualified experts. Could you solve the problem? You say you're new to cryptography, I assume you have maybe one or two personal computers, and you are solving the problem for fun (you won't profit by solving it). How much time are you willing to devote to this? I assume only a limited amount of time.

Within these parameters you could try attempting to decrypt the ciphertext using this or that encryption software and this or that algorithm, and possibly you could get lucky. Possibly not. Maybe the ciphertext was encrypted using an obscure algorithm, or more than once. It's anybody's guess.

Do you have any more information to bring to bear on the problem? For example, you know the text was encrypted by your cousin Bob, you know Bob uses PGP, and Bob is always telling you about what a great algorithm Blowfish is. This kind of information might simplify the task at hand.

There's also a cryptography forum on StackExchange.

Answer 3

@AardvarkSoup does a great job at showing the ways you can diagnose the encryption algorithm given a key and some encrypted text.

Given that a student is asking, I'll also point out that in practice there is generally no mystery. Different protocols and standards handle this differently but most of the time there's a format for agreeing to use a given crypto mechanism. SSL, for example, has a handshake. Encrypted email will have a header in the clear. In primitive systems, the encryption schema may be hard coded on both ends.

The general philosophy is that the only thing that must stay secret is the key. There is nothing secret about the method of encryption - it should be OK to disclose it, so there's no value to obfuscating it and every reason to make it easy on the systems involved in information transmission.

That said - the goal with the cipher text is to be random. While you might get some information from the key, the goal is to have the cipher text be so much like a random string of meaningless values that it won't give any indication of the content. So if you can scrutinize the ciphertext and easily say "this looks like the X encrpytion scheme" it's viable to worry that this encryption is NOT suitably random...

Answer 4

In general, no without additional information like a binary that can perform the encryption or decryption.

In practice, probably quite often. The simplest method is you take the ciphertext, key, and your list of decryption functions you suspect may be used -- and keep applying them to the ciphertext until you get something that (a) actually decrypts (many ciphertext & key combinations will not be able to decrypt), and (b) decrypts to meaningful plaintext. You possibly can use things like the key-length, etc.

But there are an infinite number of possible encryption schemes you can come up with, even if there were only a few fundamental cryptographic primitives. Even starting with just one encryption function is AES-128, you could make an infinite number of variations on it. You could then encrypt a message with AES-128-CBC, and encrypt it again with the same key. Or you could encrypt it once, bit-wise reverse the key, and encrypt it again. Or you could alter the key by xor-ing with a specific random string built into your algorithm on the second encryption. Or reverse the first half of the key, but not the second half, or interleave the key somehow. You could change the block cipher mode from CBC to OFB, CTR, CFB, GCM, CCM, etc. And again, since you could encrypt the ciphertext with any number of applications of AES (and could vary these choices in some predetermined fashion), you get an infinite number of potential encryption algorithms. You can tweak the fixed parameters of AES, changing the number of say from 10 to 13, or altering the Rjindael S-box, or mixcolumns step, or ... (Granted, you should be very careful while doing it, many seemingly benign changes will drastically weaken the security of the algorithm; e.g., the S-boxes were specifically constructed to be resistent to differential cryptanalysis). And this is with just starting with one type of encryption function, while in reality there are many often based on totally different principles. I would never recommend constructing your own cipher, unless it was just a toy project and you fully recognized how insecure it likely is.

Granted, the whole idea of Kerckhoffs's principle is that the security of your data should be solely based on keeping your key secret, regardless to whether your attackers know your encryption/decryption functions. It's easy to switch to a new key, but its much harder to implement changes to existing algorithms when there are flaws, especially if its in use and widely deployed. For example, consider how many web-servers and web-browsers still use protocols and modes of SSL/TLS with known flaws several years after the flaws were widely published ).