I have an encrypted configuration file from an embedded device which I'm trying to decrypt. The file seems to be encrypted in 128bit blocks, as changing a single option causes a 16 byte block to change (all bytes change). The file appears to be encrypted in ECB mode, as blocks of all-zeroes are always encoded the same way.

Is there any way of determining the cipher used, and what are the chances of a known plaintext attack?

  • 3
    $\begingroup$ There is only a handful of practically used ciphers of this block length; however, for most (all?) of them, determining the key will be infeasible. $\endgroup$
    – yyyyyyy
    Mar 8 '15 at 19:22
  • $\begingroup$ I see... Which ciphers do you have in mind? $\endgroup$
    – jclehner
    Mar 8 '15 at 19:25
  • 6
    $\begingroup$ All AES finalists would be a good start to consider: AES (Rijndael), Serpent, Twofish, RC6, and MARS. Being able to distinguish the used cipher would be the first step in breaking the algorithm. With secure algorithms and a random key, it should be not possible to get the used cipher. $\endgroup$
    – Nova
    Mar 8 '15 at 19:37
  • 2
    $\begingroup$ With modern ciphers, it's impossible to reverse engineer an encryption algorithm by looking at (plaintext, ciphertext) pairs. You need to reverse engineer the encryption or decryption code instead. $\endgroup$ Mar 9 '15 at 20:23
  • 1
    $\begingroup$ If you can control part of the plaintext that gets encrypted, you can potentially break this trivially. $\endgroup$ Mar 10 '15 at 22:00

All modern block ciphers are supposed to be pseudorandom permutations, meaning that they cannot be efficiently distinguished from a truly random permutation without knowledge of the key. (If a practical distinguisher were to be found for a particular cipher, that cipher would be considered broken by modern standards.)

This also implies that no two secure modern block ciphers (with the same block size) can be practically distinguished from each other, unless one knows the key being used. Thus, unless the cipher being used is broken, or unless you can somehow find out the key, the answer to your question is "no".


Perhaps. You indicate this is from an embedded device. This strongly implies everything the device needs to decrypt it is already present in the firmware of the machine, including both the algorithm and the key.

Here is a blog post on how a talented engineer accomplished a similar feat through reverse engineering. Note that this was not a cryptographic feat, but a reverse engineering feat.


There have been few tries to identify unknown cipher algorithms from couples plaintext/ciphertext , that paper describes a possible way of doing it using a mixed approach with pattern recognition , neural networks and entropy.

  • 1
    $\begingroup$ Alas, the one thing the paper does not seem to include is any kind of demonstration that their method actually works. In fact, for modern block ciphers with the same block size, I can fairly confidently assert that it doesn't -- if it did, the authors would be famous. (They do suggest that their program may also use side channel information, so it's somewhat plausible that it could e.g. be able to distinguish DES from Blowfish based on the time needed to encrypt a message; but that'll only work if such timing information is actually available.) $\endgroup$ Mar 10 '15 at 19:47
  • $\begingroup$ yes it isn't clear if it is a concept or if they actually developed a prototype which worked, apparently they have developed some programs in the context of this paper. $\endgroup$
    – user23258
    Mar 10 '15 at 20:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.