- cypherpunks-legacy - lists.cpunks.org

anonymous bank accounts via
by Fen Labalme 13 Oct '92

13 Oct '92

Mail*Link( Remote anonymous bank accounts via pem FYI: [pem-dev is a private email list for developers of the Privacy Enhanced Mail protocol additions to Internet mail, originally published as RFCs 1113 - 1115, and now updated as four draft-ietf-pem documents. To join the list, send email to pem-dev-request(a)tis.com. By the way, most of the discussion is not nearly as germane to our ideas as this particular posting, but this one caught my eye as of some iterest to cypherpunks.] ----------- Forwarded Message ------------ Date: Tue, 13 Oct 92 01:07:39 EDT >From: uunet!ellisun.sw.stratus.com!cme (Carl Ellison) To: pem-dev(a)TIS.COM Subject: Re: [Peter Williams: Perhaps OSI security is not possible in a liberal community!] Sender: uunet!TIS.COM!pem-dev-relay Let me throw in another vote against the *necessity* of hierarchical certification by arguing against the necessity of certification itself. For example, it is possible, given digital signatures, to have totally anonymous bank accounts -- identified only by public key -- with no certification of relationship between that key and any other fact about any individual or corporation. Such accounts are at least as valuable as a Swiss numbered account -- perhaps more so since no one need know the identity of the person or people with the power to withdraw funds. Such funds transfers can be made not only anonymously but untraceably. It might even be possible for them to be made without it being possible to trace the transfer at either end (eg., using digital cash techniques). I don't propose that all bank accounts be anonymous. It's just that I don't like to see us jump into an attempt to relate public keys into the physical world so that our old established notions about relationships and responsibility can carry over into this new domain when by doing that we end up avoiding research into all the possibilities which digital signatures open up. That research needs to be both technical and social -- or we could shy away from it by forcing relationships between keys and those entities to which we are already accustomed. --Carl

1 0

Where to get further information about PEM
by gnu＠cygnus.com 13 Oct '92

13 Oct '92

Get the latest Internet Drafts for PEM; the RFC's are out of date. By ftp to nic.ddn.mil, directory internet-drafts: -rw-r--r-- 1 gvaudre 35978 Sep 4 03:36 draft-ietf-pem-algorithms-01.txt -rw-r--r-- 1 gvaudre 16031 Sep 2 03:36 draft-ietf-pem-forms-01.txt -rw-r--r-- 1 gvaudre 85132 Aug 7 03:30 draft-ietf-pem-keymgmt-01.txt -rw-r--r-- 1 gvaudre 104515 Jul 25 03:30 draft-ietf-pem-msgproc-02.txt -rw-r--r-- 1 gvaudre 128 Sep 2 03:36 draft-ietf-pem-notary-00.txt John PS: I too think that other key certification models besides "hierarchical" are appropriate. I think we can start from PEM software and PEM message formats and evolve and experiment as appropriate. Before you ask, currently there is no PEM software widely available. It's in alpha test. It will be released in full source code, and its development was funded by DARPA.

1 0

New remailer...
by Hal 13 Oct '92

13 Oct '92

I have been experimenting with Eric's remailing software on the Sun 4 I use at work. This is what I've found. First, Eric's descriptions of how all the different software components work together have been very helpful. The software has gone through three revisions as Eric added new features, so I implemented them in that order - first the basic remailer, then adding the "##" and "::" support for header management. (I had to get perl and slocal before I could get started. Luckily my system already uses sendmail.) Basically, I was able to put the parts together the way Eric described and have it work. I was able to send messages and have them remailed. I even did some tests bouncing mail between my remailer and Eric's. Then I tried adding a new feature to the remailer - automatic message decryption using PGP. It's not really very secure since anyone with root privileges at my site can see my pass phrase, but my site is pretty isolated (a 2400 baud modem is the only link to the outside world). For this I had to add one line to Eric's model .maildelivery file to invoke my PGP filter, and had to write about a five line shell script to run PGP in a useful way. I am still tuning this a little bit but I can send the exact scripts out when people are ready for them. One nice thing about this is that, with my remailer plus Eric's, and with the decryption option, you can now send anonymous messages for which no one person can tell that you did it. What you would do is to send the message first through Eric's remailer, so I don't know where it came from, then through my remailer, but with the message encrypted so that Eric can't tell where it's going after it leaves me. If more people will run remailers then we'll have much more security. I will now tell you how to use it, in case you want to experiment. But remember that all messages are going across an intermittently- polled 2400 baud modem, so don't expect fast turnaround and please don't send a large volume of messages. Also, please don't pass information about this remailer beyond this list, for now. The remailer is at hal(a)ghs.com. The basic remailing operation is as Eric has described: either put "Request-Remailing-To: <dest>" in the header of the message, or put, as the first two lines of the body of your message: :: Request-Remailing-To: <dest> And follow these two lines with a blank line, then the message to be forwarded. Decryption is just a little complicated. The thing to remember is that you want to do more than just have me decrypt the message. You want me to then remail the message after decryption. This means that you should prepare a message with remailing instructions as above, then encrypt the whole thing, including the "::" and "Request-Remailing-To:" lines. Encrypt using PGP with the public key I show below, and use the -a flag for Ascii output. This will create a PGP output file, typically with the extension .asc. The first line will be: -----BEGIN PGP MESSAGE----- Now, you can send this message to me, but you have to do one more thing. You have to mark it as an encrypted message, by putting the line "Encrypted: PGP" in the header. If you can't put stuff into the headers of messages, then use Eric's "::" feature and add the following two lines, then a blank line, before "-----BEGIN PGP MESSAGE-----": :: Encrypted: PGP Don't forget the blank line after these two. Now, this message can be sent to my remailer. It will be decrypted and then remailed to whomever you requested. I know this sounds complicated, so let me break it down into steps: 1. Create the message. 2. Add "::" and "Request-Remailing-To: <dest>" and a blank line to the top. 3. Encrypt the whole file using PGP and the public key below. 4. Add "::" and "Encrypted: PGP" and a blank line to the top of the encrypted file. 5. Send it to hal(a)ghs.com. That's not so bad, is it? Now, if you're really adventurous, here's how to do the double-remailing process I described above, the one which keeps any one remailer from knowing who's talking to whom. 1. Create the message. 2. Add "::" and "Request-Remailing-To: <dest>" and a blank line to the top. 3. Encrypt the whole file using PGP and the public key below. 4. Add "::" and "Request-Remailing-To: hal(a)ghs.com", then a blank line, then "##" then "Encrypted: PGP", then a blank line, to the top of the encrypted file. 5. Send it to hughes(a)soda.berkeley.edu The only complicated step is step 4, where you put in the remailing request to go from Eric's system to mine, and use the "##" line so that the outgoing message has "Encrypted: PGP" in the header. If you want real security, encrypt the message using your friend's public key after step 1 and send that. Then nobody will even know what you're saying, let alone who you're talking to. As promised, here's the public key for my remailer: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.01 mQBNAirY9EoAAAEB/iuDBqpeJ8gsNQwJNRYWBxH7uP95ApQ92CDhCmuSEJ0Tta0l oCrC+8Br+D7Nfotb7hJlI0A1CYGAlmCsRO8VEmkABRO0H1JlbWFpbGluZyBTZXJ2 aWNlIDxoYWxAZ2hzLmNvbT6JAJUCBRAq2ISQqBMDr1ghTDcBARYlBADCjkCkIDvA 7QFtpYUlYjz/2U+/oDuMZBDlmAw8BCg3sdJG7hnxPE4yVgKoH/ozsb23pbFTPB8H WNEjqTqixNybOKSKH9T8iCaRDA8+bS6xPN4YlWKD/Wg2EiyuOjD3v/vWgiZXzMR5 hpe0CYVJ6bM++hptXu+JxqDReJIot5FFbQ== =p8FS -----END PGP PUBLIC KEY BLOCK----- Hal 74076.1041(a)compuserve.com P.S. Coming soon: anonymous return addresses!

1 0

Mr. Squirrel?
by Hal 13 Oct '92

13 Oct '92

Hi, I've just joined this list. Interesting confusion about Mr. Squirrel. That's one of the problems with anonymity. How do you know you're talking to the right person? What you should do is to use a public key. The pseudonym is not really the name "Secret Squirrel"; anybody can use that. The pseudonym is the public key. Any message signed by that particular key is from that particular squirrel. Any message you encrypt in Squirrel's public key is readable only by him. If Squirrel changes his key, he should sign the message so you know it's really _that_ squirrel who's changing his key (and not some other squirrel telling people to use a new key). A pseudonym is a public key. Hal P.S. Here's my key, signed by PRZ: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.01 mQCNAiqsNkwAAAEEAMKWM52m5EWi0ocK4u1cC2PPyHT6tavk9PC3TB5XBYDegf3d sldRpnjJj1r+aO08FFO+QLEI9wtBqvf1PPP5iLX7sD2uIVlJH14MPtyVtjm9ZKb8 JMtCW74045BgtHBC9yQ3V7vXNV5jM6dE2ocnH4AI/pBFrGLJPKgTA69YIUw3AAUR tCZIYWwgRmlubmV5IDw3NDA3Ni4xMDQxQGNvbXB1c2VydmUuY29tPokAlQIFECqu M1Tidd4O/2f3CwEByrUD/3uoV2y+Fuicrrd2oDawgOw9Ejcx6E+Ty9PVPqKvflLs 0zYyGfeFVSgBbTSDP3X91N3F68nydl9J9VA6QRCGelHM1cZRukCJ0AYbKYfpwUN0 xjEGHsDrd2gT5iWlB3vBZvi+6Ybs4rSq+gyZzVm1/+oRrMen32fz2r0CLgUtHok2 =fF6Z -----END PGP PUBLIC KEY BLOCK-----

5 6

Re: one time pads
by George A. Gleason 13 Oct '92

13 Oct '92

Good hard critique, Eric! Now if I might try to salvage my position... "One time pads are very (much more) expensive on a per-link basis than public key systems..." Yes, of course. However I don't envision OTPs as a standard for bulk encryption on large networks. Rather, for person-to-person communication in small networks. Examples: a group of civil rights attorneys suing the Federal govt., an international environmental organisation's main offices in the capital cities of a small number of countries, etc. Cases where the adversary is one or more powerful governments, and the number of links required is relatively small. Given the nature of the relationships between these kinds of networks and their adversaries, the expense would seem to be justified; in any case, the **incremental** cost of for instance a set of 30MB cartridges as compared to a few floppy discs, is an minor fraction of the cost of the airline tickets and other expenses for trusted couriers. (oops: "a minor fraction...") Your discussion of bandwidth can be met with a similar counter-arguement. First of all, I would reject the use of UPS or (God help us) the *Post Office* as a courier, particularly where one or more governments may be the adversaries against whom protection is needed. So your reference to those carriers is not relevant to the main point of my case. I'm assuming that key materials are transported by trusted courier and are guarded by same until they reach their intended recipient. Okay, that *really* drives up the cost, doesn't it...? Not if the key materials "hitch hike" on an existing travel plan: attorney A flies out to city B to visit attorney B... and happens to carry key material onboard in his/her shoulder bag. No added cost except for the storage devices, and that is not significant. Re mathematical breakthroughs in factoring etc, you say, "we don't know when that will happen, and we don't know which will happen." Exactly my point. *We* don't know. But the NSA and so on, most certainly do know, and they won't be telling. If the breakthrough comes, then the period between that point and the point when it is publicised, will be one of false security. Was it Kahn who said nothing is more dangerous than a bad cipher? My point here comes down to nothing more or less than the principle of caution in the face of an unknown. (Discussion of relative cost of brute force solutions, and the question of hard problems and scale.) I agree that my intuition about these things may be highly flawed. However this doesn't invalidate my point about the possibility of basic breakthroughs happening behind closed doors. Now in a way I'll admit that my arguement here sort of comes down to a black box. However, again I would assert that there are cases where the almost irrational caution is worthwhile. You say in concluding, "Perfect security is not worth the cost in time, effort, or dollars when the marginal cost of perfection is less (do you mean more?) than perfection." You cite examples of international banking systems. I would cite examples of political movements which have been sabotaged and destroyed by government covert action. One need not look far to run into COINTELPRO and the more recent French govt action of blowing up a Greenpeace vessel. Where your adversaries are the intelligence agencies of world powers, and where lives are at stake, I would say the cost of perfect security is justified. Now of course, the French terrorist bombing, the destruction of Black nationalist and student organising groups in the US, and other examples, may not (probably would not) have been prevented altogether by adoption of perfect communications security. Che Guevara after all used OTPs, and it was radio direction finding and traffic analysis (rather than cryptanalysis) which ultimately led to his murder by US-backed mercenaries. If we are promoting a tendency which is inherently political, it implicitly recognises governments as its adversaries. Our choices of cryptographic systems should reflect a wide range of applications and not exclude some a-priori on grounds of cost or convenience. -George (gg(a)well.sf.ca.us)

3 2

Re: Game items
by George A. Gleason 13 Oct '92

13 Oct '92

The examples I always refer to are Federal civil rights suits naming the Federal govt as defendant, and international ecological organisations conducting whatever business they may be engaged on. These may or may not fulfill the game objectives, and they do tend to suffer from being a bit mundane perhaps to the point of being unexciting. However they are historically relevant and probably will be so in the future. Another possible topic would be womens' access to abortion, though given the coming change in our govt this may be irrelevant. How about GIFs depicting sex between consenting adults? Corporate proprietary information on new technology, in an age of increasing international competition (in this case the physical prototypes as well as information about same). International intrigues are always interesting: small countries seek to combine economic power against large countries, that kind of thing. -gg

1 0

Re: drugs and simulation games.
by efrem＠spitha.informix.com 13 Oct '92

13 Oct '92

Unfortunately the first two things which come to mind are: coffee (a drug - actually an excuse for gathering) papers on public key cryptography (primary information) radios - illegel in Russia and I believe elsewhere during WWII East German typewriters - I had one Also a slight deviation: many medicines (and soon herbal contraptions) which are doctor monoply items here, but over the counter in most other countries. Religious artifacts of any number of banned religions. Divorce (opps, not a physical object). Really on thinking about it, I believe that the trade of ideas is always far more repressed than the trade in any kind of stuff. --Efrem Re: > We want to develop a list of game items, physical objects, which will > be the goods of transaction. I would like to pick objects that have > been illegal in the past, but which are not anymore. They should not > be primarily information, such as copies of _Ulysses_. They should > not now be restricted. Nor should they be weapons

2 1

The subject of Saturday's game
by ravi＠xanadu.com 13 Oct '92

13 Oct '92

I just joined the list; I've read such archives as are locally available, but I apologize if this subject has already come up. Talking to a couple of people who had been to Saturday's meeting, I was deeply disturbed by the choice of subject for the simulated privacy game - trying to purchase illegal drugs. This is a subject on which rational public discussion is essentially non-existent in this country. Let me first state that I do favor the legalization of drugs, and I am a committed libertarian (as I suspect are many of the people in this group). However, I think it is unwise to tie cryptography in with this issue. Communications privacy is *too important* to take the risk that it will get caught up in the current hysteria of the New Prohibition. There have already been enough government attacks on cryptography that we do not want to give them any more ammunition. I think that if we are committed to getting cryptographic technology in wide use, and spreading true privacy and information security throughout the world, then we need to take careful account of the political and social factors, as well as the technical. In order to be successful, this needs to be not just a development project, but also a marketing campaign. When an MIS manager at some large corporation is deciding whether to upgrade her network to privacy-enhanced mail, we want her to associate it with security and liberty, not the street corner punks who are trying to sell her kids crack. In this vein, let me suggest some subjects for future simulations: - organizing the Boston Tea Party in the face of British spies and informers - purchasing condoms or Lady Chatterley's Lover back when they were banned (these bans seem so absurd now, that trying to get around them seems sensible and ordinary, and may start people thinking about the absurdity of current interdictions) - Yeltsin/Gorbachev vs the coup leaders Furthermore, given the erosiion of constitutional protections in the Drug War, I think the participants in Saturday's game were taking a non-trivial risk to their persons and property. If the risk were necessary to help spread cryptographic privacy, I think none would begrudge it; however, I think it was not only unnecessary, but counterproductive. 'Nuff said. To life and liberty, --ravi

4 3

Next meeting: Nov. 21
by Eric Hughes 12 Oct '92

12 Oct '92

The next physical cypherpunks meeting was decided on Saturday at that meeting. It will be Saturday, November 21, starting at noon at the Cygnus Support offices in Mountain View. I am announcing the date now so that you can put it on your calendar. Eric

1 0

More on packet radio encryption
by whitaker＠eternity.demon.co.uk 12 Oct '92

12 Oct '92

This article was forwarded to you by whitaker(a)demon.co.uk (Russell E. Whitaker): --------------------------------- cut here ----------------------------- Path: eternity.demon.co.uk!demon!pipex!unipalm!uknet!doc.ic.ac.uk!agate!spool.mu.edu!sgiblab!public!grady From: grady(a)public.BTR.COM ( ) Newsgroups: alt.privacy Subject: packet radio encryption Message-ID: <8113(a)public.BTR.COM> Date: 11 Oct 92 19:41:12 GMT Organization: BTR Public Access UNIX, MtnView CA. For info contact: info(a)BTR.COM Lines: 52 Bill Stewart (wcs(a)anchor.ho.att.com) writes, in part: [...Unlike the AX.25 link protocol specified by FCC rules, the higher level protocols are not required to be plain-text...] Do you have a reference for this? And does this apply to the contents, the protocols, or both? (E.g. can you use a crypto-based presentation layer protocol and plain-text payload, or vice versa?) ---- The definitive reference is Part 97 of the FCC rules (available from the US Government Printing Office, Washington, D.C. 20402. Phone orders: 202 783 3238. Ask for "Code of Federal Regulations" 47 CFR 80 to End.) To summarize the rules, except for certain remote control operation as space or repeater machines, nothing can be transmitted with the intent that the meaning be obscured. Conversely, text compression, for example, is legal because, although the plaintext is certainly obscured, it wasn't the _intent_ of the LZ or Huffman or whatever coding to conceal the meaning. Likewise with UUencoding and a host of other compression/ error detection and correction schemes that incidentally involutes the plaintext to some more efficient transmitted form. Spread spectrum is treated somewhat more restrictively since for that mode you may be required to produced the logs and the content of the messages. But not so for narrow- band FM packet. To sum up, using cryptography in general is prohibited. (However, digital signatures are OK, even though based on MD5 or SHA as long as the intent is not to _obscure the meaning_ of part of the transmitted message.) Clearly, though, the burden of proof is upon the FCC to show that a particular message _was_ encrypted, since there is _no_ theoretical, a priori way that an encrypted data stream can be distinguished from one merely well compressed or, just for that matter, random. Of course you should verify this with an attorney if you are troubled with fears of prosecution. Grady Ward KD6ETH/AA -- Grady Ward grady(a)btr.com Moby Lexicons --------------------------------- cut here -----------------------------

1 0