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
participants (4)
-
7CF5048D@nowhere -
farid@netcom.com -
greg@ideath.goldenbear.com -
hughes@ah.com