What's really in PGP 5.5?

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

At 02:46 PM 10/8/97 +0200, Mike wrote:
   
>What happens when the non corporate versions of PGP encrypts a message to
>Alice? Will they disregard the recovery key and encrypt to Bob, or simply
>fail?
   
Here is what happens if you are using freeware/personal privacy:

It brings up a dialog box and gives you the option of encrypting to Alice
alone or Alice plus her corporate recovery key. If the "strict" flag is set
on Alice's CMRK and you remove it, we display a dialog box that wags a
finger at you and tells you you're being naughty, but that's it. If you
remove Alice's CMRK from your key ring, it just sends to Alice alone and
doesn't bother you at all.

If this isn't what happens, it's a bug. Tell us, we'll fix it.

	Jon



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

At 6:06 PM +0100 10/8/97, Adam Back wrote:
>
>Email itself is pretty fragile, and email is not commonly used for
>long term storage.

Now this is a pretty bold assertion.  One with which I completely disagree.
As I peruse my Eudora folder this evening, I can easily pick out messages
that date back nearly 6 years.  Looking thru IETF working group archives
(which are *all* email) it is possible to find messages dating back 10
years and more.

Moreover, it is not unheard of during legal discovery for email to be made
subject to search (Our lawyers are constantly tut-tuting about all the
email that is saved).  So to say it is not used for long-term storage is
simply incorrect.

Since your argument pretty much is based on this claim, Adam, I have a hard
time accepting any of it.

john  w noerenberg, ii
jwn2@qualcomm.com
pager: jwn2@pager.qualcomm.com
 --------------------------------------------------------------------
  "A beautiful idea has a much greater chance of being a correct idea
   than an ugly one."
 -- Roger Penrose, "The Emperor's New Mind", 1989
 --------------------------------------------------------------------

John Noerenberg <jwn2@qualcomm.com> writes:
> 
> At 6:06 PM +0100 10/8/97, Adam Back wrote:
> >
> >Email itself is pretty fragile, and email is not commonly used for
> >long term storage.
> 
> Now this is a pretty bold assertion.  One with which I completely disagree.
> As I peruse my Eudora folder this evening, I can easily pick out messages
> that date back nearly 6 years.  Looking thru IETF working group archives
> (which are *all* email) it is possible to find messages dating back 10
> years and more.

You're misunderstanding what I'm saying.  There was some other context
around the above quote.

What I'm saying is that you don't use the *email in transit* for
storage.  You receive the email, then you archive it (store it in your
eudora folder), then you consider it storage.  Perhaps with your
current software you archive the PGP encrypted email.  This is a bad
security practice.  You should have different, storage only keys for
encrypted archives.

Email in transit isn't that reliable.

About the only example of email in transit being considered storage
was a USENET article years ago by someone who considered it a kewl
hack that he had some games or something else which was in breach of
policy in his account and rumor went around that the admin was having
a purge.  He tarred, gzipped & uuencoded the lot and emailed it to
himself down a _long_ ! fowarding path.  It came back to him around 3
days later after the purge.  That's the kind of thing I mean when I
say you don't consider email storage.

I'm arguing that you should not backup, or escrow communications keys,
and that you should backup storage keys.

(Separately I have argued in the past that you should use forward
secrecy to ensure that you have no long term private keys which after
the fact allow you to decrypt traffic -- if a competitor, or the feds
get a copy of this key, your past traffic is vulnerable.  Encrypting
the session key to two long term keys, never mind one, makes this
situation even worse, and also results in a system useable for GAK.)

> Moreover, it is not unheard of during legal discovery for email to be made
> subject to search (Our lawyers are constantly tut-tuting about all the
> email that is saved).  So to say it is not used for long-term storage is
> simply incorrect.

Your lawyers have a good point.  I know a few examples where people
really wish that email hadn't been kept around, as an email sent with
1 minutes thought has been dug up and used somewhat out of context as
the basis of a court case.

A pgp signed email is even worse.  There you have transferable
undeniable signature proving that you wrote the contested email.


I'm sure I've said this all before, but hey, maybe PGP has it's ears
open this time:

You should have two types of email.  "Official statement" type email,
which you might want to back up, and which you might want proof read
and approved by your company legal team, depending on how important it
is.  Official email you want to sign with a transferable signature
(normal pgp signature).

Unofficial email, for example to and fro communications between
co-developers at different companies, etc. you probably don't want
transferable signatures on.  (This is the kind of thing lawyers go
tut-tut about.)  So you use non-transferable signatures.  You use
forward secrecy, and for the really paranoid deliver it via mixmaster
to avoid mail delivery logs.  Archive if you wish.  It'll then be
largely one persons word against the other, as there will be little in
the way of proof of authorship.

> Since your argument pretty much is based on this claim, Adam, I have
> a hard time accepting any of it.

It isn't based on the idea that you never want to store email.  That's
clearly bunk.  I've got 54Mb of old email on my disk.

What I'm arguing is that if you're going to encrypt your stored email
on your disk, that you should encrypt it with a storage key, and NOT a
communications key.  Communications keys should ideally be transient
(via forward secrecy), but failing that you should at least not have
multiple recipients to exarcerbate the problem.

Am I making sense?

I know I'm fighting against the tide .. but I'm confident that what
I'm saying is correct.

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

At 9:50 AM -0700 10/10/97, Tim May wrote:
>I don't think we've yet seen a good example of massive amounts of e-mail
>being examined in a "discovery" process, yet, but we saw the effects on IBM
>during its antitrust issues in the 70s. Basically, every scrap of paper,
>every desk calendar, every internal memo, everything, had to be turned over
>to opposing counsel.

A group from IBM who had developed a telephone based audio messaging system
many years ago described it at Share (the IBM large systems users' group)
many years ago.  They described their system as being used by the top level
IBM executives.  They also described the aggressive "no backups" policy and
mentioned the discovery process in the Justice Department vs. IBM suit.
Tim's point is very real.


-------------------------------------------------------------------------
Bill Frantz       | Internal surveillance      | Periwinkle -- Consulting
(408)356-8506     | helped make the USSR the   | 16345 Englewood Ave.
frantz@netcom.com | nation it is today.        | Los Gatos, CA 95032, USA

* Jon Callas wrote:
>It brings up a dialog box and gives you the option of encrypting to Alice
>alone or Alice plus her corporate recovery key. If the "strict" flag is set
>on Alice's CMRK and you remove it, we display a dialog box that wags a
>finger at you and tells you you're being naughty, but that's it. If you
>remove Alice's CMRK from your key ring, it just sends to Alice alone and
>doesn't bother you at all.

The CMRK must not be used in eMails. It may be used in storing folders.x

If it does work in that way, it's GAK to temprorary communication keys.

Jon Callas <jon@pgp.com> defends:
> 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 is true but mainly I think for _storage_ keys.  PGP is being
discussed as an email communications system.  It's probably just as
likely that your email will disappear down a black hole as that you
forget your keys.

Your analogy doesn't fit.

All you're encrypting is something sent over a fairly unreliable
communications link.  If you lose the key, well heck you just get the
sender to resend it.  Happens every day with or without crypto.

(So you generate a new key, and get it certified, and publish your
revocation cert., if you have one).

This is the same mistake that Freeh and company make in arguing for
GAK.  It's a flawed argument.

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

Email itself is pretty fragile, and email is not commonly used for
long term storage.  (What are PGP are thinking? "gee, how best can we
best archive our master source tree ... I know we'll email it to our
colleague over here and delete it before I get confirmation it
arrived"?).

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

Way I understand "data recovery" is that you have a recovery mechanism
for stored data.  Like you have backups of the keys for your hard disk
driver level encryption program, or encrypted back up program.

You either have misunderstood the data recovery argument, or are
attempting to rejig it to fit your argument.

> When I was at HIP97 this August, I was amused to hear cypherpunks
> chanting, "Data recovery good, key recovery bad." 

I'm pretty sure said cypherpunks were chanting about storage keys:
keys for data stored on your disk, as opposed to the GAKkers wanting
access to your communications keys.

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

Bingo.  And your data is where?  On your disk.  Not in limbo being
passed around the flaky sendmail/mailserver hodge-podge that is
Internet mail.

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

No, no!  The simple solution to fragile encryption on fragile
communications data is to keep a copy of the email you sent!  Encrypt
and backup the keys for that all you want, and you won't get any GAK
complaints.

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

No you didn't, you built a GAK system.

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

Yes, and your archives are going to be where?  On backup tapes, on an
encrypted partition on his hard disk... not in the email system.

> (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.) 

Sad story.  I venture to suggest, however, that the product source
code was not stored solely in your email box, nor I expect did the
last copy of your source tree happen to be en-route in encrypted
email which only he had the key for.

> Your spouse might need access to financial records.

She might.  In which case you might secret split the key to your
encrypted partition, your lawyer and her, or whatever.

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

Nope, that's not it.  Data recovery is being able to recover stored
data.  "Key escrow" and "key recovery" are newspeak terms defined by
the GAKkers which mean that they want access to your communications
keys.  Your response should be to widely field systems using forward
secrecy, not to go along and implement GAK for them. 

[description of PGP GAKware elided]

If any PGP employees want a job working for a company which doesn't do
GAK, contact me off list, encrypted mail preferred.

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

At 11:48 PM -0700 10/9/97, John W. Noerenberg wrote:

>Moreover, it is not unheard of during legal discovery for email to be made
>subject to search (Our lawyers are constantly tut-tuting about all the
>email that is saved).  So to say it is not used for long-term storage is
>simply incorrect.

Not surprising that your lawyers are worried about extensive mail archives.
Imagine the juicy things that must lie in gigabytes of archived e-mail
messages! (Or the messages which can be twisted by skilled lawyers into
seeming to be anticompetitive, price-fixing, conspiratorial, etc.)

I don't think we've yet seen a good example of massive amounts of e-mail
being examined in a "discovery" process, yet, but we saw the effects on IBM
during its antitrust issues in the 70s. Basically, every scrap of paper,
every desk calendar, every internal memo, everything, had to be turned over
to opposing counsel.

We will almost certainly see some examples of where lawyers demand access
to all company e-mail.

(When I was at Intel there were periodic purges of old memos, old reports,
old scraps of paper. Ostensibly this was to cut clutter, but the real
reason was, probably, that Intel feared old memos and reports would be
demanded by AMD or whichever competitors were suing Intel, or by a
government bent on breaking up the world's most powerful chip monopoly (as
the Feds saw it). As a sidenote, I kept nearly all of my old reports and
papers, and this came in handy several times...others had purged their
corporate memories, but I had the needed information to solve a problem.)

I can imagine that companies are getting very worried about the possibly
"discovery" of their increasingly computerized communications systems, with
lawyers pawing through gigabytes with keyword searches for anything to help
their case.

(And there are similar examples in the political sphere. E-mail in the
President's "PROFS" system during the Iran-Contra controversy was acquired;
the Ollie North crowd thought they had deleted the messages implicating
them, but the PROFS backups revealed all.)

Is there a solution? Well, "key recovery" is probably one of the _worst_
solutions! (This is in my opinion. If I had a company I'd fear a CAK system
would be used against my company. Expect CAK keys to be the first things
demanded in the discovery process.)

Certainly lawyers can subpoena the holders of various keys, and I'm
certainly not saying that having X hundred separate, non-CAKked keys means
the discovery process hits an insurmountable obstacle. But it is certainly
true that having a large repository of all e-mail, conveniently accessible
with a small number of easily subpoenaed CAK keys, is an overwhelmingly
tempting target.

If CAK is implemented, and these corporate discovery trends continue,
expect to see less communication through the official corporate channels,
and more through personal accounts. (E.g. people will use the Net to access
other accounts, even Web mail throwaway accounts, to communicate even with
persons in their own company!)

It may be that PGP, Inc. and the other companies claiming "communications
plaintext recovery" is so important are talking to the wrong groups of
lawyers at various companies.

--Tim May



The Feds have shown their hand: they want a ban on domestic cryptography
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
ComSec 3DES:   408-728-0152 | anonymous networks, digital pseudonyms, zero
W.A.S.T.E.: Corralitos, CA  | knowledge, reputations, information markets,
Higher Power: 2^2,976,221   | black markets, collapse of governments.
"National borders aren't even speed bumps on the information superhighway."

At 9:50 PDT on Friday, October 10, 1997, Tim May wrote:

|I don't think we've yet seen a good example of massive amounts of e-mail
|being examined in a "discovery" process, yet, but we saw the effects on IBM
|during its antitrust issues in the 70s. Basically, every scrap of paper,
|every desk calendar, every internal memo, everything, had to be turned over
|to opposing counsel.
|
|We will almost certainly see some examples of where lawyers demand access
|to all company e-mail.

Several lawsuits about discriminatory denial of tenure have been won partly
based on the contents of email.  The University of Illinois periodically
reminds all staff that email is considered a public record and that they
should conduct their business with that in mind.

/pbp

Tim May wrote:
> At 11:48 PM -0700 10/9/97, John W. Noerenberg wrote:
> >Moreover, it is not unheard of during legal discovery for email to be made
> >subject to search (Our lawyers are constantly tut-tuting about all the
> >email that is saved).  So to say it is not used for long-term storage is
> >simply incorrect.
> 
> Not surprising that your lawyers are worried about extensive mail archives.
> Imagine the juicy things that must lie in gigabytes of archived e-mail
> messages! (Or the messages which can be twisted by skilled lawyers into
> seeming to be anticompetitive, price-fixing, conspiratorial, etc.)

So, Mr. May...I see that you have instructed your "skilled lawyer" to
make certain my client's email messages are "twisted" to seem
anticompetitive, price-fixing and conspiratorial.
Now all I have to do is find a client to sue you...

The Prosecutor
"Hold that ambulance!"

At 11:35 PM 10/7/97 -0400, Charles Platt wrote:
   On Tue, 7 Oct 1997, Jon Callas wrote:
   
   > Like it or not, government has a mandate to protect the people from
   > dangerous technologies, be they in foods, drugs, autos, or information
   > technologies.
   
   Please tell me where it says this in the U.S. Constitution.
   
   In particular, please tell me where the FEDERAL government is assigned 
   this power.
   
   Thank you.
   
There are a number of places. The usual one they abuse is what's called the
"commerce clause" which lets them regulate interstate commerce. They also
drag in "providing for domestic tranquility" or anything else that looks good.

If you'll look again at my next sentence, I said, "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...." I'm one of those
many people.

One of the very sad things in our history is that limitations on Federal
power became hostage of the race issue a century ago. "States Rights" is a
real issue because the Constitution places severe limits on what the
federal government is supposed to do. Unfortunately, that term is nigh a
synonym for justification of slavery, racial segregation, and other odious
things. Limits on the federal government are a casualty of the War Between
the States.

Recently, the courts have been reversing this trend, tossing out some laws
that are justified by the commerce clause. A number of scholars predict
this will increase. We can only hope.

	Jon



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

At 02:27 PM 10/07/1997 -0700, Jon Callas wrote:
>When I was at HIP97 this August, I was amused to hear cypherpunks
>chanting, "Data recovery good, key recovery bad." 
...
>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. 

Eric Hughes brought up this at a cypherpunks meeting earlier this year.
It doesn't mean that businesses often _need_ data recovery, 
and there are serious and complex concerns about 
	"what data do we keep?  what data do we discard?"
that companies, their legal staffs often deal with.
In particular, the Intellectual Property Bureaucrats tend to get
very concerned if you either do or don't have a large collection of data
in one place, as lawsuit targets, conflict of interest between departments,
and "simultaneous employment" opportunities for clerks and computer-janitors.
But it's clearly the case that they don't need keys, only maybe data.
I haven't yet seen a technical description of PGP5.5, but it sounds like
it's implementing copying data to some corporate data-escrow key.
Note that, while it is a lawsuit/subpoena/warrant target,
that's typically not something that happens without company knowledge,
unlike Louis Freeh's dream of no-knock backdoors for your data.

So who gets the data?  How do you tell what kinds go to whom?
Any corporate feature for implementing this needs to provide some
mechanism and interface for supporting multiple alternative recipients -
if you need message escrow, you may need the 90-day-Work-In-Progress escrow,
or the Long-Term-Projects escrow, or the Company-X-Relationship escrow, 
or the Accounting-Department Escrow, or the Retain-for-Legal-Department escrow 
- note that these are different functions from just copying those recipients,
because an escrow feature is supposed to be semi-automatic and not for
automatic and convenient access.  

Doing the job right really means you need to be able to send mail to 
recipients who get only a secret-shared slice of the session key, 
not the whole thing - not only for corporate data escrow, but also for
mail you've addressed yourself that goes to your lawyers, or the
managers of your trust, or the three trustees of your corporation.

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

One way to help this problem is to support secret-sharing for user key backup,
as well as the ability to make copies of keys with different passphrases
(e.g. the floppy in the offsite-storage with the passphrase on the yellow-sticky
doesn't use the same passphrase as the same key on your desk machine.)

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

This is an important point - if you've got [data  + session key] escrow,
you've got a reasonable court case that says the court doesn't need your 
master keys, just the keys for the specific messages.  Of course,
they _can_ ask to see _all_ the messages by the targeted senders,
just as they can ask to see all the paper in your file cabinets,
but you at least have some ability to fight it.

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

The issue of whether this is in fact needed or if it's giving in to
the Great Satan is of course the critical one....

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

No, No, Br'er Zimmermann, Don't throw me in that there briar patch!


				Thanks!
					Bill
Bill Stewart, stewarts@ix.netcom.com
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

On Tue, 7 Oct 1997, Jon Callas wrote:

> Like it or not, government has a mandate to protect the people from
> dangerous technologies, be they in foods, drugs, autos, or information
> technologies.

Please tell me where it says this in the U.S. Constitution.

In particular, please tell me where the FEDERAL government is assigned 
this power.

Thank you.

--Charles Platt

At 2:27 PM -0700 10/7/97, Jon Callas wrote:
>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."

Jon clearly states one half of the problem here.  The other half is what
seems to be below the surface in many of the responses to PGP 5.5.  That
is, how do I achieve the secure deletion of data?

When I make a telephone call, I have an expectation that the only record of
the call will be in my memory and the memory of the person at the other
end.  At one time, people recording telephone conversations were required
to include a beep every 15 seconds to notify the participants that this
expectation was being violated.  (It seems this expectation has always been
violated by law enforcement.)

Now email is a confounding medium because it is both a transient
communication medium and a storage medium.  We would like to be able to
have protection against losing access to our stored data, at the same time
we are sure that those who violate our trust and intercept our
communications can not read the data, when it is sent or at any time in the
future.

PGP 5.5 seems to have a solution to the "lose your data" problem.  It does
not seem to address the secure deletion problem.

In the context of computer system backup, one paper at the last Usenix
Security Conference suggested implementing secure deletion by encrypting
the data on the backup tape and then destroying the key when you wanted to
delete the data.


-------------------------------------------------------------------------
Bill Frantz       | Internal surveillance      | Periwinkle -- Consulting
(408)356-8506     | helped make the USSR the   | 16345 Englewood Ave.
frantz@netcom.com | nation it is today.        | Los Gatos, CA 95032, USA

Bill Frantz <frantz@netcom.com> writes:
> At 2:27 PM -0700 10/7/97, Jon Callas wrote:
> >favorite way of expressing this problem is, "if you lose the keys to your
> >car, then you have to get a new car."
> 
> Now email is a confounding medium because it is both a transient
> communication medium and a storage medium.  We would like to be able to
> have protection against losing access to our stored data, at the same time
> we are sure that those who violate our trust and intercept our
> communications can not read the data, when it is sent or at any time in the
> future.
> 
> PGP 5.5 seems to have a solution to the "lose your data" problem.  It does
> not seem to address the secure deletion problem.

If PGP wants to archive data sent or received, well they can do so, but
sending encrypted communications over open networks encrypted to _two_ long
term public keys is bad security practice.


There are two reasons which are given as to why someone might want to
have GAK installed for company use.

1. to allow access to important material lost in the mail system in the
event that an employee is hit by a bus

2. to allow management to spot check the emails being sent and received


Argument 1 seems pretty flimsy to me.  I reiterate my comment in an earlier
post: who in their right mind keeps their _only_ copy of ultra valuable
company information bouncing around in the email system?  Did those arguing
for this position not notice that sometimes email gets lost in transit?

Regardless, if PGP claims to be catering to those who use this argument, and
to not want to try that hard to make it impossible to by-pass, the more
secure, and less GAK friendly way to do it is to have the mail client
software archive the email sent and received.


Argument 2 I find somewhat distasteful, but seems to me to be logically what
PGP's implementation is catering for.  A less GAK friendly way to implement
it, and a more secure (communications secure, not saying anything about GAK
being easier or harder to by-pass) way would be to archive for a while the
session keys. The security advantage being that the email doesn't go out
with the session key encrypted to 2 long term public key encryption keys.

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

-----BEGIN PGP SIGNED MESSAGE-----

In <199710081011.LAA00865@server.test.net>, on 10/08/97 
   at 11, Adam Back <aba@dcs.ex.ac.uk> said:

>Bill Frantz <frantz@netcom.com> writes:
>> At 2:27 PM -0700 10/7/97, Jon Callas wrote:
>> >favorite way of expressing this problem is, "if you lose the keys to your
>> >car, then you have to get a new car."
>> 
>> Now email is a confounding medium because it is both a transient
>> communication medium and a storage medium.  We would like to be able to
>> have protection against losing access to our stored data, at the same time
>> we are sure that those who violate our trust and intercept our
>> communications can not read the data, when it is sent or at any time in the
>> future.
>> 
>> PGP 5.5 seems to have a solution to the "lose your data" problem.  It does
>> not seem to address the secure deletion problem.

>If PGP wants to archive data sent or received, well they can do so, but
>sending encrypted communications over open networks encrypted to _two_
>long term public keys is bad security practice.


>There are two reasons which are given as to why someone might want to
>have GAK installed for company use.

>1. to allow access to important material lost in the mail system in the
>event that an employee is hit by a bus

>2. to allow management to spot check the emails being sent and received


>Argument 1 seems pretty flimsy to me.  I reiterate my comment in an
>earlier post: who in their right mind keeps their _only_ copy of ultra
>valuable company information bouncing around in the email system?  Did
>those arguing for this position not notice that sometimes email gets lost
>in transit?

Well lets take the flip side of this: Who in their right mind encrypts
ultra valuable company information and then leaves the plain text on their
computer?? I have an outbox full of encrypted messages that are encrypted
to both the recipient and to my key (Encrypt-To-Self Option). If you are
going through the trouble of encryption why would you want to leave plain
text lying around??? One needs to remember that e-mail is not just
communication but communication *and* storage.

>Regardless, if PGP claims to be catering to those who use this argument,
>and to not want to try that hard to make it impossible to by-pass, the
>more secure, and less GAK friendly way to do it is to have the mail
>client software archive the email sent and received.

I have to disagree, see above.

>Argument 2 I find somewhat distasteful, but seems to me to be logically
>what PGP's implementation is catering for.  A less GAK friendly way to
>implement it, and a more secure (communications secure, not saying
>anything about GAK being easier or harder to by-pass) way would be to
>archive for a while the session keys. The security advantage being that
>the email doesn't go out with the session key encrypted to 2 long term
>public key encryption keys.

I have seen no evidence that encrypting to multiple recipients is any less
secure than encrypting to one. If there are serious security implications
in doing so then it affects *all* versions of PGP and not just 5.5. I find
it odd that this issue is only now being brought up with 5.5 and never
mentioned with previous versions.

One thing I would like to see added to this set-up is secret sharing of
the corporate private key. That way one person could not unilaterally
access the data but would require the agreement of several people (say 3
of 5 department heads). I think this would provide enhanced physical
security of the key and personal privacy (Joe in IMS can't snoop the mail
just because he is board). I have made some mention of this in the past to
PGP but don't know what if any work has been done in this area. I have
been working on a small utility that would let a user do this with his own
private key. Perhaps if I ever get some free time I can finish it up.


- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.amaranth.com/~whgiii
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000

iQCVAwUBNDvPdY9Co1n+aLhhAQHjQgP/UK4Ep2TsA9c5kSdvjS0iy2iaSvFVbML6
w4SIiQtTRgrSX5gQuPN5Xny1KZNH9xgwbSrQUFYOpS4l63eanvTMYdTFDAEt4IyA
AzdtZzJjgUqUzy0a8W6nljgQ8AVekJMjBX0N4ew1kVw1ZtWsAMBTxlXCchbzS+zH
9RL4/dHenG4=
=iWRY
-----END PGP SIGNATURE-----

[made a few snips to the CC line, still Cc of cypherpunks]

William Geiger <whgiii@invweb.net> writes:
>    at 11, Adam Back <aba@dcs.ex.ac.uk> said:
> >1. to allow access to important material lost in the mail system in the
> >event that an employee is hit by a bus
> 
> >Argument 1 seems pretty flimsy to me.  I reiterate my comment in an
> >earlier post: who in their right mind keeps their _only_ copy of ultra
> >valuable company information bouncing around in the email system?  Did
> >those arguing for this position not notice that sometimes email gets lost
> >in transit?
> 
> Well lets take the flip side of this: Who in their right mind encrypts
> ultra valuable company information and then leaves the plain text on their
> computer?? 

Lots of people.  See, what goes over a public network in the clear is
much more vulnerable than what sits on your disk.  I encrypt
communicated copies of things which aren't encrypted on the disk
myself.  I suspect you do too.

But, more to the point, my argument was that keys should have
segregated uses.  One key for storage, another for receiving encrypted
emails.  I wasn't saying that you wouldn't encrypt your archived sent
& received email.  I _was_ arguing that a better way to archive email
securely is to encrypt it with a separate storage key.

> I have an outbox full of encrypted messages that are encrypted
> to both the recipient and to my key (Encrypt-To-Self Option). 

Bad move dude.

See you might have a 100 bit entropy passphrase, but the recipient
might have a password of "fred".  You've conveniently archived all
your email, and you've left it decryptable by a hodge podge of other
people with unknown level of care about your level security.

Say perhaps fred deleted the email after reading, even though he has a
poor passphrase.  You have just screwed your own security.

Similar problem if it is you that has a passphrase of "william".  I
won't thank you when the feds decrypt your email to me, thanks to a
you having a poor passphrase.  (Not that I'm suggesting you do).

If your email archives are encrypted with storage keys, you avoid all
these problems, and avoid GAK arguments at the same time.

> If you are going through the trouble of encryption why would you
> want to leave plain text lying around??? One needs to remember that
> e-mail is not just communication but communication *and* storage.

Nope.  Email is communication.  Archived email is storage.  Use
communication keys for communicated email, and storage keys for
encrypting archived email.

This is a very important point, and I can't fathom why so many people
who are otherwise on the ball are not getting it.  If you don't escrow
any communication keys, but do escrow storage keys, the GAKkers don't
get what they want, and you get all the functionality you need.  They
actually have to break into premises, and take disks, and supoena
keys.

Right?  Simple enough isn't it?

> >2. to allow management to spot check the emails being sent and received
> >
> >A less GAK friendly way to implement it, and a more secure way would
> >be to archive for a while the session keys. The security advantage
> >being that the email doesn't go out with the session key encrypted
> >to 2 long term public key encryption keys.
>
> I have seen no evidence that encrypting to multiple recipients is any less
> secure than encrypting to one. 

Of course it's less secure.  It's less secure almost by definition.

Lets say you have your communications encrypted with only your key,
and there is a small probability call it p1 that your key is
compromised (key board sniffer virus, hidden video cam, typing
passphrase whilst on phone (yes?), whatever). 

Well if you encrypt to another key, say a corporate escrow key, there
is an additional chance, call it probability p2, that your security
can be blown by the corporate key being compromised.  So long as the
p2 is greater than 0, which I'm sure you'll agree it is, however
small, then you have less security by using multiple encryption.

> If there are serious security implications in doing so then it
> affects *all* versions of PGP and not just 5.5.  I find it odd that
> this issue is only now being brought up with 5.5 and never mentioned
> with previous versions.

I've been arguing against using encrypt-to-self for ages.  It simply
makes me cringe when people send me email which is encrypt to self.

> One thing I would like to see added to this set-up is secret sharing of
> the corporate private key. [details elided]

Sounds like a good idea.

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

Jon Callas wrote:
>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.

What happens when the non corporate versions of PGP encrypts a message to
Alice? Will they disregard the recovery key and encrypt to Bob, or simply
fail?


Mike.