Is there any program that, given a cipher text, it would tell me what the encryption algorithm is?
What if I have the plain text? Is there something that can be done in that case?
Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this communityIs there any program that, given a cipher text, it would tell me what the encryption algorithm is?
What if I have the plain text? Is there something that can be done in that case?
No.
The whole point to encryption is to produce a cipher-text that is indistinguishable from random noise.
Absent any outside hints, the ONLY way to determine what encryption mechanism is used is to run the decryption routine with the correct password and check the result to see if it looks correct.
On a related note, likewise the only way to determine whether you're using the correct password is to run the decryption routine with the correct cipher and check the result.
As long as modern cryptography is used there is absolutely no way to determine what cipher was used.
However, if you have the plain text, and if at any point the PRNG stream from a stream cipher then you can decrypt unknown messages with a simple xor operation. PRNG reuse is nasty, but only a novice would make such a mistake.
A major tenant of encryption theology is that even if you know exactly how something is encrypted, you still have no better attack than a brute force search for the key.
On the other hand, if you found a pile of bits somewhere with a note attached that says "secret password is foobar" then it could be useful to have a dictionary of the common wrappers and file formats used by known encryption software. I've never seen one, but I'm sure the professionals have them.
There are two sides to your question:
If the encryption system is any good, its output is indistinguishable from random bytes. Therefore, encryption with algorithm A1 and encryption with algorithm A2 should be indistinguishable from each other, since both are indistinguishable from random bytes.
Cryptographers always assume that the attacker knows which algorithm was used. This is assumed because we do not know how much secure the algorithm name can be; after all, it is incarnated as software, in an executable file, and there is source code somewhere, and many people know which algorithm is used. It cannot be very secret. Thus, security analysis takes the cautious (if conservative) stance of considering that only the key is secret (that's what the key is for: to concentrate the secret).
Because of point 2, many encryption formats include headers (outside of the really encrypted part) which define quite plainly which encryption algorithm was used. It does not change security analysis, since we do the analysis under the assumption that any attacker already knows everything that the header contains. However, such a header is very convenient for application robustness; notably, it helps a lot for algorithm agility (the ability to support several types of algorithms).
For instance, an email encrypted with S/MIME is actually a CMS object (encoded in Base64 so that it can travel unharmed as an email) which contains a plainly visible specification of the encryption algorithm (type ContentEncryptionAlgorithmIdentifier
in the CMS specification).
Summary: although the encryption algorithm name cannot normally be recomputed from the encrypted data (whether you know the plaintext or not), that information can usually be obtained from the metadata which surround the encrypted blob, and that's not a security issue.
(Or rather, if knowing the algorithm significantly helps the attacker, then the algorithm is junk.)