- cypherpunks-legacy - lists.cpunks.org

ps -laxww for randmoness?
by yanek＠novavax.nova.edu 16 Dec '92

16 Dec '92

How about using ps -laxww as a source of randomness? Of course it would be run throug something like MD5 to get rid of the structure. This would not be good on a multi-user system because ps command may have been modified to log the person invoking it, time, and output to somewhere. But on a personal workstation that you trust, it could be a pretty good source of unpredictable data. This is not my original idea, I think it was suggested in one of the multiple precision math packages I looked at recently.

5 6

subscribe
by ahawks＠nyx.cs.du.edu 15 Dec '92

15 Dec '92

Please subscribe me to the list...Heard about it from alt.cp, Mondo, Paco Xander Nathan, and my own FutureCulture list... -- ahawks(a)nyx.cs.du.edu FutureCulture: In/f0rmation ahawks(a)mindvox.phantom.com future-request(a)nyx.cs.du.edu

1 0

remailer extension (contact field)
by Karl L. Barrus 15 Dec '92

15 Dec '92

I've added a contact field to my remailer. To contact me (the operator of remailer03 <elee7h5(a)rosebud.ee.uh.edu>) you can use the following header: ----cut here---- :: Contact: ----cut here---- Note the colon after contact and the blank line at the end. Encryption of this header is supported as well; you can reach me by encrypting this contact header and doing the usual. For those interested - here are the changes to maildelivery and remail.pl (I haven't been able to study the remailer code much, and am just learning perl, so this can probably be improved.) Changes to maildelivery, before the * on the last line Add the following: (I spaced everything out in the file) Contact "" pipe R remail.pl Contact "" file A archive.remail Add to remail.pl, before the block that begins if (/^Request-Remailing-To:/ || /^Anon-To:/) if (/^Contact:/) { chop ; s/^.*// ; $addressee = $_ ; $addressee = "my.id(a)some.other.machine" ; } I don't know perl well enough to figure out what can or can't be deleted (specifically the $addressee = $_ line, etc.) /-----------------------------------\ | Karl L. Barrus | | barrus(a)tree.egr.uh.edu (NeXTMail) | | elee9sf(a)menudo.uh.edu | \-----------------------------------/

1 0

Re: Remailers.
by Marc.Ringuette＠GS80.SP.CS.CMU.EDU 15 Dec '92

15 Dec '92

> It relies on there being at least one operator who won't reveal > his logs. If one of your bounces happens to be through your own > remailer, you can guarantee this. Let's be clear on exactly how useful it is to route your messages through your own remailer. It's not as useful as it first appears. If the Awful Nasties convince all of the remailers downstream of yours to give up their logs, they trace the message back to your machine. You then might choose to say, "Hey man, it wasn't my message, it was just my remailer. And I'm not giving you the logs." But if you're going to use this excuse, you needn't really have routed your message through your remailer at all; you just need to be operating a remailer and routinely refuse to divulge its logs. -- Marc Ringuette (mnr(a)cs.cmu.edu)

1 0

Remailers.
by Hal 14 Dec '92

14 Dec '92

Tim's message brings up a point I've been wanting to mention. The prototype remailer software keeps log files of all messages passed through it. There are different reasons why people running the software might wish to have these logs. One purpose is for debugging; the remailers don't produce much in the way of error messages and the log files can be useful for tracking down errors. A few weeks ago, for example, one user was having difficulty sending messages through my remailer, and he posted here about it. I was able to confirm that his messages had come in and been sent out. However, another possible reason is for the case of abusive messages. I had one message go through that appeared to be directed towards the sender's boss, and was rather unfriendly in tone. The remailers give the outgoing messages the superficial appearance of having come from me. This message wasn't that bad, but there's nothing to stop someone from sending a really vicious, racially or sexually harrassing message, and I am very concerned that I could get in trouble for that. What I've generally done is to delete the log files every few days, usually after a quick perusal to see if there are any messages which the recipient might object to. Sometimes if I see a message which is of an illegal format so that it didn't get sent, (like forgetting the ":" in "Request-Remailing-To:") I'll send a message to the sender telling him what he did wrong. I feel that people who run remailers should set their own policies as far as the confidentiality of the messages they forward. Running a remailer can be somewhat risky in the current climate and the operators can legitimately seek whatever level of protection they are comfortable with. However, I think it would be good if the users of the remailers could get some information about what the privacy policies are. Maybe some remailers will simply not keep logs; maybe others will keep logs but not look at them unless a specific circumstance arises, and so on. Eric Hollander has been creating a list of remailers; perhaps he could solicit this kind of information from the operators and publish it along with the remailer addresses and keys. Hal 74076.1041(a)compuserve.com Distribution: CYPHERPUNKS >INTERNET:CYPHERPUNKS@TOAD.COM

3 2

A minor experimental result
by tcmay＠netcom.com 14 Dec '92

14 Dec '92

One of the purposes of setting up remailers is to experiment with them, see what kind of emergent behavior appears, see what kind of flaws and obstacles arise, see how they break, etc. Here's one: the compromise of my "anonymity" by one of the folks running a remailer. (Who and where don't matter, just the phenomenon itself.) I used a single bounce without any encryption to send a message and got a query from the owner of the remailer saying "I couldn't help looking through my remailer archives and noticing...." and requesting more information from me!! Hoist by my own petard! Several lessons: * Multiple bounces help, even without encryption, as then the remailer sysop can't be sure who originated the message. * Encryption is of course even more desirable, though a hassle (especially for Mac users). * Remailer sysops should make a point to _not_ look at their remailer archives. In fact, they should discard them immediately (for their own legal protection, and for slightly greater trust amongst users, though this is a hazy area...). (Recall that the "mix" on which our software-based remailers are loosely patterned are "memoryless," i.e., the tamper-resistant modules that implement the receive-decrypt-store-forward protocol have no memory of the mapping between incoming and outgoing messages. In fact, the outside world cannot possibly compromise the protocols to get at this information.) So, my laziness in using only a single bounce, combined with the curiosity of a remailer sysop, breaks the anonymity. Neither surprising nor profound, but I thought you folks would like to know. --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | PGP Public Key: by arrangement.

3 2

Re: A minor experimental result
by andrew_derry＠sfu.ca 14 Dec '92

14 Dec '92

> If I wanted to be obnoxious, I could set myself up as a remailer, >then screen all incoming messages to see whether they came from other >known remailers. If not, then I can archive the message, have a look at >it, and maybe compromise the original sender. > > Is this so? Seems quite possible to me.. I think that's why it was suggested a while back that as many remailers be set up as possible. That way, one could use several in a row and virtually eliminate the problem. > In this case, everyone wanting to use a remailer should in principle >*own* a remailer, and you'd probably want your own to be the first >remailer. Then, to avoid compromise of the recipient, maybe you'd want >yours to be the last remailer. So why not use your own remailer >exclusively? I don't think you'd have to worry much about compromising the recipient, if you encrypt the message with with her public key (except possibly traffic analysis, which I doubt poses a problem to very many people, and which can be overcome anyways). > To take this to an extreme, set up a remailer and then use this >*all* the time for the mail you originate. Does this gain you anything? Well, it would probably be ok if a lot of other people used your remailer.. but if you were the only one, I doubt it would be very effective. --- Andrew Derry - derry(a)sfu.ca | ACS@HCC - Simon Fraser University | Standard disclaimers apply |

1 0

MEETING: 2nd Cypherpunks UK
by whitaker＠eternity.demon.co.uk 14 Dec '92

14 Dec '92

[I thought a month's notice on this (second) meeting would draw a little more interest. Our first meeting, 13 December 92, was a good start. -- Russell ;-) ] 2nd Meeting, Cypherpunks UK --------------------------- Chris Tame, of FOREST and the Libertarian Alliance, has generously offered the use of the meeting room at his offices for our gathering, Sunday, 10 January 1993, from 1300 onwards, at: FOREST 4th Floor 2 Grosvenor Gardens London SW1W 0DH 071-823-6550 This is just around the corner from Victoria Station, at the end of the mansion block near Hobart Place. There's a dark green cabbie shelter across the street from the entrance, and some British Telecom payphones. Can't miss it, really. However, if you have trouble, call the telephone number above, or call my pager, on 081-812-2661. If it helps, we're in the direction of Buckingham Palace, which is (very) partially visible from our windows. If you wish to attend, you should bring a 3.5" DOS-formatted diskette (sorry! My UN*X machine is an Intergraph workstation, and I can't use it for crypto) with a copy of your PGP 2.0+ public key. I'll sign it there. Mac users: if you don't have Apple File Exchange (what!?), I'll be extra nice and take your keys anyway ( ;-)) for AFE conversion on my IIcx. Not to fear. It might not be a bad idea to copy your public key on each of several diskettes, so you've got a copy to distribute to each of the others. Don't trust me to copy *your* key to others! As a matter of fact, as there are plenty of power points in the meeting room, you should bring your laptop, and/or a desktop PC: when someone hands you a disk-with-key, you can sign her key, and hand her back her diskette, with your own pubkey added. [Note to the novice: don't hand another person your secret key... the one named secring.pgp.] This should be a lively meeting. Among the topics likely to be discussed are: o The proliferation of PGP public keys in the U.K. o The local development of anonymous remailers and a proposed automatic public key repository at Demon Internet Systems o Electronic networking/email security for the novice o Pro-active proliferation of PGP 2.1+ to interesting European, African, and Asian sites - ftp placement - BBS distribution - sneakernet across borders o The use of HPACK in securing local file installations .. and much more! Mark Turner, from Demon Internet Systems, is likely to be on hand to demo DIS for non-DIS users. We've set up our own local, high-quality newsgroups: demon.security demon.security.keys and established the /pub/ibmpc/pgp archives on gate.demon.co.uk (expanding recently to include all versions of PGP, and "fellow traveller" files). Hope to see you there! Semper vigilans, Semper vigilans,

1 0

A Quote for the List
by DrZaphod 14 Dec '92

14 Dec '92

Here's a quote I snagged off an h/p bbs... thought it was particularly true of cipher-technology as well as computing in general. >>> As life moves to this electronic frontier, politicians and corporations are starting to exert increasing control over the new digital realm, policing information highways with growing strictness. Before we even realise we're there, we may find ourselves boxed into a digital ghetto, denied simple rights of access, while corporations and government agencies make out their territory and roam free. So who will oppose the big guys? Who's going to stand up for our digital civil liberties? Who has the techno-literacy necessary to ask a few pertinent questions about what's going down in cyberspace? Perhaps the people who have been living there the longest might have a few answers. -Mark Bennett <<< TTFN! DrZaphod [AC/DC] / [DnA][HP] [drzaphod(a)ncselxsi.uucp] Technicolorized

1 0

dcnets...
by Hal 14 Dec '92

14 Dec '92

-----BEGIN PGP SIGNED MESSAGE----- I thought I would reply here to Yanek's message about dc-nets since it is a topic that should be of interest to the list. I think it's great that someone is going to start experimenting with these systems. The sooner we start playing with this technology, the better. I have a few general comments about the system. First, I like the idea of splitting the key information management from the communication management. That way people can choose their level of security, all the way up to one-time pads if they want. However, I think there should be another system chosen for exchanging key information initially than using PGP to send large one-time pads. Dc-nets really eat up the bandwidth. Yanek estimates using 125 kb per message sent! And having to send one-time key information around doubles the bandwidth. Also, Eric Hughes pointed out to me in private mail once that a system like this for key information exchange is only computationally secure. You are basically relying on RSA and IDEA not to be broken. As long as you're doing that for this initial experiment, why not save yourself a lot of trouble. Just exchange an IDEA (or DES) seed, then cycle it repeatedly through IDEA (or DES), taking the low order bit or few bits as new random ones. If two people have the same seed, they will generate the same random bits. And if IDEA is secure, your bits should be secure. If they aren't, PGP isn't secure. PGP has code to do this. I think it's in the IDEA.C module. Also see strong_pseudorandom in CRYPTO.C. So, I'd suggest that the key exchange part just exchange a short key and then a program generates the new random bits as needed for the messaging. Keep the key stuff separate, though, so people really can do one-time pads if they want to eventually. Another point is the amount of messaging people will do. I think the system should be enhanced to allow people to send and receive messages to/from non-DC-net participants. Otherwise you have 10 or 20 people who hardly know each other. What will they have to say to each other? You won't get a good picture of message loads. I don't foresee everybody in the world being hooked into interlocking DC-nets any time soon (if ever). But I do think there will be DC-nets for some interested people. They will achieve anonymity amongst the group for messages sent beyond the group. In other words, it will be known that a message comes from a certain DC-net group, but it will be impossible to tell which person in the group sent it. Likewise, messages could be sent to a DC-net group without it being known to whom they are sent. I think this capability should be added very soon to the DC-net software. It sounds like the software may include automatic message-sending capability and if so, something which just recognized a special message header and took it as "Request-Remailing-To:" should be easy to add. Likewise, incoming messages to the Dc-net (which would be sent to some random person in the group) should be easily forwardable to the DC-net system from outside. I don't have a clear picture of the user interface from Yanek's description so I'm not sure how easy/hard these would be to do. One other thing I'd mention: the mechanism of reserving a slot and then sending a message is discussed at some length in the Ph.D. thesis of Jurgen Bos. Tim May kindly sent me an excerpt from the thesis which included this discussion; I think it may have been part of the original cypherpunk meeting handout. Bos compares several message reservation schemes and discusses which are the best. It might be good for Yanek to take a look at this document. Yanek asks about sending encrypted traffic over amateur bands. This is definately illegal in the U.S. The reason is that the amateur bands can't be used for commercial purposes, so the FCC demands to be able to know everything that is being sent to make sure this rule is being complied with. However, there are some commercial packet-radio systems starting up and presumably they won't be subject to this limitation. It may not be practical to incorporate all of these suggestions at first, but I do think that using PGP to exchange a RNG seed would be better than using it to exchange one-time pads. I'm looking forward to seeing the system in operation. Hal 74076.1041(a)compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBKyvk8qgTA69YIUw3AQHyuQP/fXIkyCWR5GCiZsiRvMThcJK5xMbOQEIF ow9S9xQ+7kiiJuF4dVp7NRyNTBjO2tBiQDh4JRKb4Pl7LGq+KKYQSTDzGgEo7hOw dkgujwxbCAXjn2XEMewRHprZMPV4XB+iGIZzQ4piqubzWg8hOV8sMhduGaHKnhGc MlhbbmhToOc= =+cPN -----END PGP SIGNATURE----- Distribution: CYPHERPUNKS >INTERNET:CYPHERPUNKS@TOAD.COM

2 1