Orthogonality and Disaster Recovery

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

Tim wrote at length about the usefulness of cleanly separating
functionality.

As this applies to pgp5.x, one could apply this idea in the following
way:

- remove pgp file encryption functionality from pgp5.x

- store decrypted emails in the clear in mail folders

- develop PGPdisk for more platforms, and/or market a separate file
  encryption program which only uses symmetric keys.  Integrate
  recovery into that if required, or let the users figure out to copy
  the symmetric storage only "key ring" onto floppies and place in
  fire proof safe themselves.


Problems with this are:

- pgp5.0, pgp5.5 already have this file encryption function built in
  (they might not want to take it out)

- several people are arguing for the need for the company to be able
  to read queued emails encrypted to a company use key when recipient
  is away on holiday, or leaves company, etc.

- some people argue for functionality of having email archives encrypted


Once you start trying to tackle those problems, things get unavoidably
complicated as you attempt to balance the criteria of resistance to
political abuse, resistance to privacy invasion, security, ergonomics,
and meeting user requirements.

I think it's useful to attempt to design systems which balance those
criteria, even though anything which automates any aspect of third
party access to data is inherently dangerous and more prone to
government abuse.

Kent Crispin said sometime ago that cypherpunks (he addressed the
comment to the list readership) should have a go at designing
commercial data recovery protocols.

Even pgp2.x is not that resistant to government abuse as an email
transport.  Governments can demand copies of private keys, governments
can request to be 2nd crypto recipients.  Some governments sooner or
later may even try that with pgp2.x itself.

So I think it is interesting to encourage use of perfect forward
secrecy, at the transport layer, and opportunistically in the pgp
encryption layer.

It is perhaps dangerous, but if people are doing it anyway, it is
useful to examine politically government resistant company storage
recovery, and integration of this into pgp implementations, and
standards even.  Not something cypherpunks would normally consider,
I'm sure, but the functionality of the deployed base is all important,
as is the functionality of standards -- and both of these are to a
large extent influenced by commercial users.

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`

On Sat, Oct 25, 1997 at 01:52:05PM -0700, Tim May wrote:
> 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.
[...]
> 
> 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.

You are missing the less well-documented, but equally classic function
of key management, which is a part of any useful crypto system.  The
key management part of it *could* exist as a separate program from the
encryption/decryption part, but they are *far* more closely tied than
word processing and accounting, and what you would have is a crypto
*system*, composed of several relatively tightly coupled programs that
share complex data formats.  Such a crypto system would be quite
useful, and would allow the construction of all kinds of other
products by using scripting languages.  However, the ergonomics of
such a crypto system would not be appropriate for the average point
and click MacWindows Moron. 

[...]

> 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 think you are quite off base here.  There is very little additional 
functionality added by CMR; and the enforcement *is* done by a 
separate program.

[...]

> But are such bloatware crypto programs even good for disaster recovery?

Nice try, but the bloat, if any, comes from the gui and other stuff, 
not the crypto functionality.  PGP 5.x, from a user interface point 
of view, is much simpler than previous versions -- it integrates very 
cleanly and unobtrusively with the system on the MacWindows platform.

[...]

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

Are you nuts?  Of course PGP, Inc, should be worrying about this kind 
of stuff.  They *need* new products to survive.

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

Fine -- you use your personal solution.  PGP, Inc is trying to 
provide solutions that work in an organizational setting, where 
forgotten passwords are a constant fact of life, and where the 
security issues are vastly different from your situation.

[...]

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

If they want to survive as a company, it is.

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

Just precisely what is their core business, Tim -- supplying freeware 
to Cypherpunks?
 
> If it is claimed that corporate America is demanding these backdoors, our
> industry and community then faces a major educational battle.

"If it is claimed..."? Of course it is claimed -- it's a fact.  And
yes, there is a major educational battle -- ivory tower cypherpunks
have to educate themselves about the nature of the world.  You
believe, apparently, that large organizations contemplating crypto are
just misguided or duped by evil governments into doing the devil's
work.  Until you actually grok what is going on you will never be all 
that effective in dealing with it.

-- 
Kent Crispin				"No reason to get excited",
kent@songbird.com			the thief he kindly spoke...
PGP fingerprint:   B1 8B 72 ED 55 21 5E 44  61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html