[2080] in cryptography@c2.net mail archive
statement of intent, security of CMR (Re: GAK and S/MIME)
daemon@ATHENA.MIT.EDU (Adam Back)
Mon Jan 26 09:31:07 1998
Date: Mon, 26 Jan 1998 00:48:38 GMT
From: Adam Back <aba@dcs.ex.ac.uk>
To: colin@nyx.net
Cc: cryptography@c2.net
In-reply-to: <199801240708.AAA28558@nyx10.nyx.net> (message from Colin Plumb
on Sat, 24 Jan 1998 00:08:30 -0700 (MST))
Colin Plumb <colin@nyx.net> writes:
> [...] it's nice to have a way to mark a messge "personal and
> confidential" for the times that a sender does need it.
Plaintext handling requests, and statements of intent are nice. We
might like the facility for senders and recipients to make
statements/requests about whether email is archived, confidential,
personal, official company business, distributed to others etc.
However these can't really_ be anything other than requests -- gossip,
forwarding plaintext, and publishing plaintext are larely outside of
our control. So pushing these requests down into the crypto protocol
level as a design criteria does not seem useful -- there is nothing to
enforce.
> If I share my private key, the sender hasn't got that choice.
The mechanism used in the protocols is orthogonal to the statement of
intent idea. We can design alternate systems based on either shared
keys or on multiple recipients and either system can have statements
of intent applied to it.
Local key escrow is politically safer, and I argue more secure than
multiple recipients as an mechanism to allow archived traffic to be
recovered. There are less doors into the ciphertext with local
escrow, and the communicated ciphertext is much more vulnerable than
data on local disks. If governments have to get a supeona and raid
offices to get at traffic, we are closer to the status quo.
Building systems which send session keys encrypted to third parties
over insecure communications mediums to ensure local data availability
is politically risky. The design is too close to something which
would be useful to governments.
> You could give everyone two keys - a "me or my agent" key, and a
> "private and confidential" key, but this system seems to better
> reflect what is actually happening.
You seem to dismiss this half of the solution space (separate personal
use and company use keys) with no justification. Either method can
sit behind the same user interface. You don't actually care about
keys, they are just uninteresting random numbers; you just care that
you have a dialog box which allows you to send private and
confidential mail and care that only the individual key holder will be
able to read it.
> And by pushing the cryptographic operation to the sender, the system
> *must* have the sender's cooperation.
The sender is not typically aware of underlying protocol details.
Whether the implementation presents the user with a choice is an
implementation issue. The command line unix version of one or more of
the pgp5.x versions in fact does not present this choice I think.
> and I'm sure I don't need to explain all the ways that a sender can
> not cooperate even if the appearance of cooperation is required.
Matt Blaze figured out how to hack the tessera cards by brute forcing
the LEAF checksum. The fact that a hacker could hack around a system
doesn't protect many peoples privacy. Most people will use the system
without even the most trivial attempts to bypass. In a sense the
people who's privacy the unavoidable hackability of software message
recovery systems protects is precisely that group who already already
have the know how to use pgp2.3a, and stego programs.
Another issue is that by-passing third party access may be detectable
and in some regimes detection could be detrimental to your health.
> Just sharing the private keys is simple, doesn't make waves (because
> the outside world doesn't see it), easier to explain and sell, and
> generally has lots of advantages. I just thought that it's bad for
> privacy.
I think that the approaches of using locally shared keys vs using
multiple encryption compare as roughly equivalent in the privacy
stakes. You can implement roughly the same statement of intent
choices on top of either of them with similar or identical user
interfaces.
Local shared keys has lots of advantages as you note.
One particular problem with the CMR mechanism is that it fails to
maintain the availability of archived mail. This is because the most
common reason for loss of availability is users forgetting
passphrases, and CMR does not allow the private key to be recovered.
Therefore when a user forgets their passphrase, you need to have the
company key czar go and decrypt all data and re-encrypt it with the
users new key. This is pretty impractical, and as a result companies
will probably also escrow private keys, getting the worst of both
worlds.
Another related comment is that communications keys and storage keys
are used for the same purpose in pgp5.x. They have quite different
security trade offs, and reusing one key for both functions reduces
security. Communications keys should have as short life times as
possible to minimise traffic exposure. Private keys should be
securely wiped after expiry. (ie perhaps shorter expiry periods than
the `recommended validity period forever' given in the pgp5.x dialog
box). Archiving keys are more efficient as symmetric keys -- you
don't need public key functionality. Storage key recovery is better
achieved with selective local escrow. Personal data is protected by
not archiving, or by archiving without recovery information.
A meta comment is that many people pointed out earlier in the CMR
discussions that PGP seems to be making the assumption that companies
want and need to have full audit and accountability for all staff's
email. This assumption does not always hold. There are risks of
discovery processes during litigation with armies of lawyers picking
over old emails. Emails which are not official company statements
might be better proected by purposeful periodic destruction. Several
people commented that they were aware of large corps with such
policies.
Adam
