From: 7CF5048D@nowhere
Date: Mon, 8 Aug 94 23:01:12 PDT
To: comp.org.eff.talk.usenet@decwrl.dec.com
Subject: Key Coercion after encrypted message transmission.
Message-ID: <199408090533.AA06475@xtropia>
MIME-Version: 1.0
Content-Type: text/plain



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

There seems to be much written about key coercion lately.  It seems to
me that the key coercion problem can be divided into two
problems. First, there is the problem of Princess Leia storing data on
her computer disk for later reference. Then Darth Vadder seizes the
disk and the Princess and coerces the Princess for the encryption
key. This problem may be called the static storage coercion problem
(SSCP). I am not sure that there is a good way of addressing this
problem short of dividing the key in some way among multiple people so
that Darth has a hard time seizing them all. This idea has already
been discussed elsewhere.

The second problem is the case where the Princess wants to send a
secret message to Hans Solo in the horsehead nebula. She sends the
message encrypted to Hans, but the encrypted message is intercepted by
Darth. Hans decrypts the message, but unfortunately six months later
Hans is captured by Darth who tortures him for the decryption key.
Note the Hans is in a worse position than if he were tortured for the
content of the message, because if he were merely asked the contents
of the message with no way to verify, he could simply lie. But Darth
can verify if any keys that Hans gives really does decrypt the
intercepted cipper-text to a sensible message. This problem could be
called the transmission retroactive coercion problem (TRCP). Unlike
the static storage coercion problem, the transmission retroactive
coercion problem does have a technical solution.

If Hans and the Princess were using a public key encryption system
that stores secret keys on disk as a conventionally encrypted file,
like PGP, then Hans could create a separate key pair for each message.
Hans has one long term public/secret key pair which never changes.  He
could send temporary public keys in advance to the Princess as a
signed (using his long term public key) message. Then when the
Princess needs to send him a message she chooses one stored temporary
public keys and sends Hans the message using that key. She then throws
the key away and never uses it again.  When Hans receives and decrypts
the message, he destroys the secret key stored on disk by overwriting
it. Then when Darth goes to torture Hans six months later for the
secret key, Hans can only tell him the passphrase for the now
non-existent key.

People can use this protocol right now with PGP to protect themselves
against this kind of retroactive coercion. It will work. However, the
problem of manually generating the keys and sending them to the other
party and the whole bureaucratic hassle of keeping track of everything
makes it unlikely that anyone would actually do so.

Software to the rescue! Suppose that Hans runs a mail server on his
account which recognizes certain messages as requests for new public
keys and responds by sending back unused temporary public keys to the
requester. It could work similarly to some cypherpunk remailers which
look for some special characteristic in the message to be responded
to, letting the rest pass normally to the owner of the account. The
Princess could also have a mail server on her account which looks for
returned temporary public keys and automatically stores them in her
database after checking for the correct signature without bothering
her. Further, whenever she sends a message, a program could check her
database of unused temporary keys, and if it is low, a request for
more keys could automatically be sent. It seems clear that the whole
protocol could be made largely automatic with no constant intervention
required by the parties concerned once the system was set up. It works
best if Hans has a hardware random number generator.  Then the key
generator part of the process could be set up to run when no one is
using the computer.  (Modifications to PGP have been published that
use hardware RNG's for their Random numbers.)  Since in this case, the
computer is unattended, the PGP passphrase associated with the secret
key must be assumed to be known. To protect the secret keys against
theft in this case, the temporary secret key file could be encrypted
using Hans' long-term Public key.  If there is no Hardware RNG
present, then Hans must be present at temporary key generation time,
to type in all of the stupid keyboard timing strokes! In this case,
Hans will want to create a number of keys in advance to be stored in a
database so that the mailserver can dole them out when people request
them.

A little thought shows that such a system could be used in some
applications of interest to cypherpunks. The ability to implement such
a system is clearly within our grasp. Therefore, the cypherpunk CODE
requires that the cypherpunks analyze, design, code and make such a
system widely available according to the grand traditions established
by previous cypherpunks.

Here are some beginning questions to get the ball rolling. How many
different CPU's Operating systems, mail transport mechanisms and mail
programs can such a program be adapted to?  Should such a program use
PGP to do its encryption, or should it have its own built in
encryption routines. What Language should such a program be written
it? I think the program should be portable to all computers for which
the program is technically possible.  Can someone outside the U.S. be
persuaded to code such a program? It would be best if such a person
could be found.

What do our fellow cypherpunks think?

Remember that when disusing this or any other encryption software on
the net, it is important that our usages be defensively
formulated. Encryption technology should always be used against evil
and for good.

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAgUBLkA6ug2Gnhl89QSNAQFEwwQAv00ZbSiZnFSEg/hBZvFX6RMAAt6uqa2y
UACKlf235ShWff0J2jk6tt2LjrZzoNr1J2qBpaeuXgRqj5zIN3vrvxlW3m9ntlSb
BgLLZbpSjt8FcgWOxDPIIo6bp4U4Qh2NzkNl77kKInpquYmnn3WYZl+KQdwRlsf+
VC3zCfh966M=
=pzkq
-----END PGP SIGNATURE-----