November 1992 - cypherpunks-legacy

Re: The Cypherpunks Mail Project
by tony＠morgan.demon.co.uk 26 Nov '92

26 Nov '92

In message <9211251705.AA17774(a)soda.berkeley.edu> you write: > > It is also my suspicion that simple PGP decryption support is fairly > straightforward, being mostly the ability to run a command on a block > and replace the block with the output of the pipe. I'd like to chip in here, in my _very_ newbie way, that not everybody is running a unix system with the ability to pipe things between processes in so facile a manner. I access the net through a dial up from a MS-Dos machine running KA9Q software. My PGP is of the stand alone sort. I cannot easily get a new mailer to run on this system. Whatever protocol is decided upon, it would be useful if it were not too host-system specific. [FX Crawls back under stone] Tony ------------------+-------------------------------+--------------------------+ | Tony Kidson |`morgan' is an 8MB 486/33 Cat-| Voice +44 81 466 5127 | | Morgan Towers, |Warmer with a 670 MB Hard Disk.| E-Mail | | Morgan Road, |It resides at Morgan Towers in| tony(a)morgan.demon.co.uk | | Bromley, |Beautiful Down Town Bromley. | tny(a)cix.compulink.co.uk | | England BR1 3QE | -=<*>=- | 100024.301(a)compuserve.com| +=================+===============================+==========================+

2 1

Re: RS232 Crypto Dongle (idea for widely accessible crypto technology)
by karn＠qualcomm.com 26 Nov '92

26 Nov '92

I've also been thinking about the risks of running crypto software on hackable PCs and ways of protecting against this with external special purpose devices. My thinking is to limit the external "dongle" to the one function that is truly sensitive and worthy of special protection: RSA secret key operations. It seems to me that whenever you use a PC to encrypt or decrypt something, you have to accept the risk that it might have been hacked, and whatever you do on it might be secretly recorded. But when I now run PGP (or any similar package) on a machine, I must risk much more than this every single time I type in my pass phrase, namely *everything* that ever was or will ever be encrypted with this same RSA key pair. This may well be an unacceptable risk, especially if I'm temporarily borrowing somebody else's machine or using one in a public area. I see this as THE major obstacle to our goal of routinely encrypting all communications, sensitive or otherwise, as a way of "desensitizing" the world to the use of cryptography. The way around this risk is to move the RSA secret key storage and processing operations to some external dongle. The device would have only one primary function -- the execution of an RSA secret key operation. It would not allow the secret key to be read out of the device, although it might have a "zeroize" function to destroy it. (It might also include a good random number generator for the convenience of the host computer.) Everything else (data compression and armoring, public key operations, symmetric cryptography, etc) can and should go in the PC where cycles and memory space are much more plentiful. If the dongle has a built-in keypad, then it could store your RSA secret key encrypted with a PIN that you'd have to enter to enable the device. This would protect you if the device were stolen. Of course, the best protection is to make the device so small that you can conveniently keep it with you at all times instead of having to store it someplace. I believe that "smart cards" are already available on the market that do these or similar functions, although they are much more widespread in Europe than in the US. Comments? Phil

2 1

Unlabelled PGP messages
by ghsvax!hal＠uunet.UU.NET 26 Nov '92

26 Nov '92

Peter Shipley points out that PGP messages are labelled with an identifier of the person they are sent to. This hurts the anonymity of the messages somewhat. What PGP actually puts in the cleartext message header is the "Key ID" of the recipient. This is the low-order 64 bits of the RSA modulus "n" of his key. (PGP displays only the low-order 24 bits when it shows key ID's, but it keeps 64 bits internally.) I understand that there was some discussion during the development of PGP 2.0 of having a mode where this wouldn't be done. One possibility would be to output a key ID of all zeros for a message which wanted to hide who it was for. Then, as Peter suggests, it would either be trial-decrypted by all of the secret keys you have, or, more simply, it would just try your "default" secret key. Most people only have one secret key so both methods would be the same in most cases. Doing it the second way would be a pretty easy patch to PGP. I'm not so sure now that this feature is that helpful. First, you don't have to put your real name in the "user name" field. You could use a pseudonym. So you really don't have to give much information away about yourself the way it is now. Also, if someone is sending a message to you using encrypting remailers, they would encrypt it using your key, add remailing instructions for the last remailer in the chain, encrypt that using that remailer's keys, add remailing instructions for the next-to-last remailer, encrypt it again, and so on. (This would be done automatically by some future software - you wouldn't want to do this by hand!) The result is that the mail you send does not expose the key ID of your recipient. That information is only revealed when it comes out of the last remailer in the chain. And by that time, it's no secret, since that last remailer is using the true email address of the recipient anyway. So it's not giving anything away. For the other kind of anonymous messaging, where you just post to a newsgroup or use some other kind of "broadcast" system, the key ID is revealed and for this case it might be better to hide it. But, the key ID can be useful in this application by letting you know which messages you should decrypt. No one has to know that a particular key ID is "you". You can still download 1000 messages and only read yours without anyone knowing which ones you read. But with key ID hidden you would have to decrypt them all to see which are yours. Do you want to decrypt all 1000? This will take minutes, hours, or days, depending on your key size and computer speed. (Most of the decrypt time is spent doing the RSA step, at least for most messages, and you can't tell if it's for you without doing that step.) This still might be a good idea, but I'm not sure... Hal Finney 74076.1041(a)compuserve.com

1 0

Re: Electronic Banking
by mark＠coombs.anu.edu.au 26 Nov '92

26 Nov '92

>(A minor note: I ended up doing the Xeroxing for free, which hasn't >yet been declared illegal...though I presume you'll all carefully note >this on your tax returns, as such "barter exchanges" are reportable >income. In theory, which shows how hopeless tax collection is >becoming, all of our "mutual consulting" on this list, and on the Net >in general, is _taxable income_--just as if we were plumbers and carpenters >getting together to work on each other's houses. A crazy system.) So *thats* why nnacct is there :)... Does the tax office get an email from each news admin every fiscal year? :) So they can charge us for services rendered by the net? With regard to digital cash, I have yet to read (or have forgotten the definition) the implementation. What I preceive it as is a form of IOU's that if someone does something for you then you send them an applicable amount of credits. To simplify it a bank could issue credits and people could trade in them, sending them back and forth, each digitally encrypted and based on the amount of credits in each persons bank account. I assume each transaction would be validated through a bank to ensure the credit is unique and the right value? E.g: Customer gets suppliers account number from the supplier encrypted with the banks public key. They send it and the amount of cash to transfer to the bank all encrypted with the public key of the bank. The bank decrypts, gets the amount and decrypts the destination account. It then sends a message to the supplier saying that amount has been deposited in their account and the transaction between the customer and supplier can be completed. Otherwise it tells the supplier (and customer) there is a problem with insufficient funds or incorrect data. The cash may be held in ether until both parties confirm the transaction has been completed. If the commodity is electronic data the supplier may send to the bank a transaction private key encrypted with the customers public key so that the customer cant cheat the supplier as he has to ask the bank for the information to access his/her data which has been encrypted with the other half of the transaction keypair. That way the bank knows the transaction has been completed and it finishes the transfer of funds and sends the transaction private key to the customer. Each commodity, especially if it was physical might be serialized so there could be proof that the customer purchased that item with that SN. If the merchant was a crook the audit trail would catch him... the customer wouldnt be able to cheat as the merchant wouldnt have to release the goods (as is the situation now in Real Life (tm)) until the funds were paid. Issues of Big Brother spying on your transactions apply here but I guess one could always use a psuedonym for the electronic commodities and a postal box paid for with digital anonymous cash for the physical stuff.. (assuming it was mail order... you wont have to give a name for store buying, just a bank public key and your encrypted account number.) Someone might even want to set up a physical forwarding company which merely acts as a buffer for people to increase their privacy. Paid for anonymously and digitally. I havent heard of any companies specialising in this type of service to date. This make any sense? Has it been said before? Mark mark(a)coombs.anu.edu.au

1 0

Re: How far is to far?
by George A. Gleason 25 Nov '92

25 Nov '92

Miron writes, "Charge for the mix services with crypto money. The crypto money could be some networking service..." Only problem is, once we start anything like a formal barter system, it comes under the IRS. The way to avoid that is to keep it a volunteer organisation with an expectation of time commitment to projects or to payment of membership dues. Not-for-profit organisations are of course regulated in a minimal way (think of your local Model Railroad Club), but the accounting isn't as strict and the membership transactions don't have to be reported in detail. -gg

3 2

The age of the engineers...
by gnu＠cygnus.com 25 Nov '92

25 Nov '92

------- Forwarded Message To: junk Subject: quotd Date: Wed, 25 Nov 92 14:12:06 -0800 From: ambar(a)cygnus.com - ------- Forwarded Message Date: Wed, 25 Nov 92 17:06:28 EST From: CyberBunny <kjc(a)cs.rutgers.edu> This is not the age of pamphleteers. It is the age of the engineers. The spark-gap is mightier than the pen. Democracy will not be salvaged by men who talk fluently, debate forcefully and quote aptly. Lancelot Hogben Science for the Citizen (1938)

1 0

RS232 Crypto Dongle (idea for widely accessible crypto technology)
by yanek＠novavax.nova.edu 25 Nov '92

25 Nov '92

A very useful device for people who can not trust the host they are talking to such as users of multiuser unix systems, or low security BBS systems, or "public access" workstations or PC-s, (this includes almost every single person that uses e-mail, except probably for users of a high-security mainframe communications system) would be an RS232 crypto "dongle" that would sit between the terminal (or modem) and the remote system. It would contain some tamperproof (write and decrypt only, can not be read out without a great deal of trouble) memory (as someone at the midnight crypto session at Hackers was talking about) for storage of the private key, some nonvolatile memory (flash eprom?) for the public key ring, and a processor to do the encryption/decryption. It would look (if all that can be fit into a small enough space) like a null modem or a gender changer. (or an RS232 break-out box). If crypto tech ever becomes illegal, it could even be disguised as one, with some special signal combination enabling the crypto function. It should also contain some out-of-band signal such as an LED to indicate that it is actually doing the decryption, instead of the host mimicking it. If introduced now or in near future, this device could become incredibly widespread, since most everybody that is accessing any form of e-mail goes at some point through an RS-232 link (either a terminal hanging off a terminal server, or a PC connected to a modem). Also, it would not require ANY special software on the host or the pc, nor any special terminal. Thus it would work with any of the great variety of e-mail and BBS sysetems that exist, instead of having to deal with each of them individually as a purely software-based approach would have to. It would also be completely independent of the type of computer/terminal or operating system used. You would send the usual mail command to the host, type the magic sequence to the encryption device (or even better, flip a little switch), and then type your message. The device would send to the host the ciphertext, while echoing the plaintext to your terminal so you can see what you are typing. The plaintext would never travel further than the RS232 connection between your terminal and the encryption device. When you receive an encrypted message, flip the switch on your device to "decrypt", and tell the host to send you the message. The host and any intervening networks would only see the ciphertext. The only place the decrypted text appears is on your terminal. I think this is as secure as you can get (until a decryption implant can be put in your head :-). Now, to allow the use of existing tools (pagers, editors, mailers, etc) the device should be completely transparent except when performing the crypto function. Even then, careful design should make it pretty transparent. For example if it passed all control characters intact, it could be used with a text editor that uses control key sequences for movement. It could be programmed for most common arrow key sequences, and for commands for editors such as EMACS, vi, etc, to pass them through unchanged. Same thing for receiving. When decrypting, it should pass through unchanged any characters passing through the other way, and should not interfere with terminal control characters, so any mail viewing program would not be affected. Additional functions it might include are generation and verification of signatures, an echo mode with decrypt/encrypt (so you could store the encrypted texts on your local drive, and to view would just "ascii upload" them to the device while in a comm program; also you could prepare the text of a message locally, while storing the encrypted text echoed back. Then you could upload the cyphertext to the system), a simple local editor and viewer, and anything else we have the ROM space for. Once the basic hardware is developed, there is nothing to stop one from including any desired features. Is anyone here already working on something like this? If not, is anyone interested in working with me on developing this kind of a device? I have the design pretty much thought out (this post is just a summary). I also have a clear picture of the prototyping and development process, and am capable of writing the software part. I would like to work with a partner who knows the hardware part of all this. I.E. the RS232/UART control, PCB layouts, that kind of stuff. Also, I know almost nothing about the technology of tamperproof memory storage. The main objective of this is not to make loads of money (though that would not hurt either) but to increase widespread accessibility and use of good crypto technology. So I would make the schematics and code available, in case anyone wants to be SURE and build one themselves. This could probably also be made available in kit form, that could be assembled by the user. (an interesting parrallel: this is how the personal computer was first distributed... look at the prevalence of PC use today!) This way they can be more sure that it does what it says it does. So, if you have read this far you are probably interested in this. PLEASE reply to me or to the list. If you are the person I am looking for to help with the development, please contact me soon, using one of the addresses or numbers listed in the signature. If you think you would be interested in buying or using such a device when it is ready, please let me know. If you have any improvements to the idea, or other comments, or reasons why you think this device would not be useful or could not work, please let me know too. Waiting for your feedback.... -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek(a)novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819

2 1

Re: Question about the MacPGP
by George A. Gleason 25 Nov '92

25 Nov '92

re Tai's item about more user-friendly decryption on the Mac version.... Seems to me we need it for encryption as well... For instance, telecom software which allows you to back out into a screen editor where you write something and then encrypt it, and then get back to telecom and transmit the ciphertext directly. In my use of email, spontaneous mail and replies are vital. Having to go offline, go into WP, compose, go to crypto and encrypt, then go back to telecom, link up again, and transmit.... Holy cow, if that were a prescription for safe sex, it would be "Start a romantic evening. Just when you and your Love are sitting by the fire holding hands, get in the car, go to the drugstore and buy condoms. Then come back to where you've left your Love waiting by the fireplace, and try to get back in the romantic mood. Then before bedtime, walk around the house to make sure all the lights are off and the oven is off and the dog is in and the cat is out. Then retire for the night, and try to get the romantic mood going again, hoping that your Love hasn't fallen asleep while you were making your rounds..." Eee-yow, we can do better than that! -gg

3 2

Re: SF Bay Area Parties
by rfm＠Eng.Sun.COM 25 Nov '92

25 Nov '92

Edgar Swank wrote: > Cypherpunks, <cypherpunks(a)toad.com> > Extropians <extropians(a)gnu.ai.mit.edu> Libernet <libernet(a)dartmouth.edu> > Since all the above groups, of which I am a member, are not known > for sponsoring social functions, I suggest we co-opt the Pen SFA > parties. Their latest "Winnie" newsletter is attached. Please note > and follow "rules". I especially recommend the 12/26 party. ... Interested people are definitely invited to attend PenSFA parties (though not to "co-opt" them..), but we prefer not to post the meeting notices to random mailing lists since they include hosts' addresses and phones. [Edgar didn't know this because I failed to tell him; my fault, not his.] But please don't forward the whole Winnie on to other lists. (Especially, don't post it to USENET...) If you'd like more information on PenSFA, email me, I have a information handout to give you; also email me to get on the list for more announcements. Rich (rfm(a)eng.sun.com)

1 0

An easy-to-reply anonymous mail scheme
by yanek＠novavax.nova.edu 25 Nov '92

25 Nov '92

> >is this: Just include a public key in your post. And ask any repliers to > >post to the newsgroup, encrypted with that key. No-one else but you can > >decrypt the reply, and no-one can know that you did, since everyone receives > > all of my own and everybody elses schemes is that it requires an INVOLVED > replier. I need some way that I can send out an anonymous email, and have > the receiver of that email just hit "r" to reply to me. If they have Ok, if that is what you want, then the following procedure will let you do exactly that: post anonymously, with a reply address that people can just 'r' to. And no-one (not even the host that is handling the replies) has to know who you are. There exists a site, lets call it remailer.com. It watches the newsgroup alt.key.announce for messages with the "Subject: remailer public key notice" that contain a public key. It takes each public key, and perofmrs some sort of hash function on it, tcreate a short "key id". (note: the hash function must be cryptographically strong, i.e. it should be very difficult to construct another key with the same hash value). It stores hash and the key in a database. Then whenever it receives a mail message to reply.HASH (where HASH is the key id), it encrypts the message with the associated public key, destroys the plaintext message, and posts the ciphertext to alt.w.a.s.t.e. So to use this, you would generate a public/private key pair, and compute the hash function of the public part. Anonymously post the public key to alt.key.announce, and then send your message by whatever means you like (anon mail, anon post to a regular newsgroup, anything) using reply.HASH(a)remailer.com as your return address. Then watch alt.w.a.s.t.e for replies and decrypt as received... All the recipient(s) have to do is press 'r' key and type the answer. You are guaranteed anonymity because no-one can find out who decrypted the alt.w.a.s.t.e message, since everyone received it. All you need is a good way to anonymously post to a newsgroup. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek(a)novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819

2 2