What an error on storefrontbacktalk.com tells us

On Storefrontbacktalk.com, QSA Walt Conway talks about why encrypting short fields, like the expiration date of a credit card, can let an adversary decrypt your entire database. His conclusion is just plain wrong, but his article is actually very useful in other ways, because it may give us some insight into what the industry really needs.

First, let's see why Walt's conclusion is wrong.

If you encrypt a small field with non-randomized encryption, it may be possible for an adversary to carry out a chosen-plaintext attack. To do this he builds a table of all possible plain-cipher pairs and then uses that table to decrypt ciphertexts that he sees. But just because an adversary can do a chosen-plaintext attack does not mean that they can do a key recovery attack. That's typically much harder.

Building a table of all possible expiration dates is very feasible. Trying to recover a key that's used to encrypt all of those expiration dates isn't. This means that the fundamental premise of Walt's article is totally wrong.

That’s not surprising, however, because encryption is a tricky subject that’s often inaccessible to non-specialists. If we look at exactly what it means for encryption to be secure we see a good example of this.

There are actually several definitions of security for encryption, and each of these formalize what it means to be secure against the different types attacks that an adversary might try. One of the most common of these is IND-CPA security, which provides a careful definition of how hard it is for an adversary to carry out a chosen-plaintext attack.

The precise definition of IND-CPA security is fairly incomprehensible to non-specialists, so you can’t really expect them to spend the time and effort to understand it. If you’re not a crypto specialist, look at the Wikipedia article on IND-CPA security and see if its definition makes sense to you.

There’s another notion of the security of encryption that’s called “perfect secrecy,” and that’s really the security model that tokenization systems try to attain. This definition is also fairly incomprehensible to non-specialists, so even though tokenization systems violate the assumptions of the security model that they’re trying to meet, that’s not clear to most people.

On the other hand, there's a definite need for careful and precise definitions of what it means for encryption to be secure. These definitions are what you use when you prove that a cryptographic scheme is secure, and without these careful definitions, these proofs really aren't possible. The unfortunate side effect, however, is that things really get a bit too complicated for most people to understand.

In any event, if the subtleties of encryption and its security aren’t clear to a QSA, what that’s probably telling us is that there’s a need for some way for them to get complicated concepts explained to them in an easy-to-understand way. Maybe some sort of industry forum in which QSAs and others can ask experts about these things in a way that won’t make them feel foolish would be good for this.

I’ve found that having a few beers with the sales people selling crypto products is a fairly effective way to do give them a chance to ask questions about exactly how their technology works and why it’s secure, but that approach probably doesn’t scale very well. Maybe that industry forum would be a better approach.

Leave a Reply

Your email address will not be published. Required fields are marked *