Is it possible to derive the encryption method from encrypted text?

Is it possible to identify the encryption method, or at least rule out some of them, by looking at the encrypted text?

For example, if you have 3 encrypted strings where the first 10 characters are the same on each of the strings.

• One interesting consequence of this -- that an encrypted data stream should be apparently random -- is that it explains why you should compress, then encrypt, rather than encrypting then compressing. Compression depends on redundancy, and an encrypted stream has none. In fact, a compressed encrypted file may turn out to be larger than the original. Jul 15 '11 at 13:59
• It almost always would be slightly larger, depending on the compression algorithm even quite a bit larger. (The deflate algorithm guards against a too much inflation, using only a small fixed overhead in case of non-compressible data.) Jul 15 '11 at 15:31

Yes, it is possible under certain circumstances to determine the encryption method used purely from ciphertexts. The first question that cryptanalysis faced with such a problem must answer what general type the cipher is. Does the cipher appear to be a classical cipher, asymmetric cipher, or symmetric cipher?

• Classical ciphers - These are typically written on a piece of paper. The character frequencies are often non-random. Often times people invent their own classical ciphers so there is a decent chance that your cipher is not in any book. Classical ciphers are typically easy to break by statistical analysis, once broken one knows the method used.

• Asymmetric ciphers - I may be wrong and I've been unable to find any information online about this, are asymmetric ciphers like RSA distinguishable from random noise? Putting that issue aside for the moment, generally, protocols that use asymmetric ciphers require certain metadata that would reveal the cipher used. Assuming no metadata the size of the ciphertext can also help an analyst as RSA tends to use much larger keys than ECC or AES.

• Symmetric ciphers - Many of the other answers have claimed that determining the method of encryption for symmetric ciphers is impossible if the symmetric ciphers have not been broken (if they are "good"). While it is certainly true that "bad" symmetric ciphers are distinguishable in some cases, let's assume that whatever ciphers we are going to look at our "good" random permutations with the caveat that many ciphers (especially stream ciphers) currently in use are not "good". We have two classes of symmetric ciphers, stream ciphers and block ciphers.

• Stream ciphers - Given enough ciphertexts one can distinguish between a block cipher and stream cipher because the stream cipher ciphertexts can be only any length whereas the block cipher ciphertexts must always be in increments of the block size. Distinguishing between two stream ciphers is far more difficult but possible under additional assumptions. For example, the plaintext is all Latin characters. All one has to do then is try all possible keys and all possible stream ciphers. If you find a key that reliably decrypts the ciphertext to plaintext containing all Latin characters, you win you've determined the stream cipher.

• Block ciphers - Block ciphers have two properties that are easy to determine from ciphertexts: 1. the block size and 2. that the block cipher is running in ECB mode. One merely needs to look at the length of the ciphertexts to deduce the block size, this does not necessarily tell you what cipher was used, but in semi-rare cases, certain block sizes are unique to a cipher. For example, if you discover that the block is 96 bits, you are probably dealing with the 3-way cipher. If a cipher repeats the same blocks in a probabilistically unlikely fashion the cipher is likely running in ECB mode.

On the nature of "good" ciphers.

Many ciphers currently in use do not fit the definition given above of a good cipher. For example, DES has a key size that is smaller than it's block size. Given two ciphers of the small block size and the different key sizes, it should be possible in theory to distinguish between them given only ciphertexts. Furthermore, many currently used stream ciphers are designed with ease of implementation in mind and therefore don't use non-linear mappings. For instance, the GMS system used by many mobile phones uses the a5/1 cipher. These ciphers are merely an LFSR and can not only be distinguished but can be broken in seconds given sufficient pre-computation time.

• "whereas the block cipher ciphertexts must always be in increments of the block size": Nope, you can use techniques like ciphertext stealing for CBC mode. Aug 11 '11 at 15:23
• @Nayuki Minase - Can you distinguish a stream cipher from a block cipher running in 'ciphertext stealing' mode? Aug 11 '11 at 15:40
• As far as I know, no. These methods are supposed to look like pseudorandom permutation functions with absolutely no obvious patterns. Aug 11 '11 at 15:45
• @Nayuki Minase - The functions themselves may by pseudorandom, but what about the increments, the other bits of information that no one likes to talk about. Can a block cipher running in 'ciphertext stealing' mode produce an odd number of bits, can it operate on the bit level rather than the byte level? What does it do if the input size is less than one block? How does it fail? Aug 11 '11 at 16:23
• Most stream ciphers are in practice also only used on the byte-level, even if they could have been used at the bit level. This will not help to distinguish. Nov 19 '11 at 14:46

If the encryption system is any good, then no. The output of a (symmetric) encryption algorithm is supposed to be indistinguishable from pure random. If you can distinguish encryption output from pure random with probability greater than 1/2 (i.e. you are given two strings of bits, and you can tell which one comes from an encryption system with better success on average than pure luck), then the encryption algorithm is said to be "broken". An example of such an algorithm is RC4 (not that being broken does not mean that decryption without the key is easy; RC4-protected SSL connections still appear to be mostly safe).

However, the used encryption algorithm is not generally supposed to be secret information. That algorithm exists as code or specific hardware somewhere; it is amenable to reverse engineering. It is very difficult to know how much algorithm secrecy may resist an attacker, and that's a problem since a good security policy should aim at quantifying things. Secrecy of a symmetric key can be quantified: a 128-bit key is secret up to 2127 (on average) trials. Since such a precise measure cannot be achieved for the algorithm itself, it is usually assumed that the name of the algorithm is known by everybody. Correspondingly, encrypted message formats often begin with an additional header which plainly states which algorithm is used (such a header avoids many maintenance headaches, especially when several distinct algorithms are in use).

• Alternatively, if you determine with LESS than 1/2, you can also consider it broken. Simply pick the opposite of whatever your algorithm says. Jul 15 '11 at 13:41

No, It's NOT possible. Output of a cryptography algorithm should be like an output of a pseudo random number generator. There is no any identification to identify it. If it's possible the cryptography algorithm is NOT a good cryptography algorithm.

• I disagree. What about all the detail one can deduce from block sizes, encryption modes, relative key size to block size, padding method, ciphertext length, non-random plaintext, key reuse (a problem for OTPs), related keys, fixed points. Jul 19 '11 at 22:42