- cypherpunks-legacy - lists.cpunks.org

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

"gleason speaks at CPSR..."
by George A. Gleason 29 Nov '92

29 Nov '92

Just a quick note of reassurance here. Someone at BMUG saw something I posted about crypto and education and values, and suggested I give a short talk on that to get discussion going. I will definitely Not 1) be a "spokesperson" for anything or anyone other than my own views, and 2) say anything likely to arouse premature publicity regarding things going on in the group or on the list. So in other words I intend to play it way careful, low-key, stick to social issues, and make it clear that there are many people far more qualified than I to discuss technical aspects in detail, and make it clear that there is wide debate and difference of opinion on the subjects of discussion. Now also, apologies for not contacting other folks on the list here when this was just getting set up. Actually it surprised the heck out of me to find out how fast the date came up; I was expecting at least another week. Properly, there are at least ten or twenty people on our list who could be addressing other groups on these issues. Any feedback, email back to me quick, because it's about 12 hours from now...! -gg

2 1

Cypher Bank
by donb＠netcom.com 29 Nov '92

29 Nov '92

Does anyone know of a law, rule, regulation, or other restriction that would prohibit the establishment of a simple cypher based bank? I can think of 3 basic areas that would have to be satisfied: 1. Federal law and agencies, Federal Reserve, etc.. 2. State and local (California for me). 3. Internet "Appropriate Use" policy. If the bank is operated on a not-for-profit basis --as an experiment. Then that should satisfy the appropriate use requirement. I could use some comments if anyone can cite specific federal or California regulations. Please respond either to me directly, donb(a)netcom.com, or to this mail list. -------- The cypher bank would work like this: I would publish my physical address; and offer to accept deposits by cash, check, or what have you. With the deposit, write on it your PGP handle. Email me your public key corresponding to the handle on the deposit. I will maintain a public list showing handles vs. Amount received, in collection, and in escrow.(Set Subject = "BANK" to get the list) Funds will be paid out based on instructions encyphered with your private key. Comments would be appreciated. Don Bellenger donb(a)netcom.com

4 3

Remailer followup
by edgar＠spectrx.Saigon.COM 29 Nov '92

29 Nov '92

No-one has replied to my request for help using the remailer at Remailing Service <hal(a)alumni.caltech.edu> Am I the only person having trouble making this thing work?? Recall I had to use the "::" convention since I can't specify network headers (except subject) from this system. -- edgar(a)spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca

1 0

crypto banking
by Karl L. Barrus 29 Nov '92

29 Nov '92

I'd like to see a digital bank go up as well - just to be able to work through the protocol, at first. I took a cryptography course last summer at the university, and learned a lot (and had some fun!) working through various protocols: coin flipping, poker, subliminal channels, number comparison without giving away the numbers involved, signatures, etc., and more recently since joining this group: dc-nets. It doesn't have to be fancy: this list or maybe just email between various participants at first, maybe then a fancier system with transactions posted or made public for study, then a more advanced system with telnet or mail to the digital bank and transactions kept private. We could make everybody's account balance public and then study ways to avoid traffic analysis on account fluctuations (maybe the only way to do this is to keep balances secret) - maybe everyone can have more than one account and pay off transactions with a little bit from each account (this would be inconvenient though...) Anyway, I'm just rambling on... :-) /-----------------------------------\ | Karl L. Barrus | | barrus(a)tree.egr.uh.edu (NeXTMail) | | elee9sf(a)menudo.uh.edu | \-----------------------------------/

1 0