The following is an excerpt from Cryptography in the Database: The Last Line of Defense.
Cryptographic attacks
Cryptographers classify attacks against cryptosystems into several categories. These attacks attempt to either retrieve the key or expose the plaintext. The algorithms discussed in this book are strong and resist all the attacks discussed here. However, the demands of a practical cryptosystem can easily introduce vulnerabilities even though the algorithm itself is strong. Much of the design presented in this book is aimed at mitigating these weaknesses.
A known-ciphertext attack is what most people think of as a cryptographic attack. The attacker has access only to the ciphertexts produced with a given key. These attacks can target either the key or the plaintext. Generally, we'll assume that the attacker has all the ciphertexts.
In the case of a database, this is tantamount to the attacker's having access to the database. Perhaps the attacker has found a weakness in the operating system that allows the database file itself to be downloaded, or perhaps a SQL injection attack is exposing the encrypted data. A properly placed insider often has easy
access to all the data.
When the attacker has access to both the plaintext and the ciphertext, the attacker can mount a known-plaintext attack. People new to cryptography often dismiss known-plaintext attacks as a sort of "cheating." After all, if the attacker already has all the plaintexts, all the secrets have been exposed. We generally assume, though, that only some of the plaintext-ciphertext pairs are known. Perhaps all the past plaintexts prior to a certain date were compromised. The goal of a known-plaintext can be to recover the key or to uncover plaintext.
In a database context, it is often not too hard to find known plaintexts. The system might temporarily cache the plaintext prior to encryption, or the system might store the data unencrypted elsewhere in the system. This last case is far more common than you might think. For instance, say customer data is stored encrypted, but the data is decrypted in order to e-mail the invoice. The invoice might very well be stored in the database as well. If the invoice isn't also encrypted, the attacker has a source of plaintexts to match with ciphertexts.
An even more subtle example is when data taken together must be encrypted but when the data is separate, it can be unencrypted. For instance, a customer's name and credit card number might be encrypted when they are together in the order table. But another table, in the call tracking system, perhaps, might have the customer's name unencrypted. If these two tables can be linked in a series of joins, the attacker has access to the plaintext. Database normalization can help security in this case, but in practice many databases are not highly normalized, so leaks like this are common.
As its name implies, a chosen-plaintext attacker can construct plaintext for the system to encrypt. This is a much more powerful version of a known-plaintext attack. An even more powerful variation is when the attacker can experiment by constructing new plaintexts based on the results of previously constructed plaintexts.
This attack is generally quite easy to mount against a database. In the case of an online ordering system, the attacker simply places additional orders with whatever data he would like to see encrypted. If he would like to see the ciphertext for "Kenan," placing a false order with that information would be suffucient. Unless the cryptosystem is designed carefully, the attacker would then be able to identify all the rows in the table with an order for "Kenan" (and encrypted with a particular key) by searching for the ciphertext produced by the chosen-plaintext attack.
