Phil Zimmermann: Beware of Snake Oil Crypto (1997)

http://www.philzimmermann.com/EN/essays/SnakeOil.html?

by bdhe • 15 years ago

70 42 15 years ago

tptacek15• 15 years ago

Virtually all AES/RSA/SHA256 cryptography outside of a very few well-known, well-regarded cryptosystems is effectively snake oil.

It's a credit to Zimmerman's article that he doesn't leave it at "don't write your own block ciphers", adding that you need to understand block cipher modes (we should stop calling ECB mode "ECB mode", by the way, and start calling it "the default mode"). But obviously, this 1997 article doesn't nearly cover the bases on all the other things you have to do correctly to not end up with trivially breakable cryptography. A lot of those things weren't even known to the public in 1997.

An even more important point is that Zimmerman is talking about cryptography implemented in its strongest, safest venue: data at rest. As implemented by most developers today, crypto ends up in a far more exposed venue: one where a server holds a secret key and uses crypto not to protect a file but to enforce policy. Despite being the 2011 common case for crypto, this is a far harder scenario to get right, because adversaries can devise ways to query the key-holder to learn things about the plaintext, ciphertext, and behavior of the system as a whole.

My advice: don't trust crypto at all outside of TLS, GPG/PGP, and SSH. And know that of those three systems, two were broken relatively recently.

dublinclontarf2• 15 years ago

> My advice: don't trust crypto at all outside of TLS, GPG/PGP, and SSH. And know that of those three systems, two were broken relatively recently.

Good advice, but they weren't broken, just mistakes in their implementation.

tptacek15• 15 years ago

That is first of all not true, and second of all not relevant. In both cases the cryptosystem itself had a design flaw. And in both cases the implementations of that cryptosystem, aside from the design flaws, had implementation flaws that made the design a moot point.

rdl• 15 years ago

Even using those, people will mess up key management and other security critical aspects.

tptacek15• 15 years ago

I'm a little allergic to allusions to the risk of "key management", because Applied Cryptography (not a good book) calls that out specifically as the riskiest thing about implementing crypto, and it is most definitely not the riskiest thing about implementing crypto.

So let me just say that while key management is hard, even if you stipulate that your key management is perfect, you are probably still boned. The simple task of exchanging real time messages between two parties with secure keys is treacherously hard to implement.

pnathan2• 15 years ago

What advice would you give to someone who did realistically want to work in, implement, and evaluate industrial-strength crypto?

tptacek15• 15 years ago

Spend 6-8 years breaking it.

(I haven't spent that much time on crypto, and so as a general rule we don't do implementation projects).

palish• 15 years ago

Which two?

amalcon• 15 years ago

All three have had flaws of one sort or another discovered since 2005 (TLS has had several; OpenSSH had the Debian keygen thing and an SSHv1 vulnerabiity, and possibly others; GPG apparently had a couple of problems back in 2006).

TLS has definitely had more severe issues, but then, it's also the most widely deployed (so undiscovered flaws are more likely to be discovered). On the other hand, it's also solving the most complicated problem of the three.

dublinclontarf2• 15 years ago

We now have GPG, openssl (not the best software, but after so many iterations can be considered...decent) and openssh.

But even then with these great libraries there is much room for mistakes, openssl is just horrible to use IMO.

matthavener2• 15 years ago

OpenSSH uses OpenSSL for crypto

yuhong2• 15 years ago

Yea, OpenSSL can be used as part of a stack. tptacek is objecting to developers using OpenSSL directly.

tptacek15• 15 years ago

OpenSSL is the worst kind of crypto library: the kind that gives you a menu of ciphers and a menu of cipher modes and says "go to town". There is virtually no chance that a generalist developer will ever build sound crypto with a library like that.

The good kind of crypto library is Keyczar. Keyczar removes degrees of freedom; it says, "you don't tell me what block cipher to use, and you don't remember that your messages need a MAC, and you don't choose the order operations happen in, and your keys are all going to be from a CSPRNG, and you'll use this keystore, and that will be that". There are a very few other libraries like that (Guttman's cryptlib is another).

Unfortunately, nobody uses libraries like that. They use OpenSSL (via their language's bindings to it) which seems to work until it blows up in their face during a pentest.

My best advice is to use Bouncycastle's PGP implementation, which again removes all the degrees of freedom and has the benefit of building on very well studied constructions (poorly regarded constructions, but survivors nonetheless).

wingo• 15 years ago

What do you think of GnuTLS, Thomas?

listrophy2• 15 years ago

What about writing a library that wraps OpenSSL and only implements a couple, strong ciphers/modes? Specifically, AES-256-CBC and RSA 4096?

I mean, I've done my homework: I know enough to not call myself an expert, yet also know enough to avoid every crypto-algorithm like the plague until I've thoroughly investigated it and its "competitors."

caf3• 15 years ago

OpenSSL does at least provide some high level interfaces now - EVP_Seal* & EVP_Sign* (and their inverses, EVP_Open* and EVP_Verify*) seem reasonable.

matthavener2• 15 years ago

This article skips over CTR mode which is gaining popularity. It has nice properties like parallel enc/dec, no padding requirement, seek to any block, and the ability to lose blocks. AES 128 CTR is the default cipher suite in the SRTP standard

tptacek15• 15 years ago

This article was written in 1997.

Today, your reasonable choices for block cipher modes are CTR and CBC.

And: (If you have a library that does any of the "authenticated modes" like CCM, OCB, GCM, or EAX, your reasonable choices are those 4 constructions, all of which are based on CTR mode.)

But your comment gave me hives, because CTR mode is in its most simple application (no parallel, no precomputation, no seeking, no lossiness) already easy to spectacularly fuck up, and some of the things you pointed out as benefits of CTR come with additional pitfalls.

Finally, what is a "default" in a standard is different from a "default" as provided by a library. ECB is the "default" because (a) it usually is the default, and (b) it requires the least amount of configuration. In 2011, it is still sadly common to see trivially breakable ECB in new apps, and that's because crypto libraries are structured in ways that make ECB the de facto default.

RexRollman• 15 years ago

When I opened this up, I thought for sure that cperciva would have commented on this. Must be a busy day.

And I personally think we all own Mr Zimmerman a debt of gratitude. I don't think I could have handled the stress of what he had to go through with the US Government.

tptacek15• 15 years ago

Give him time. He'll show up, and I'm sure he'll disagree with half of what I've said.

16s• 15 years ago

This is why I feel that all password managers that store passwords are fundamentally flawed. Who has verified the crypto used to store the passwords? Has it been implemented by devs who thought they knew crypto (but really don't) as this article suggests?

eru3• 15 years ago

Phil Zimmermann talks about some patents on public key cryptography. I am just wondering, did Clifford Cocks prior art invalidate that patent posthumously?

tptacek15• 15 years ago

When Zimmerman wrote that, you'd get sued by RSA if you shipped a product with public key crypto in it. Those patents expired.

eru3• 15 years ago

Yes, I know. But wouldn't the British chap's prior art make those lawsuits invalid retrospectively?

I don't know enough about even my own countries' legal systems, and certainly not about America's. So my question is: Supposed you got sued back then, had to pay, and now try to get the money back, because the patents the suit was based on were invalidated by prior art. Would that work? (Sorry, not a crypto-question at all, more like a legal one.)

stoph• 15 years ago

Is there any connection to be made between this article and the usage of signed cookies to hold session state? Database-backed sessions hold a state that you know your application set at one point, but a signed cookie, if forged, could have much bigger ramifications. Since no one gets cryptography right, it seems like this would be another instance not to trust it.

tptacek15• 15 years ago

Yes.

Phil Zimmermann: Beware of Snake Oil Crypto (1997)

Related Stories