Cryptography is a fun but tricky art. Almost every programmer has at some point in their career tried to write their own cryptographic algorithms. While the computations used to create the resulting encrypted output may be complicated and seem rock solid, usually custom cryptographic algorithms end up falling for one or more classic crypto pitfalls.

Substitution ciphers

While you may have pages upon pages of input manipulation, many custom written algorithms result in simple substitution ciphers. The most basic example, ROT13, shifts each English letter 13 spaces, wrapping around at "Z". This simply replaces "a" with "n", "b" with "o", "c" with "p", and so on. Thus "Apple Baker" becomes "Nccyr Onxre".

Custom ciphers usually create a much stronger illusion of security because the resulting output is less legible than the input. However this doesn't change the fact that the cipher boils down to a degenerate substitution cipher, which can be cracked fairly easily. Some would even consider substitution ciphers to be obfuscation, rather than a cipher in it's own right, they are so breakable.

Poor key strength

Ideally the security of a cryptographic algorithm should depend on the strength of the keys used for the encryption. Take for example an algorithm which relied on XORing[1] the unencrypted input with a stream of data. In this case, our stream can be considered a key[2]. So, say your key (some string of bytes) was 100 characters long in this case - that'd be plenty to protect a message that was less than 100 characters long. But if you needed to keep reusing that key for a 1 Mb message, a cryptographer would have a much better chance of deciphering the message.

...


Click here to go to this article.