[Cryptography] Opening Discussion: Speculation on "BULLRUN"

Jon Callas jon at callas.org
Thu Sep 5 23:54:47 EDT 2013

Hash: SHA1

On Sep 5, 2013, at 8:02 PM, Jerry Leichter <leichter at lrw.com> wrote:

> Perhaps it's time to move away from public-key entirely!  We have a classic paper - Needham and Schroeder, maybe? - showing that private key can do anything public key can; it's just more complicated and less efficient.

Not really. The Needham-Schroeder you're thinking of is the essence of Kerberos, and while Kerberos is a very nice thing, it's hardly a replacement for public key.

If you use a Needham-Schroeder/Kerberos style system with symmetric key systems, you end up with all of the trust problems, but on steroids.

(And by the way, please say "symmetric key" as opposed to "public key" -- if you say "private key" then someone will inevitably get confused and think you mean the private half of a public key pair and there will be tears.)

> Not only are the techniques brittle and increasingly under suspicion, but in
> practice almost all of our public key crypto inherently relies on CA's - a structure that's just *full* of well-known problems and vulnerabilities.  Public key *seems to* distribute the risk - you "just get the other guy's public key" and you can then communicate with him safely.  But in practice it *centralizes* risks:  In CA's, in single magic numbers that if revealed allow complete compromise for all connections to a host (and we now suspect they *are* being revealed.)

I have to disagree. You don't need a CA. 

There's a very long rant I could make here, and I'll try to keep it a summary.

Much of the system we have is built needing CAs, but it was only built that way. A long time ago, the certificate structure we're still vestigially using had as one of its goals a way to keep the riff-raff from using crypto. I remember when I got my first PEM certificate, I had to send my blinking passport off to MITRE for two weeks so they could let me encrypt the crapola that was sitting on my disk unencrypted. It was harder to get a cert than it was to get a visa to Saudi Arabia! So much of what we would have encrypted we just printed on paper and put in a file cabinet. Excuse me, I'm starting on that rant I said I wouldn't do.

The major problem one has with public key is knowing that the public key of the endpoint you want to talk to us actually the right public key. Trusted Introducers of any sort are one way to solve the problem. CAs are merely an industrialized form of Trusted Introducer and not ipso facto bad. The way that "Web PKI" (as it's now being called) is using Trusted Introducers is suboptimal, but ironically, we are on the inflection point of a real honest-to-whomever fix to them in the form of Certificate Transparency. That suggests even another discussion, one that I promised Ben I'd get to eventually.

The major problem with the certificate system is actually the browsers, in my opinion, because they actively discourage using certificates in any other way. If browsers, for example, allowed you to use a private cert with a user experience that was ultimately SSH-like (also called TOFU for Trust On First Use) as opposed to putting big blood-red danger warnings up, it would work out better for everyone including the CAs.

But anyway, there are other solutions. They range from some variant of Direct Trust being TOFU or even using a Kerberos-like system to hand you a key, or what we do in ZRTP, or lots of other things. 

The bottom line is that if you want to send someone a message securely and you have never talked to them before, you have no other way to deal with it than public key systems. 

(Or you can re-define the problem. Suppose I want to send Glenn Greenwald a message and his Kerberos controller gives me an AES key, I merely have to trust the controller. If we say that trusting him is the same as trusting the controller, then yeah, sure, it works. That's a suitable redefinition in which the KDC is isomorphic to a CA. But if we allow public key, then I could get Mr. Greenwald's public key from an intermediary who is not necessarily an authority, or even self-publish keys. It's done with PGP all the time.)

> We need to re-think everything about how we do cryptography.  Many decisions were made based on hardware limitations of 20 and more years ago.  "More efficient" claims from the 1980's often mean nothing today.  Many decisions assumed trust models (like CA's) that we know are completely unrealistic.  Mobile is very different from the server-to-server and dumb-client-to-server models that were all anyone thought about the time.  (Just look at SSL:  It has the inherent assumption that the server *must* be authenticated, but the client ... well, that's optional and rarely done.)  None of the work then anticipated the kinds of attacks that are practical today.

I concur that the way that browsers and web servers us SSL is suboptimal. This doesn't mean that a solution is impossible, it only means we have a widely-distributed suboptimal system.

> I pointed out in another message that today, mobile endpoints potentially have access to excellent sources of randomness, while servers have great difficulty getting good random numbers.  This is the kind of fundamental change that needs to inform new designs.

I have to disagree on that one, too. The servers that have problems indeed have problems. Servers do not implicitly have problems. The solutions are not evenly distributed, but they're not architectural. Heck, a Raspberry Pi has a hardware RNG.


Version: PGP Universal 3.2.0 (Build 1672)
Charset: us-ascii


More information about the cryptography mailing list