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:

    text, before and after ECB

    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

Viewing 4 Comments

    • ^
    • v
    Excellent post. A key point that I think should be emphasized is that there are only 2 categories of manufacturers.

    You're Not Special (98%):
    Separate your marketing department's claims about your product's external view from the internal design. Nearly all problems boil down to ones already solved by existing protocols and libraries. Encrypting a file? GPG. Sending anything over the wire? TLS/SSL. Your special sauce is in how you glue all these things together to make some product. Don't reimplement these, and still get review of how you've glued them together.

    You Are Special (2%):
    You are Voltage and you were founded by Dan Boneh. Or your business is cryptanalyzing products in concert with Adi Shamir. Note the most important part here -- if you're special, you are willing to plunk down $400/hour for a full-time cryptographer for at least 6 months.
    • ^
    • v
    A very good post indeed, highlighting the problems faced with teams implementing their own cryptography.

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

    That's most definitely a key point to get across which in most cases gets brushed under the carpet and as Nate posts above, there's only a small fraction of people who shouldn't be doing this, the reality however is unsurprisingly common.
    • ^
    • v
    Sure it's easy to rant, you've made all good points, now would you like to recommend any companies or schools where ISVs can hire people to fix these problems? The issue here is two fold 1) ISVs can't do crypto properly themselves 2) They don't know where to go to get it done properly when they acknowledge the need.
    • ^
    • v
    ISVs should assume they are doing something wrong the moment they start contemplating "interesting" cryptography. Like Nate says, if you're encrypting files, use PGP. If you're encrypting traffic, use TLS. In both cases, they should
    actively tend to the most popular implementations (OpenSSL, GPG), because those are the ones that receive scrutiny.

Trackbacks

close Reblog this comment
Powered by Disqus · Learn more
blog comments powered by Disqus