[Cryptography] [cryptography] Underhanded Crypto

[Jerry Leichter]

On Nov 27, 2014, at 11:31 PM, Peter Gutmann <pgut001 at cs.auckland.ac.nz> wrote:
>> Yes, it may be difficult. Note that "difficult for the organizers to verify"
>> might imply "difficult for anyone in practice to verify" so that may be an
>> avenue towards a good submission.
> That's actually a bit of an indictment of crypto protocol implementations,
> that they have to be so complex that there's no easy way to verify them any
> more.  I've noticed this with crypto in embedded systems, the entire RTOS and
> control system is a minimal, fairly easily-assessed system all nicely done to
> something like IEC 880, and then the security/crypto portion is five times the
> size of all the rest combined and so complex you can never really be sure it's
> doing what it's supposed to.
That's a wonderful (and scary) point.  It's obvious when you point it out, but I must say I've never focused on it as a general property - just as a property of *particular* protocols and implementations, SSL in particular.

Many years back, I was pushed into doing a protocol and crypto implementation for a system I worked on.  (It had been designed so it could work easily through an SSH tunnel, but that was seen as too complicated.  For various reasons, some better than others, we needed to do pretty much all the work from the ground up.)  The design I came up with was actually pretty simple and not a hell of a lot of code - but then I knew about holes in it when I designed it.  We didn't have the time or manpower to do even what we would have considered a reasonably secure design and implementation.  (In fact, while it had a space for authentication using a novel technique that I still think was clever - though it's mainly obsolete due to the later development of combined encryption / authentication modes), we didn't have a chance to fill it.)  Some of the basic techniques were taken from the leading-edge crypto papers at the time - but have since been shown to be flawed.

Converting what we built into something actually up to today's standards would have required several times as much complex, finicky code as was already there.

(The most ... interesting ... discussion about the system was with a military contractor who wanted to use the thing in a tank communication platform.  They started asking about how we did our crypto.  After explaining a bit, I asked them if they *really* wanted to rely on a crypto system a small company had designed and built - didn't they just get crypto boxes from NSA?  We left it at that.)

Anyhow ... are we really in the situation where the complexity of the protocols is great enough that we simply *can't* get them right?  The attacks of the last year, from Heartbleed to Poodle, certainly point in that direction.  Yes, Poodle was an attack against a protocol that should have died years ago - but security is a *system* property, and if we can't get old protocols to die when they must, out *system* isn't secure.

It's not easy to come up with solutions.  Some of our "best practices" make things worse:

1.  The insistence that you don't "roll your own" crypto.  If crypto from the experts really was solid, this might be good advice.  But what *that* is fragile, it creates a monoculture in which any failures have very broad effects.

2.  The insistence that systems be universally useful, rather than one-off's, ties into 1.  It also guarantees complexity.

3.  The insistence on covering every attack that anyone has thought of forces complexity.  Yes, attacks always get better.  Yes, you don't know the capabilities of your attackers.  But just how much security do you *really* need on your credit card number?  On your tax information?  Pretty much everything most people want their crypto to protect is available in other ways.

Would we be better off with a large variety of "good enough" simple designs and implementations which could reasonably be verified, than with a few "crown jewel" designs and implementations that no one can realistically have any confidence in?  At the least, this may be the best approach to stopping the mass surveillance we now know is being practiced - which has been combined with subtle "supply chain" attacks against the very "crown jewel" protocols and designs we've relied on.
                                                        -- Jerry