4

I am trying to reverse engineer an unknown encryption algorithm. By this, I mean I dont know what kind of algorithm is used to encrypt the words.

But I know some input-output pairs. From this point what can I deduce/reverse engineer? Thanks

cekisakurek
  • 151
  • 1
  • 4
  • You want to determine the algorithm and not to decrypt the cyphertext, correct? – schroeder Apr 04 '16 at 16:22
  • I also want to decrypt other unknown texts. Since I dont know all the input-output pairs. –  Apr 04 '16 at 16:38
  • How do I move this question @AbuUbaidah ? –  Apr 04 '16 at 16:38
  • I would not vote to migrate this question, as it demonstrates a lack of understanding of basic cryptanalysis techniques. – Xander Apr 04 '16 at 16:46
  • is Can a known plaintext attack help identify the algorithm used for encryption another possible title for this question? – Mindwin Remember Monica Apr 04 '16 at 17:48
  • 1
    If this is proper encryption, then you're out of luck, as you don't know the key used for encryption you can't really distinguish the ciphertext from random data. If the transformation is public (like a hash), you could try common hashes and see if any pairs matches, but there's no systemetical way to deduce a crypto algorithm from known plaintexts. How are these pairs used and can a legitimate program recover the plaintext from the ciphertext? – SEJPM Apr 04 '16 at 19:04

1 Answers1

9

It is not possible to reverse-engineer a good encryption algorithm from plaintext/ciphertext pairs alone; it might not even be possible to test the validity of a guess unless a matching key is known (but it is often possible to rule out a guess; e.g. if individual cryptograms are 64 bytes, that's not RSA with a decent key size).

Among techniques to reverse-engineer a good encryption algorithm:

  • Using social engineering/bribery/spying to obtain info; experience proves that even partial info helps a lot.
  • Obtaining and analyzing a hardware implementation (e.g. using electronic or atomic-force microscopy).
  • Obtaining and de-compiling the object-code of a software implementation.
  • Getting extra information from a working implementation using some side channel (e.g. JTAG debug port; micro probing the bus, or for self-contained ICs perhaps with the help of ion-beam implantation technology; power analysis; timing); ideally, the attacker wants to see the data the algorithm is manipulating along its execution; but even lesser information is useful (e.g. if encryption timing varies as a deterministic function of the plaintext value for constant plaintext size, the algorithm is not a plain implementation of Salsa).
  • Using fault injection to cause nasty things to happen (like, glitching the power supply or lighting the IC with a laser pulse at reset, in hope of entering a debug mode that allows the attacker to reach one of the previous goals); also, careful examination of erroneous data output caused by fault injection might allow confirming an hypothesis on the algorithm, and finding the key.

Reverse engineering a bad encryption algorithm depends very much on the algorithm; sometime it is possible, there are even generic techniques for entire classes of algorithms, see this for anything affine, including linear.

Community
  • 1
fgrieu
  • 140,762
  • 12
  • 307
  • 587