The field of cryptography is full of pitfalls. The same can be said about computer science in general, but in cryptography the pitfalls have a distinct character: you may never learn that you have fallen into one.

Let me give an example. Suppose you want to move N bytes starting at address A to the area starting at address B. Since every problem has a simple, fast and wrong solution, one can think that the problem can be solved by a simple loop that moves every byte number X from the first area to the second, where X goes from 0 below N. Once you try to use your program with overlapping areas, you will know that you have fallen into a pitfall: the copy will not look like a copy at all!

Let me now give a cryptographic example. Suppose you want to encrypt a message and decide to use the CTR mode. If you reuse the nonce (IV) for a different message, you compromise confidentiality of your messages, but you may never learn about this: the messages look as scrambled as they were with different nonces.

The confidentiality failure in this example is easy to show. For messages A and B and keystream X, the ciphertexts are A+X and B+X. If an attacker learns one message, he can calculate X and then the second message.

Not all cryptographic pitfalls are that easy to explain. Moreover, it seems that developers are not eager to fix the security problems unless there is a graphic depiction of the failure.

The padding oracle attack was published in 2002:

In many standards, e.g. SSL/TLS, IPSEC, WTLS, messages are first pre-formatted, then encrypted in CBC mode with a block cipher. Decryption needs to check if the format is valid. Validity of the format is easily leaked from communication protocols in a chosen ciphertext attack since the receiver usually sends an acknowledgment or an error message. This is a side channel.

In this paper we show various ways to perform an efficient side channel attack. We discuss potential applications, extensions to other padding schemes and various ways to fix the problem.

but it turns out that even in 2010 many developers continue to make the same mistakes over and over again:

we show that widely used web development frameworks and web sites are using encryption incorrectly in a way that allows attackers to read and modify data that should be protected. It has been known for years in the cryptography community that encryption is not authentication. If encrypted messages are not authenticated, data integrity cannot be guaranteed which makes systems vulnerable to practical and dangerous chosen-ciphertext attacks, one of them being the padding oracle attack presented by Vaudenay at EuroCrypt 2002

What is the proper way to solve all such cryptography misuses once and for all? One approach is to educate the developers, but the experience shows that this approach is not that effective as one may hope. Another approach is based on the observation that if you cannot educate everyone who will use your tools, it pays to make tools that are hard to misuse.

Consider the CBC mode of encryption. One of its main drawbacks is that the message must be padded to a multiple of the cipher block size. This does not only increase the ciphertext size, but also allows to check the integrity of the padding during decryption. In most cases the size increase is negligible, but the ability to &lquot;check&rquot; integrity gives a false sense of security. This misunderstanding leads to spectacular attacks.

Recently, NIST published an addendum that will probably do more to prevent the CBC misuses, than all the warnings that CBC does not provide authentication:

This addendum to [NIST Special Publication 800-38A] specifies three variants of CBC mode that accept any plaintext input whose bit length is greater than or equal to the block size, whether or not the length is a multiple of the block size. Unlike the padding methods discussed in [SP 800-38A], these variants avoid ciphertext expansion.

The new mode does not only save space, but the fact that there is no authentication becomes obvious: if you change a bit in the ciphertext, then some plaintext becomes gibberish, but the decryption function does not even notice.