Oh, The Bad Crypto You’ll See (an open letter)

Thomas Ptacek | July 25th, 2006 | Filed Under: Bitching About Protocols, Defenses

Dear Software Development Industry,

Please stop writing your own crypto code. You aren’t qualified. I know that sounds harsh, but here’s how I know I’m right: I’m not qualified to build cryptosystems, and I can find the flaws in your products. The history of your present efforts is one of repeated injuries and vulnerabilities. To prove this, let facts be submitted to a candid world:

1. You have used ECB encryption, often without even knowing it; ECB is what is accomplished by repeatedly applying the AES block function in a “for” loop. The deficiency of ECB is so simple that it can be demonstrated with a picture:

   

   The bottom image has been “encrypted”, using a strong passphrase, with 128 bit ECB AES. But one block of 16 “black” bytes is the same as any other such block, all of which ECB encrypt to the same ciphertext.

   “Seeing through” encrypted bitmaps is not the practical problem with ECB. Replayability is. In your lock-step client/server protocols, where messages can be distinguished by size, direction, and protocol iteration, this weakness is intolerable.

2. You have confused encryption with authentication, in the belief that forcing an opponent’s injected message to decode to gibberish is a defense against forgery. Injecting gibberish is the greater part of what your opponent is trying to accomplish, and because you aren’t encrypting the passage of time, you concede to your opponent the placement of that gibberish as well.

3. You have relied on key exchange for authentication, perhaps believing that an attacker who has expended the effort to write a malicious client to your encrypted server has exhausted herself and will be incapable of writing a malicious proxy server to complete the circuit. Neither an RSA key without a verifiable signature, nor an RSA key whose signature you fail to verify, nor the MD5 of a public certificate without confirmation that the opponent holds the corresponding private key tells you anything about the identity of a caller.

4. You have failed to check parameters, and if you believed detecting malicious input was hard when working with SQL metacharacters, try it modulo a large prime number. A number raised to the 0th power is 1, even mod p.

I could offer individual solutions to each of these flaws (CBC or CTR mode, HMAC, etc). But as I said before, I’m not qualified to do that, and you aren’t qualified to evaluate my advice. Your only reasonable option is to fall back on the competence and experience of those who are qualified. And that means that if you’re trying to:

• encrypt data sent over the wire so I can’t read it, or

• use crypto to verify the integrity of that data so I can’t fake it, or

• use crypto to verify my identity, then

you are going to use TLS, with a peer-reviewed library, meaning, the same one everyone else uses.

Sincerely,

Matasano Security