How would I reverse engineer a cryptographic algorithm?

Question

I wrote an application that encrypts text in this way:

1. Get the input text

2. Reverse the text

3. Convert to hexadecimal

4. <

Answer 1

In order to break a cipher, cryptanalysts use all the information they can gather. Attacks fall into a number of categories, depending on what is known. Some of the main attacks, from hardest to easiest, are

• ciphertext-only: this is the hardest attack. The analyst tries to collect as many encrypted messages as he can, and analyzes them to look for patterns or biases in the frequency of symbols. However, with good, modern ciphers, there are no patterns. This is infeasible with a good cipher, properly used.
• known-plaintext: having the plaintext corresponding some ciphertext is a big step toward recovering unknown plaintext from new ciphertexts. This is where "reverse-engineering" really begins, because he can test his hypotheses about the algorithm against known input and output. In World War II, cryptanalysts worked hard to build extensive lists of "cribs"—words that were likely to appear in the enemy's messages—to exploit known-plaintext attacks. For example, weather conditions on a particular day, or place names of battles, etc. were likely to be reported to headquarters in encrypted messages.
• chosen-plaintext: even better is when the cryptanalyst can trick his enemy into encrypting a message created by the cryptanalyst. In wartime, sometimes fake information would be leaked to the enemy, hoping that it would be encrypted and help the cryptanalyst break the code.
• adaptive chosen-plaintext: this is sort of an iterative approach to known plaintext. The cryptanalyst can repeatedly have his chosen-plaintext encrypted by the system, and looks at the results to adjust his next attempt.

Nowadays, likely ways to break a code are through flaws in the system. For example, poor key management might be used, allowing the key to be stolen or guessed. In other cases, a "side-channel" attack might be used. For example, by carefully measuring the time it takes for certain cryptographic operations, an attack might be able to guess that certain bits or bytes of a key are zero, causing a fast path through some algorithm.

Up near the "tinfoil hat" end of the spectrum are methods to intercept radio emissions from computing equipment. This allows a remote agent to "see" what is displayed on a monitor. There are even specially designed fonts to try and disrupt this sort of eavesdropping.

Answer 2

You would need a larger text base than that and some understanding that the crypt is coming from a particular language/domain. Then based on the frequency of words in that language/domain, one could potentially decipher certain attributes form the text.

Of course, good ciphers work around this. Only poorly implemented ciphers can be broken easily with this method.

Answer 3

You'd be able to try guess the algorithm if you know how to decrypt it. I can create many algorithms that would result in "A751CD9E1F99" for some input.

Now, if you have many inputs / outputs available, you could try changing only a little your input to see what happens to the output, for instance. Good encryption algorithms usually result in major output changes for minor input changes.

Answer 4

An attacker would probably (in general) do the followings:

Identify and defeat any 'visible for the eye encoding' or trivial crypto, like reversing of text, Base64 encoding, ROT13, ect.

At a point that they find a high entropy state they try to acquire more pieces of encoded data, and XOR them together. This results in an XOR-ing of the two original plain-text with the key cancelled out in case the encoding is indeed XOR based (like RC4) and the key was constant. If the attacker can get hold of any plain-text - encoded data combination, all other encoded data is decode-able.

At final desperation they may try to test against most common practices, like where they use RC4 or other simple algos with a dynamic key, and put the key on the end or beginning of the file/data.

If they only have access to encoded text, this is pretty much the end of the road. In case they have a access to.. like an API where they can produce the encoded version of a supplied plain-text, then they will trivially identify if its a bit based (like XOR), or block cypher, or feed forward block cypther encoding, but the getting the key and the actual algo is still a problem.

If they have access to the decoding program for symmetric key encoding (like your XOR), or the encoding program of asymmetric key encoding, the encoding is most likely instantly defeated by reversing it.

Answer 5

I think you should start by reading The Code Book. What you are asking is how to crack encryption methods and that will give you a start as to how they work.