November 1992 - cypherpunks-legacy

Re: Secure key exchange
by George A. Gleason 30 Nov '92

30 Nov '92

Edgar- Two possible points of critique in an otherwise good idea. 1) HOME Address?! As I've said before, that's arguably your most secure datum since it's where you keep your soft, squishy body, and where the baddies and black-baggers and so on would just looove to know where to find you. Let's not make it any easier for them. 2) "I certify that I'm not a cop or spy." That doesn't and hasn't ever held up in any court in the land. Plenty of precedent in drug case law. "I want to buy some pot." "Okay, first tell me under oath that you're not a nark." Result: nark laughs all the way to the police station, with fresh catch in handcuffs. We can't keep them out, and at some future time might want to open up a dialog with the LE community on various issues. No point looking like a conspiracy if we aren't one. -gg

1 0

Some hacked scripts for the remailers
by Bill O'Hanlon 30 Nov '92

30 Nov '92

Here's a couple of real rough Bourne shell scripts to get some mail to go to both Hal's and my remailers. Not too helpful if you don't have a unix machine around--sorry. Nothing fancy, but it'll keep the mental confusion down when trying to put a message together. First is twohop... ------ Cut here ------ #!/bin/sh # Two hop anonymous remailer hal's first, then rebma ... if [ $# != 2 ] then echo Usage: twohop message-file-name destination-address exit 1 fi message=$1 dest=$2 t1=twohop.1 t2=twohop.2 # if the "remailing" and "remailer" names look odd--well, that's what hal's # and my respective keys for the remailers are named... encap $message $dest remailer $t1 encap $t1 remailer(a)rebma.mn.org remailing $t2 elm hal(a)alumni.caltech.edu < $t2 rm -f $t1 $t2 ----- Cut here ----- twohop calls encap twice. Encap is a more general and useful script. ------ Cut here ------ #!/bin/sh # # usage: encap message-file destination remailer resultfile # if [ $# != 4 ] then echo Usage: encap message-file-name destination remailer-key-name outputfile exit 1 fi mfile=$1 dest=$2 remailer=$3 result=$4 t1=encap.1 t2=encap.2 echo :: > $t1 echo Request-Remailing-To: $dest >> $t1 echo "" >> $t1 cat $mfile >> $t1 pgp -ea $t1 $remailer echo :: > $t2 echo Encrypted: PGP >> $t2 echo "" >> $t2 cat $t1.asc >> $t2 mv $t2 $result rm -f $t1 ---- Cut here ----- These seem to work for me... At least, a couple messages now have gotten back to me from them. They helped me get a couple problems out of the remailer. -Bill -- Bill O'Hanlon wmo(a)rebma.mn.org

1 0

UNSUBSCRIBE
by cmr!cmrp!berry_k＠mailer.cc.fsu.edu 29 Nov '92

29 Nov '92

unsubscribe berry_k(a)cmr.fsu.edu

1 0

unsubscribe messages
by Marc Horowitz 29 Nov '92

29 Nov '92

If you don't want to be on this list, that's fine. BUT PLEASE STOP CLUTTERING MY INBOX WITH THE UNSUBSCRIBE REQUESTS!!! I AND MOST OF THE OTHER RECIPIENTS OF THIS LIST CANNOT DO ANYTHING ABOUT IT!! There is a convention on the Internet that if there is a list called foo(a)bar.domain, the maintainers of this list will be on a much smaller list called foo-request(a)bar.domain. Send requests there to get added or removed, not to the whole list. If you get a bounce, then, and ONLY THEN, should you send to the whole list. So, if you want to get off the list, send mail to cypherpunks-request(a)toad.com. It's not hard. And it will keep large numbers of people from wanting to kill you. Flame off. Marc

1 0

Please...
by S950272＠slvaxa.umsl.edu 29 Nov '92

29 Nov '92

Please delete me from the mailing list, the mail volume is too great for me.

1 0

UNSUBSCRIBE
by mcmahonm＠wybbs.mi.org 29 Nov '92

29 Nov '92

unsubcribe mcmahonm(a)wybbs.mi.org

1 0

Secure PK swapping.. what are the methods?
by mark＠coombs.anu.edu.au 29 Nov '92

29 Nov '92

Since Im not sure this got through to the list last time I'll resend. Certainly I havent had any pointers to where to find the information I need.... ------------------------------------------------------------------------ Below is a letter Ive sent to a person designing a communications system similar to IRC but designed with the ability to be anonymous and as secure as possible. Further details will be announced soon when it's stable. --------------------Begin letter----------Begin letter------------------- Before you get too involved with the client in the comm system I was thinking of a way of having secure privmsgs, two forms depending on how open one chose to be: Messages are exchanged via UDP to hide from the netstat junkies... When someone does a msg the first time and the client doesnt know about that user it queries the server to either get a hostname/port pair for that user and/or a public key. The data is then stored in an internal attribute bank. Format of a private message: ._________________________________________________________. | Nickname Plaintext | dest IP | dest udp port | | =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= | | =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= | | =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= | `---------------------------------------------------------' [Return host/port/public key are encrypted into the PGP? message] The above message is then sent to the delivery module of the client. The above host and port are either the recipeints or the server's depending on what type of message is being sent. Thus the same message can go to the server or the recipient direct per se: 1) Using the hostname/port + public key for that user the sender's client encrypts the message and udp transmits a message to that port on the other users host. That remote client has set up a socket to listen on that udp port for messages. The remote client unpacks the message with it's private key and extracts the message, a reply host and port and the senders public key. He can then reply to the sender and they both can talk without loading down the server. Plus, unless someone is logging the ethernet, no one can ascetain wether they are talking. There is only the initial request of the users public key from the server which each client sends in automatically when it connects. You might also have an option in the client to auto download a block/all of the users nicks and their keys so no-one can detect the initial query of a user. 2) The other, differently secure :), form is because the server has been told to hide the users username + hostname from the /who information. All there exists for that person is a nickname and a public key. The senders client gets individually/block downloads the key he wants and proceeds to udp a message to the server which has the udp port and hostname of the recipient as normal from the client connect. It acts as IRC does now, as a middle man for messages. Less secure because the server admin can ascetain that there is a message being sent between the two people and also he can slip in his *OWN* keys to basically grab and decipher messages between the two parties. i.e he sends his own key to the sender and decrypts the incoming message and then sends the message out to the recipient using their encryption key. neither user could tell there was a switch in between. (There are schemes to get past this however). Both ways have their flaws because you are relying on the non-hackedness of the server to give you the right keys and hostnames and ports. A bad admin could easily, knowing enough about coding, disrupt the entire process if we didnt from the start ensure the right protocols were used. It has to be done right the first time or not at all. I'll echo this letter to a cryptography mailing list to ask for details of schemes that will allow each user to know they have a valid, secure public key of the other. One possible solution would be to do a mass query of all the online servers at once and if they didnt report the same keys sound a Real Big Alarm (tm). Maybe an automatom could sit there randomly checking keys :) (Can hear the cries of "No Bots.. No Bots" now :). (Note this allows *someone* to know your doing a query for a user... that may or may not bother the sender/recipient. Doing a block transfer from all the servers at once isnt net.nice) Comments? ------------------End of Letter----------------End of Letter---------------- Now what Im curious about is any other methods of secure key exchange where the exchange mid point may be lying about the keys, the hosts and the ports. Assume each person knows the others 'style' etc. How does one get the real keys to each other with an unreliable "medium"? (It might slip in it's PK). Assume that they havent previously organised a key exchange. Replies to me or the list.. (but not both please.. my mbox is busy enuff :) Mark mark(a)coombs.anu.edu.au

1 0

No Subject
by Marc Horowitz 29 Nov '92

29 Nov '92

>> This entire business may be pretty simple. If we have anonymity >> both ways, (where one or neither party knows the others physical >> location), then who cares about the content of the message? >> >> You might as well send it in plain text, Except you need RSA >> just for the signitures so you know you aren't being spoofed. Very good reasons. "Here is my plan to kill President Foo: ...." Just because you and your hired gun are anonymous, you don't want anyone, especially the government, to read your message. It could throw a wrench into your plans. Marc

1 0

crypto dongle design problems
by Marc Horowitz 29 Nov '92

29 Nov '92

A few comments on "Detailed Scenario of Dongle Usage": >> So, you walk up to ANY terminal directly connected to a host, or to a >> terminal server, or a personal computer of any kind connected through a >> modem, or borrow someone's laptop connected to a cellular modem. As several people have pointed out, terminals are passe'. In general, my mail never goes over a serial line. Here at MIT, most people have unix machines on their desks. Mail is composed on the unix machine, sent via ethernet to the mail hub, and received via POP or NFS from the mailhub. To make life worse, often, the machines are in public clusters where anyone can log in. And, (sit down here), the root password for these public machines is well known. (The servers' root passwords are a closely guarded secret.) So, for me, the crypto-dongle is almost completely useless. >> Call up, or telnet, dial up a bbs, or connect through any other means, >> to your host, and log in. Except IP. One of my machine at work runs SLIP over its serial port. What am I supposed to do now? >> Any time an encrypted message is displayed whose public key ID matches >> one of the private keys on your keyring, the dongle temporarily buffers >> the message it into its RAM, flashes the "decrypt" LED, while >> decrypting the message. Someone else mentioned this, but I didn't understand your response. I read mail in emacs, a full-screen editor. it displays the first screenfull, and I hit space to scroll down. Does the dongle recognize emacs and hit space, or what? >> Now, press the "encrypt" button on the dongle. It presents you with a >> simple line editor, that works with any terminal or terminal emulation, >> but is reasonably easy to use (something like most bbs-es use for >> composing messages). You type your message, or if it was prepared >> ahead of time on the local equipment, you transmit the text. So, I'm trusting the local equipment with my private message. Even if I'm only "typing directly to the serial port", how do I know if my friend's borrowed laptop has been (maybe unknowingly) modified to store the data? Similar problems arise with all the other sample applications you describe. More personal comments: I've had several years of experience designing large-scale systems incorporating security features. One of the most valuable lessons learned is that security and privacy must be designed into a system from the beginning, not added later. Ease of use comes from design, not hacks, which inevitably fail. My view of a useful crypto-dongle is more like Phil's. A device with one serial port, which stores my private keyring. It has functions to list the keys it has (names and hashes, not keys), to decrypt a message (while displaying some external indication of having done so), and to sign a message (again, with display). Programs would have to be modified to use the dongle to do the appropriate very sensitive crypto stuff, and I can do the DES or other work on my desktop machine. I forsee the dongle being made of a well-known CPU or MCU (easily verifiable), an EPROM (software), a static RAM (long-term, encrypted storage of keys), a DRAM (short-term cleartext storage and buffering), a UART, an input keypad of some sort, a small (say 1x20 LCD display for simple output, and perhaps a special chip for the math. Sources to the EPROM would be available, of course. Paranoid people could burn their own chip (assuming they trusted the programmer :-). Yeah, this isn't much use on a dumb terminal, but dumb terminals aren't of much use nowadays, anyway. Marc

1 0

Re: Electronic Banking
by George A. Gleason 29 Nov '92

29 Nov '92

"...and just take the legal risks..." Wellll, what is there to gain by taking legal risks, as opposed to doing a research gig where we're trading in pennies for fictitious goods & services...? Please spell it out explicitly; there would have to be a very significant advantage to convince me to agree. Like maybe that the govt is about to pull all cash out of circulation and this is our last hope.... -gg

2 1