

Phil Zimmermann: Beware of Snake Oil Crypto (1997) - bdhe
http://www.philzimmermann.com/EN/essays/SnakeOil.html?

======
tptacek
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.

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

~~~
tptacek
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).

~~~
pnathan
I'm going to presume you also by that imply "read _all_ the standard texts,
seminal papers, and current state of the art papers".

~~~
timsally
You'll want to follow people in the industry as well (I've found Nate's blog
in particular an enjoyable read). A lot of the practical knowledge accumulates
in the brains of the guys who actually get hired to do crypto work. It's an
interesting feedback loop to be sure.

Also, it's my impression that start of the art papers aren't really necessary
to start off with. The implementation errors people make in their code are
flaws that have long been published, sometimes for decades.

~~~
tptacek
Crypto papers actually kind of suck; my experience is that roughly 2/3rds of
the time, the complicated formula on the page works out to a "for" loop that
would be trivially easy to understand if expressed in algol syntax.

Best advice: do deep research on TLS. For every feature, do a directed search
of the literature and do experimentation to try to figure out why that feature
is there. Most of the features in TLS exist as a countermeasure to some
attack. Follow this tack all the way down the stack, starting with the high-
level protocol features and working your way all the way down through the
block cipher modes and configuration that it uses.

~~~
timsally
Yeah there definitely is a bit of an art to reading them. But we can't have
cryptographers and security professionals merging too fast... that would just
make too much sense. :P

------
RexRollman
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.

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

------
stoph
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.

~~~
tptacek
Yes.

------
matthavener
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

~~~
tptacek
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.

------
dublinclontarf
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.

~~~
tptacek
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).

~~~
listrophy
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."

~~~
tptacek
Saying "AES-256-CBC and RSA 4096" isn't nearly enough detail to assess whether
you know what you're talking about, and pushing me through a thread to the
limit of what I personally know how to break is just going to give you false
confidence, because I know less than a lot of people I know.

In case this is what you were implying: it is absolutely _not_ the case that
the big problem with OpenSSL is that it'll let you use Camellia in ECB or 512
bit ElGamal. The problem is that there are (a) more things you can do terribly
wrong with AES-256-CBC than there are things you ar likely to do with wrong
with, say, C memory handling, and (b) things you have to do well beyond
encrypting soundly with AES-256-CBC to make your system work as a whole.

~~~
listrophy
As with all things security, nothing is absolute... your reply is well
received. Thank you.

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

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

~~~
eru
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.)

------
16s
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?

