Key Coercion after encrypted message transmission.

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

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

An anonymous author writes:

[describes an interesting technique to avoid coerced key disclosure]

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

Unfortunately, you seem to have received one of the early drafts of
the Cypherpunk Code; they're easy to spot because a fumble-fingered
editor left out a few words while recopying meeting minutes. The
Revised Cypherpunk Code of 1993 states:

RCC 23.110:
In accordance with the grand traditions established by previous
cypherpunks (RCC 10.100, et seq), any cypherpunk who suggests that
"someone" or "a cypherpunk" or "the cypherpunks" must implement a
new idea shall be required to code the implementation themselves,
on the platform of their choice.

RCC 23.120:
A cypherpunk required by RCC 23.110 to code an implementation may
employ the work of others as a base for their implementation. The
Librarian of the Cypherpunks is authorized to lend the implementor
a copy of _Applied Cryptography_ until the implementation is finished.

Fans of legislative history will remember the passionate debates 
between the theoretical cypherpunks - who stood opposed to any
coerced effort - and the practice-based cypherpunks, who argued that
this re-education effort was required to build the proper [post-]
revolutionary consciousness, particularly in the "why can't someone
else do it for me" climate of the mid-1990's. The debate ended when
Zaxxon, an outspoken critic of the remailers, insisted that all
cypherpunk software be rewritten - twice - to his specifications. The
Cypherpunk Assembly voted 99-0 (1 abstention) to enact the 
"Do It Your Own Damn Self Act" of 1993, codified as RCC 23.110-120.


-----BEGIN PGP SIGNATURE-----
Version: 2.5

iQCVAgUBLkdCuX3YhjZY3fMNAQFvYAP/SH/FHSOXO+CDDikY9G3Cz9PSGhxUQTAC
gMjtTaxafxA8m1MrbW0TPc6lz0HHQfm5f1rkouBhUp8HEvum1LdybbZ79FDfF8Rz
0OtQUt/2oPfVnZd28XhwKZTSPn4tFSa074xMwFJLEcP2YpJoB/U6bEbe1ACA/3+U
ypHvbQDA60w=
=bQ5X
-----END PGP SIGNATURE-----

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.

Remote backup and secret sharing, yes.

   This problem could be
   called the transmission retroactive coercion problem (TRCP). 

This one has also been discussed here, just last week, by me.  It's
the problem of forward secrecy.  It already has a perfectly good name,
thank you.

The original author of the message should find out what Diffie-Hellman
key exhange is and how it can be used for forward secrecy.

Eric

In article <199408090533.AA06475@xtropia> you write:
>
>
>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.
>
Great idea.  You don't need to generate public/private keypairs though.
All you need are IDEA keys in these one time certificates and those
are easy to generate.

Regards,


-- 
Farid F. El-Wailly                 farid@netcom.com