7 October 1997
Source: Mail list cypherpunks@cyberpass.net
For background on this issue:
http://jya.com/pgp-fbi.htm
And another response by PGP:
http://jya.com/pgp-gak.htm
Date: Tue, 07 Oct 1997 14:27:10 -0700
To: minow@apple.com
From: Jon Callas <jon@pgp.com>
Subject: What's really in PGP 5.5?
Cc: cypherpunks@cyberpass.net, cryptography@c2.net, risks@csl.sri.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I have a number of comments about the New York Times article on PGP 5.5 for
Business of which Martin Minow sent a synopsis.
If we had built what they said we had, then we'd deserve of all the
derision people have directed at us. But we didn't. The New York Times got
it flat wrong.
I'll describe what we built, how it works, and its limitations. But first,
some background on the problem we're trying to solve in PGP 5.5.
A couple of years ago, the government sugarcoated their surveillance plans
by switching from "key escrow" to "key recovery," and trying to sell
surveillance to people by pointing out some of the downsides of strong
cryptography, and selling key recovery as the way around them.
One of the downsides of cryptography is that if you lose your passphrase
(or token, PIN, smart card, or whatever), you've lost your data. My
favorite way of expressing this problem is, "if you lose the keys to your
car, then you have to get a new car."
This downside is particularly insidious for a number of reasons. First,
without fixing that problem, strong cryptography will be in some sort of
limbo. You want to use it to protect your valuable information, but you
won't want to use it for any information that's *too* valuable, because
it's easily lost. Crypto-protected information is fragile, and this
fragility could hurt its widespread deployment.
Worse, this gives the government a rationale for regulating cryptography.
Like it or not, government has a mandate to protect the people from
dangerous technologies, be they in foods, drugs, autos, or information
technologies. Many people believe that the government uses this mandate as
a rationale for acquiring power, many people would prefer that they let us
take our chances, but that's not germane to this discussion.
It *is* germane to note that when you hear some ham-fisted remark about how
surveillance is like air bags, they are saying: they have to protect people
from dangerous things, crypto is dangerous, therefore they have to protect
people from crypto.
When they started mumbling along these lines, the privacy community got
their own act together and started describing what we believe to be the
real solution. This is called "data recovery." The first time I heard the
term, I hated it. I still hate it. The reason I hate it is that it's got
the word "recovery" in it, which makes it sound to someone who isn't paying
a lot of attention that all recovery systems are basically the same thing.
Most of the people in the world don't pay a lot of attention most of the
time. When I was at HIP97 this August, I was amused to hear cypherpunks
chanting, "Data recovery good, key recovery bad." The sublimely Orwellian
tone of this mantra makes me laugh and cringe at the same time. (To explain
the reference, in Orwell's "Animal Farm," there's a revolution in the farm
and the animals take over, run by the pigs. One of the slogans they have is
"four legs good, two legs bad." By the end of the book, the pigs are nigh
indistinguishable from the people. But I digress.)
The essence of data recovery is that focusing on the keys is a canard. If
you've misplaced your data, you want the data back, not the keys. The only
people who want your keys are people who want to spy on you. If you've
locked yourself out of your car, you want the use of your car, not the just
the key. Thus, the solution to encrypted data being fragile is to let
people get to the data. Simple, obvious, but subtle, because the key to
getting the data is the key.
If you don't like data recovery, you aren't going to like what we did in
PGP 5.5 -- we built a data recovery system. Some people aren't going to
like it, and some of those will think this missive is a load of
self-serving twaddle. Myself, it gives me the same mildly uncomfortable
feeling that fake rocks for spare keys do, or skeleton keys do, financial
audits, or any other similar technology. Uncomfortable feelings aside, if
the fragility problem is not solved, then many people who should be using
crypto won't, and government will continue to view this problem as a
question of public safety, and thus in their mandate to regulate.
Data recovery is useful for a number of things. Perhaps you lost your
passphrase. Or data might have been encrypted by an employee or co worker
who was in an accident. (As an aside, fifteen years ago, the architect of a
product I worked on was in a severe car wreck. He was not killed, but
suffered brain damage and has never returned to work.) Your spouse might
need access to financial records. Everyone, be they an individual,
business, or coporation has a right to having their data protected, and
protection not only means being able to put it into a safe, but getting it
out of that safe later.
What makes data recovery different from key recovery? In my opinion, data
recovery allows you to get encrypted data without compromising the key of
the person who encrypted it. Data is property, and keys are property. An
ethically built system allows emergency access to data without destroying
the property of the key owner.
Ethically built data recovery software has a number of properties:
(1) It is surveillance-surly. It should be impossible or unwieldy for an
adversary, be they government (yours or foreign), dirtballs (such as
crackers), business competitors (who sometimes count as dirtballs), or
others to use this against you. The system should also be aware of how
passive surveillance (like traffic analysis) interacts with it.
(2) It is an "opt-in" system. Users must consent to it, and must take some
action to start using it. It should be as easy as possible to stop using
the system. The system must also allow someone who does not opt in to use
all the system's features. Please note that abuses of consent (for example,
an employer who says, "consent or we fire you") are something we can't
prevent in any system.
(3) It must obey the principle of fair warning. If you send me a message
that is subject to data recovery, you should know that before sending the
message. This way, if you don't agree with my policy, you can decide not to
send me that message. This interacts closely with the opt-in principle above.
(4) The data recovery system should be preferable to an escrow system. A
number of corporations who use PGP keep copies of their employees' secret
keys. This is both odious and dangerous. Escrowed keys are a target for
attackers, subpoena-bait, and potentially ruin the value of digital
signatures. It's just bad policy.
(5) The system has to allow someone under a legal threat to respond
effectively to that threat. Legal threats include warrants, subpoenas, and
discovery processes. You have to be able to respond to the request for
information without losing your keys and thus all of your data.
(6) It must also provide a response to those who would regulate crypto in
the name of public safety. Fortunately for us, potential regulators have
focused on the horsemen of the infocalyse. There are other
pseudo-public-welfare threats including the rights of a person to their
spouse's records, or the rights of heirs to information property. We, the
people who design privacy systems, have to think about what happens when
the regulators stop dragging out the pornographers and start dragging out
the poor widows and orphans.
Note that these requirements are not completely consistent with each other.
For example, an opt-in system is riskier than an opt-out system, yet
friendlier to one's own privacy. Balancing these requirements is part of
the difficulty of good software design.
If you have been skimming the above, wondering when I'm going to get around
to actually telling you what we did in PGP 5.5, this is it.
With PGP 5, there are a number of attributes of your key that are stored in
a self-signature. For example, your preferred symmetric algorithms are
stored in your self-signature. The data recovery feature -- which we call
"Corporate Message Recovery" -- is an attribute in your self-signature that
tells anyone who receives your key that you want messages encrypted to you
to also be encrypted to that other key. There is also a flag that tells the
encryptor, "please" or "I insist." Architecturally, there can even be more
than one recovery key. That's it. That's all it is.
Well, that's mostly all it is. There are other bits of the system. For
example, if I look up Alice's key on a key server and Alice has a recovery
key, I get Alice's recovery key, too. If Alice's recovery key is a "please
use" key, then I can encrypt to Alice alone. In any case, the PGP software
tells me that Alice has a recovery key, so I can decide to use some other
mechanism to talk to her.
Note that design satisfies the opt-in and fair-warning requirements. Also,
since Alice's recovery key is an attribute of her self-signature, she can
change it. She can even have a second user name (let's call it Bob), that
has no recovery key.
Also, we have three encryption products: PGP freeware, PGP for Personal
Privacy, and PGP for Business Security. Corporate Message Recovery is
included *only* in PGP for Business Security. It is not, and never will be,
in either the freeware or the Personal Privacy product. It is an extra cost
item that we created for businesses as per their requirements. As I stated
above, a number of these businesses keep copies of their employees' secret
keys. One of the reasons we created this feature is to satisfy their
requirements with some mechanism that is less blunt than key escrow.
When a PGP message is formed, there are a number of "packets" that make up
the message. The usual construction is that there is a "session key" packet
for each public key that the message is to be read by. Following that is
the actual message packet, that is encrypted with a symmetric cypher to
session key. The session key packets specify the *key*, by its 64-bit key ID.
This is an important and subtle point. Let's go back to Alice, a.k.a. Bob.
The information that specifies a recovery key is in a self-signature of a
user name, but the session key specifies a public key by keyID. It is
impossible, solely from looking at a message, to know if it is addressed to
Alice or Bob because that information is not stored in the message. A
message that does not honor recovery is syntactically correct.
I don't know why Bruce Schneier said that this is everything the FBI wants.
If it is, then they have changed spots! One of the major ways PGP's system
differs from anything else I've seen is that it has no enforcement built
into the protocol. This helps make PGP surveillance-surly, with or without
Corporate Message Recovery. If this is all the FBI needs, then they've
decided the way to get your files is to knock on your door with a warrant,
and that's a big, big, big step forward.
Getting back to the system, I'm sure you've noticed a gotcha there. If I
mail Alice a message that I encrypted to Bob, she can decrypt it, but the
recovery key can't. If you've been paying very close attention, you have
wondered something akin to, "hmm, if Alice's key accidentally lost its
self-signature, there would be no way to encrypt to her recovery key."
You're right. If Alice really wants recovery on messages sent to her, then
she has to use our SMTP Policy Management Agent.
The policy management agent is an SMTP proxy. You can configure it to do a
number of things. Most relevant to this discussion is that Alice can use
the policy agent to require that her recovery key gets used. However, the
policy agent does *not* decrypt the message. One of the very good features
of Business PGP is that it does not decrypt the message. It does not
prevent or even try to prevent multiple-encryption. It's really, really
easy to encrypt a message to Alice alone, and then encrypt that message to
both Alice and her recovery key. We're not going to change that. Nor does
the policy management agent archive messages, make copies, notify your
mother, or any of the other things we've been accused of doing with it.
It's simply the gatekeeper that enforces Alice's corporate policy.
To sum up, we created the Corporate Mesage Recovery feature to satisfy the
requirements of our customers who need emergency access to data. We made
careful decisions to make it useful and effective for honest people, while
minimizing its potential for abuse. No one has to use it; we do not include
it with PGP freeware, nor with PGP for Personal Privacy. We alert all users
of all products when they encrypt to someone who has a message recovery
key. It is an opt-in system that you can opt out of. It is not a
surveillance system. A few weeks ago, we showed it to the FBI and asked
their opinion. They told us it doesn't meet any of their needs.
- - ------
Jon Callas jon@pgp.com
Chief Scientist 555 Twin Dolphin Drive
Pretty Good Privacy, Inc. Suite 570
(415) 596-1960 Redwood Shores, CA 94065
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA)
-----BEGIN PGP SIGNATURE-----
Version: PGP for Business Security 5.5
iQA/AwUBNDqoyn35wubxKSepEQJ9FQCfQcaS8aWdXcTZild0nKe5+LatDRsAnA5n
GTIb2dYUx4+Uh/Frim2hKFuF
=4u2g
-----END PGP SIGNATURE-----
-----
Jon Callas jon@pgp.com
Chief Scientist 555 Twin Dolphin Drive
Pretty Good Privacy, Inc. Suite 570
(415) 596-1960 Redwood Shores, CA 94065
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA)