[Cryptography] Crypto best practices

[Jerry Leichter]

> ...It's the "RC4 all over again" thing, we have about two
> decades of experience showing that if you give J.Random coder a stream cipher
> to use for data encryption, they're probably going to get it wrong.  Even
> experts get it wrong, e.g. tarsnap (although in that case I'm not sure if the
> lesson is "stream ciphers are too dangerous to use" or "CTR mode is too
> dangerous to use")....
I think this actually is an instance of a deeper, much more difficult problem.

When we do cryptographic *theory*, we naturally try to "divide and conquer":  We look for secure pseudo-random stream generators, secure block ciphers, secure public key systems, secure signatures, and a number of other "primitives", which in turn we sometimes break down even further to simpler "primitives".  Having created a nice working collection of primitives, we find secure ways to combine them - e.g., we build HMAC out of one-way functions.

Similarly, when we program, we "divide and conquer", deliberately producing small reusable blocks that we can "mix and match" to produce larger programs.  In fact, a large fraction of "programming" today - most of it, in some domains - is done by searching the Web for a bunch of pieces and gluing them together.

But then programmers look at the collection of cryptographic "primitives" the cryptographic theorists have produced and view them as a set of reusable modules.  That's how we get the kind of combinatorics you see in SSL/TLS:  Pick your key agreement algorithm (historically since SSL2.0 there have been 20, according to https://en.wikipedia.org/wiki/Transport_Layer_Security); pick your cipher/mode of operation (one of 16; SSL/TLS hasn't let you pick cipher and mode of operation separately but, hey, why not).  Not even specified is how you pick your random number generator and nonce generator - that's considered private to each party, though really you might want to be able to validate your counter-parties choices.

Programmers look at the options and say "that's agile, that gives the user maximum flexibility - fantastic, thank you cryptographers".

But ... the problem is that cryptographic primitives *are not recombinable modules*. Many - likely most - combinations of secure primitives are insecure.  HMAC was developed because it was "obvious" how to combine the operations of "agree on a secure key" and "one way hash" to produce a MAC.  Except that the "obvious" combinations don't work, and proving HMAC secure was worthy of publication as a significant advance in cryptographic theory.

*Secure cryptographic primitives don't combine securely.*  If we could teach programmers that unfortunate truth, we'd get many fewer cryptographic disasters.  Choice here is *not* your friend.

By the way, this problem is in turn a particularly bad special case of a broader issue in security:  We don't know how to compose secure modules into larger systems and maintain their security.  Oh, there are some particular constructs that retain the required security properties, but often they don't meet other functional requirements.  The notion of a security boundary - e.g., a firewall through which all connections must flow - is great and allows you to generalize from the security of the firewall to the security of the system it protects - but only with certain assumptions about how the system will be used and how it will be attacked.  Unfortunately, your attacker isn't bound by those assumptions....

                                                        -- Jerry