From: Tim May <tcmay@got.net>
Date: Sun, 26 Oct 1997 04:52:33 +0800
To: cypherpunks@Algebra.COM
Subject: Orthogonality and Disaster Recovery
Message-ID: <v03102802b078027ffb91@[207.167.93.63]>
MIME-Version: 1.0
Content-Type: text/plain




One of the themes of modern computing I strongly support is that of
"orthogonality," or clean functionality. A browser should not also try to
be a money management program. A word processor should not also try to be
an accounting program.

Failure to observe this rule of thumb has led to spreadsheets which can run
MPEG movies in spreadsheet cells (I'm not kidding), and to Web browsers
which take 20 MB of free memory to run reliably because they also contain
mediocre news readers, mediocre mailers, and lots of bloatware cruft.

The move toward modular decomposition is supported in functional and
object-oriented languages (like Java and C++) and in modern operating
systems. Much of the strenght of Unix has obviously come from the
philosophy that a function or utility should do some small set of things
well and cleanly, with chaining of these clean tools to accomplish more
complicated tasks.

A crypto program like PGP is intended to encrypt messages between a sender
and a recipient, or to provide authentication through signatures, or to
encrypt files on a storage medium. These are the classic, well-documented,
oft-discussed functions of crypto. Look in textbooks under "crypto" and
there won't be much talk of how to supply MIS with emergency backdoors, or
ways to monitor employees.

If properly modularized and orthogonalized (so to speak), such crypto
programs can then be used as building blocks for other tasks, like
remailers, data havens, and so on.

But there is a growing tendency, as seen in the bloatware examples of
browsers and spreadsheets mentioned above, to throw in all kinds of "wish
list" and "wouldn't it be nice" stuff. PGP is headed for bloatware. ("It's
not just a crypto program, it's also a tax preparation  and disaster
planning program!")

I'm quite certain that the Security and MIS directors at various companies
asked PGP, Inc. to include message recovery features. Not so much to handle
the very rare (almost nonexistent) cases where a piece of mail sent at some
time in the past has to be recovered because Alice was hit by a truck, or
similiar unlikely events (*), but because Security and MIS folks would like
the option of "monitoring" e-mail traffic.

(* I have heard no plausible scenarios under which transient
communications, which are presumably stored in the form composed
(plaintext) on the sender's machine or in the for received and read (also
in plaintext) on the receiver's machine, need to be recovered from the
*transit* state. We know why the FBI wants access to communications
keys--because access to the transit state is what they get when they
wiretap or sniff a communications line--but there is no plausbile
explanation of why a company would not simply ask Alice for the plaintext,
or ask Bob if for some reason Alice is unavailable. The idea someone
floated, that he needs to go in and decrypt his employee's mail in
emergencies is far-fetched.)

But are such bloatware crypto programs even good for disaster recovery? I
say they are not. I say e-mail will be a tiny, tiny portion of the recovery
strategy if Alice gets hit by a truck, for example. Far more important will
be recovery of her hard disk and related files.

(No, I am _not_ proposing anything be added to PGP to deal with this
disaster planning. Nor am I proposing that PGP enforce plaintext storage,
or anything else for that matter. These are all matters _orthogonal_ to the
basic function of a crypto program, and a crypto program cannot enforce
crypto hygiene any more than a spreadsheet can enforce good tax planning
hygiene.)

I am also not terribly interested in convoluted, byzantine schemes for
building "CDR" and such into crypto programs, as some are proposing. Again,
this is trying to make a crypto program into a disaster preparation
product, and trying to (partly) solve backup and disaster problems best
solved in other ways. Not something PGP should worry about (either the
program or the company).

"What if Alice forgets her key?" (Loses her private key, forgets her
passphrase, whatever.)  A very real concern. A concern I have myself. I
won't say how I deal with it, for security reasons, but it ain't something
I expect PGP, Inc. to solve _for_ me. Nor is my solution, whatever it is, a
step toward GAKking of keys, or any kind of building of an infrastructure
for surveillance.

In fact, this was my point a while back about how a diversity of approaches
to disaster planning, to key insurance measures, makes the imposition of
mandatory key escrow or Government Message Recovery (GMR) very difficult.
The very chaos helps. "Let a thousand flowers bloom."

And it turns out that the "what if Alice forgets her key?" scenario is very
poorly dealt with by PGP 5.5 (unless the corporation actually _does_  keeps
a copy of the private key generated for or by Alice...something supporters
of CMR says is not the case. Whether it _can_ or _will_ be the case is
another issue.)

So, disaster planning, for dealing with crashed disks, dead employees,
malicious employees (who, for example, encrypt their disks and then leave
the company), and general failures to backup work product, etc., these
examples of disaster planning issues are NOT dealt with in any important
way by PGP 5.5. Nor should any communications security program try to be
this kind program.

Keep it simple, stupid. This kind of bloatware is a fig leaf for security,
and very probably introduces major new  security flaws. (I've discussed at
length the issues of just who will be reading the CMR messages. It's very
unlikely such CMR messages will simply be archived away for that rare day
when someone's old messages need to be "recovered" for the reasons usually
given...in fact, as I have been arguing, I can't imagine companies even
bothering to get some transient piece of e-mail sent 2 years earlier by
Alice to Bob. They don't archive phone calls, and these are every bit as
likely to be "critical" in some sense as old e-mail messages are.)

As this relates to PGP, it just ain't their problem to try to answer the
demands of control freaks in corporate MIS departments that backdoors be
built into crypto products.

(Call it snoopware, call it surveillance software, call it CMR. But what it
really is a backdoor built into a crypto system. And one thing we know from
several decades of crypto work is that backdoors are holes in security.
Given that these backdoors apparently have little use in any real disaster
situations, they represent a serious dilution of security for little or
nothing gained.)

PGP, Inc. should stick to its core business, and not try to build in
snoopware backdoors for control freak MIS managers.

If it is claimed that corporate America is demanding these backdoors, our
industry and community then faces a major educational battle.

If this battle is lost, as it may already be, then the same reasons for
corporations to insist on "emergency access" (which of course won't be very
"emergency" oriented, as actually used in corporations) will be seen by
many to apply to government as well. "What have you got to hide?"

Keep it simple, stupid. That makes for efficiency, functionality, and
easier product development. And it doesn't build the case for government to
later demand message recovery.

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