- cypherpunks-legacy - lists.cpunks.org

Re: Crypto goals
by fnerd＠smds.com 24 Feb '93

24 Feb '93

>How about making a list of features we want, and/or a list of scenarios >we want to be able to handle? >... > executable but non-disassemblable code [is it possible?] >... >Have I missed anything? > >-- Marc Ringuette (mnr(a)cs.cmu.edu) Encrypted computing. This is even harder than non-disassemblable code. The idea is that you couldn't even tell what happened to the data if you watched it compute, tried again with slightly different inputs, etc. I've heard that some restricted sort of encrypted computing is possible with an exponential time cost! The main application I have in mind is a mix that would be trustworthy even if it was run by your worst enemies with the best computers in the world. This seems impossible but I don't have proof. -fnerd fnerd(a)smds.com (FutureNerd Steve Witham)

2 1

Front lines of anon.
by Hal 24 Feb '93

24 Feb '93

Lance Detweiler writes: > >You have these security threats which involve people being tricked into > >sending messages through the remailer in such a way that the recipient > >knows the true email address from where the messages are coming. > > These are completely analogous to users being tricked into supplying > passwords in regular login situations. Not a new problem. And anybody > who hasn't figured out that you should *never* put any identifying > information in the message itself is probably a little too clueless to > be using the service in the first place. However, the idea of giving a > warning in the use introduction is ok: ``under NO CIRCUMSTANCES EVER DO > THIS'' type thing. It's not that simple. "Deadbeat" reported that he discovered this problem when he sent mail via Penet to a list member asking a question. When that person replied, it exposed his anonymous ID. There was no need to put identifying information in the message itself. The mere fact that a particular message is being replied to gives away the true email address of the sender (because that is the address to which the question was directed). This means that if you receive mail asking an innocent question, like, "what is the address to subscribe to cypherpunks?", you need to be aware of whether that question came from the Penet remailer or one like it. If so, you need to take extra care when you respond so that your anonymous ID is not revealed. > The problem is that the anonymity is implicitly requested by a message > to the server. Hence replies are getting this anonymity. One > possibility is an override switch in the header that leaves it entirely > intact and the server just acts like another hub forwarder. But what is > this `harm'? We have to recognize these complaints as completely > frivolous and without merit. I don't think so. It seems to me that the current system makes it easy to accidentally expose your anonymous ID. If more people start operating pseudonym-based remailers it will be that much more difficult to keep track of whether you want to be anonymized or not. I think technical solutions are needed along the lines suggested by Eric Hughes and Deadbeat. Hal P.S. How about Deadbeat posting a public key? He keeps signing his messages but I can't check them.

1 0

Newbie comments. (fwd)
by kelly＠netcom.com 24 Feb '93

24 Feb '93

Forwarded message: > From cypherpunks-request(a)toad.com Tue Feb 23 15:40:37 1993 > From: J. Michael Diehl <mdiehl(a)triton.unm.edu> > Message-Id: <9302232326.AA26860(a)triton.unm.edu> > Subject: Newbie comments. > To: cypherpunks(a)toad.com > Date: Tue, 23 Feb 93 16:26:08 MST > X-Also-Known-As: Thunder > X-Goal-In-Life: To make a lot of money -- Wanna make a donation? > X-Mailer: ELM [version 2.3 PL8] > > I've been listening to this list quietly for about 2 weeks. Althought the > signal to noize ration as been a bit low lately, ;^) it's been very interesting. > > I like the idea of alt.whistle.blowers, and support anything that promotes > privacy, and Constitutional rights. > > But I have a (newbie?) question. Isn't it true that, at the network level, it > is still possible to tell where a message came from and where it's going. That > is, given the proper motivation, couldn't "and entity" sniff out all of this > information and find out which machine a particular message came from. And > from logs at that machine, which The Entity naturally has access to, It could > find out who send the message. Just wondering..... Hi there, well acutally at the network interface level all sorts of tricks are available... for example at the smtp daemon level all a snooper has to do is the following telnet toad.com smtp when the sendmail banner is seen then type VRFY cypherpunks That will yeild yet another line referring to cypherpunks-real which verifying will obtain ALL the mail addresses on this cypherpunks mailing list... I have a small fragment of perl which does the same trick recursively for every address on the cypherpunks mail list... why did I write such a thing... well I am writing a mail list to PGP key server extractor so I can automatically extract keys for members of cypherpunks-real... I didnt think of the privacy issue until some moments after I debugged the perl script and got it working... Similiar open holes exist at EVERY level of the Network and associated daemons and software, Johh and I have discussed this earlier via email and he as well as I dont feel its a REAL exposure as the means to protect yourself is well at hand... AND yes ALL network traffic can theoretically be traced thats when crackers and security admins start playing games with connection laundries and firewall as well as early warning systems... there are constraints to real world tracing... the Firewalls mailing list at Firewalls(a)GreatCircle.COM discusses these and other issues having to do with security at the network interface level > > Major suggestion: We need a FAQ! > > Well, that's about it. I'm still trying to get up to speed with pgp. > > +----------------------+----------------------------------------------------+ > | J. Michael Diehl ;-) | I thought I was wrong once. But, I was mistaken. | > | +----------------------------------------------------+ > | mdiehl(a)triton.unm.edu| "I'm just looking for the opportunity to be | > | Thunder@forum | Politically Incorrect! | > | (505) 299-2282 | <me> | > +----------------------+----------------------------------------------------+ > cheers kelly --

1 0

Social engineering tips
by Eli Brandt 24 Feb '93

24 Feb '93

It might be helpful for those involved in the penet flamewar to refer to the service it provides as "pseudonymity" rather than "anonymity". This suggests some level of continuity, responsibility, moral fiber... well, maybe not *that*. But it's worth pointing out that getting a penet pseudonym is no different, really, than getting an account called "u7364250(a)csvax.uza.za". PGP 2 key by finger or e-mail Eli ebrandt(a)jarthur.claremont.edu

1 0

anonymous return addresses
by Marc.Ringuette＠GS80.SP.CS.CMU.EDU 24 Feb '93

24 Feb '93

The recent penet troubles are a reminder that secure anonymous return addresses are a lot harder than secure anonymous mail with no return capability. Maybe it's time to go over the options available to us for anonymous return? 1. Remailer memorizes a pseudonym. I don't like this, mainly because it leaves the remailer operator vulnerable to pressure to reveal the correspondence between real and anonymous id's. It also opens up about a million possible security holes, as we've noticed. 2. The anonymous message includes a cryptographic "stamped self-addressed envelope" which contains a layered list of remailer addresses encrypted at each layer. This requires modified behavior of remailers; they must be willing to "unwrap" an address-list separately from the message body, and then "wrap" the entire message with the destination's public key, in order to disguise the correspondence between input and output. I think this has been discussed here before. Has anyone implemented it? I strongly suggest that this method be implemented in the cypherpunks remailers. Let's call it the SASE feature. What do you think? 3. The reply to an anonymous message can be posted in a public place encrypted for a key known only to the sender. Have I missed any important methods? -- Marc Ringuette (mnr(a)cs.cmu.edu)

3 2

Re: Finding Mac PGP software?
by Dave Banisar 24 Feb '93

24 Feb '93

MacPGP is available at mac.archives.umich.edu via gopher and FTP. FYI. The most recent copies of the pgp site list are available from the CPSR archive at cpsr.org /cpsr/crypto along with quite a few other files on crypto and privacy that may be of interest to the cypherpunks readers. > > I'm sure this is a FAQ, but can anyone point me to an FTP site > where I can obtain PGP for the Macintosh? Does such a beast exist? > Thanks for your time. > > +- eggo(a)titan.ucc.umass.edu Eat Some Paste -+ +- > Yorn desh born, der ritt de gitt der gue, -+ +- > Orn desh, dee born desh, de umn bork! bork! bork! -+ > >

1 0

unsubscribe
by cplai＠csie.nctu.edu.tw 24 Feb '93

24 Feb '93

unsubscribe

1 0

Law&Disorder (fwd)
by tomj＠fido.wps.com 24 Feb '93

24 Feb '93

A friend sent this to me... MODERN TIMES is a good bookstore! They've got lots 'o tech stuff, like internet info... definitely worth checking out. Anyways, the firs tone (Feb) was "Navigating the Internet: a crash course" by Eric Theise. How-to email, gopher, etc. I didn't know about it in time. I think this could be a good crowd to bring up cypherpunk issues with a more social, less hardcore tech perspective... time to stop preaching to the choir! (It's taken a while to find the door leading out of the choir... :-) Tom Jennings > From jerod23(a)well.sf.ca.us Tue Feb 23 10:35:44 1993 > Date: Tue, 23 Feb 1993 10:34:18 -0800 > From: Jerod Pore <jerod23(a)well.sf.ca.us> > Message-Id: <199302231834.AA12863(a)well.sf.ca.us> > To: tomj(a)fido.wps.com > Subject: Law&Disorder > > > Something closer, cheaper and probably more interesting than CFP > > news.1174: Monthly cyberspace series begins at Modern Times > > news.1174.39: fork: Not enough memory (estheise) Mon 22 Feb 93 15:44 > > Here's the press release for show number 2: > > > Jacking In: A Monthly Series on Cyberspace Literacy presents > LAW AND DISORDER ON THE ELECTRONIC FRONTIER > > Computer and telecommunications technologies hold great promise for > individuals and society. Increased access to information can enhance > transborder commerce, informed political participation, community > development, and public health, education, and safety. > > But, between activities of questionable legality and the countermeasures > taken by private parties and law enforcement officials, these > technologies are raising fundamental questions about our notions of > privacy, property, freedom of speech, and freedom of assembly. > > Join us for a evening of provocative readings and presentations by: > > - Bruce Sterling, journalist, editor, and author of *The Hacker > Crackdown*, *Islands in the Net*, *Schismatrix*, and co-author (with > William Gibson) of *The Difference Engine* > - Mike Godwin, General Counsel, Electronic Frontier Foundation, leading > advocate for extending Constitutional protections to cyberspace > - John Draper (a.k.a. Cap'n Crunch), wanted by the FBI for phone > cracking in the '60s, working to promote data encryption in the '90s > - Mitch Ratcliffe, Editor at Large, MacWEEK, and cofounder of This!Group, a > northern California organization working to publicize the benefits and > dangers of a highly-networked information society > - Bruce Koball, General Chair, Third Conference on Computers, Freedom > and Privacy, being held March 9-12, San Francisco Airport Marriott > > Sunday, March 7th, 7 pm > $3-$5 sliding scale > Modern Times Bookstore > 888 Valencia (19th/20th) > San Francisco, CA 94110 > (415)282-9246 -- Tom Jennings / tomj(a)fido.wps.com / World Power Systems / San Francisco CA

1 0

Newbie comments.
by J. Michael Diehl 23 Feb '93

23 Feb '93

I've been listening to this list quietly for about 2 weeks. Althought the signal to noize ration as been a bit low lately, ;^) it's been very interesting. I like the idea of alt.whistle.blowers, and support anything that promotes privacy, and Constitutional rights. But I have a (newbie?) question. Isn't it true that, at the network level, it is still possible to tell where a message came from and where it's going. That is, given the proper motivation, couldn't "and entity" sniff out all of this information and find out which machine a particular message came from. And from logs at that machine, which The Entity naturally has access to, It could find out who send the message. Just wondering..... Major suggestion: We need a FAQ! Well, that's about it. I'm still trying to get up to speed with pgp. +----------------------+----------------------------------------------------+ | J. Michael Diehl ;-) | I thought I was wrong once. But, I was mistaken. | | +----------------------------------------------------+ | mdiehl(a)triton.unm.edu| "I'm just looking for the opportunity to be | | Thunder@forum | Politically Incorrect! | | (505) 299-2282 | <me> | +----------------------+----------------------------------------------------+

2 1

scheme
by Timothy Newsham 23 Feb '93

23 Feb '93

I posted this to sci.crypt, I would also like the opinion of the people on this list: --------------------------------------- I have posted about this before, but this time I decided to whip up some code so you can all see what I'm talking about and all the details. This encryption scheme uses XOR to encrypt data 1 character at a time. Because of this it is suitable for protocols where you need to send single bytes (or less) at a time. Examples of this would be interactive ascii. Also it is easily applicable to crippled lines like 7 bit lines. This is because if the plaintext is 7 bits you can send just the 7 bits after the XOR. Even more general you can use it to encrypt any size at a time, down to single bits if you just have 1 bit to send immediately and dont want to wait for more data to become applicable. Ok. So what are its disavantages? Syncronization, as soon as synchronization is gone thats it, its all over. Each block of 'pad' is generated from previous plaintext, if you cant figure out the previous plaintext you are lost. Notice it uses a hash() function, this could be anything, ie DES, or perhaps a one way function (no unhash() is ever needed). The algorithm is fairly simple, the beginning is a bit wierd and could have been done several ways. The first 8 bits in this implementation are used for synchronization. prog -e key <file >file2 prog -d key <file2 >file3 ok.. here it is.. poke holes in it. What are the weaknesses, is it totally unsecure? Is it as secure as the hash function (ie. if DES was used, is strength equivalent to the strength of DES?) -------------cut here--------------------------------------------- #define SIZE 8 #ifdef MEMCPY #define bcopy(s,d,l) memcpy(d,s,l) #endif usage(s) char *s; { printf("%s [-e|e|-d|d] key\n",s); exit(1); } main(argc,argv) char **argv; int argc; { char data[SIZE],pad[SIZE],c[1],c1[1],*p,key[SIZE]; int cnt,encrypt=0; if(argc!=3) usage(argv[0]); for(cnt=0;cnt<SIZE;cnt++) /* fill in extra characters in key */ key[cnt]=0xaa; strncpy(key,argv[2],SIZE); p=argv[1]; if(*p=='-') p++; if(*p=='e') encrypt++; else if(*p!='d') usage(argv[0]); if(encrypt) { /* to start off encryption, we send a bunch of random bits */ /* then we hash those bits and use them as pad */ blkrand(data,SIZE); write(1,data,SIZE); hash(data,key); } else { /* to start off decryption, we receive the random bits and */ /* hash them (just like the encryptor did) and we should */ /* have the same starting pad as the encryptor */ read(0,data,SIZE); hash(data,key); } bcopy(data,pad,SIZE); cnt=0; while(read(0,c,1)>0) { /* read characters, send them with our pad */ /* every time we run out of pad, we make new pad */ /* by hashing old data */ *c1 = *c ^ pad[cnt]; if(encrypt) /* data is the plain text always */ data[cnt]=*c; else data[cnt]=*c1; write(1,c1,1); if(++cnt==SIZE) { cnt=0; bcopy(data,pad,SIZE); hash(pad,key); } } } /* provide a block of random bits */ blkrand(block,len) int len; char *block; { srand(time(0)); while(len--) *block++ = (rand() >>7)&0xff; } /* hash a block, could be DES, or even a one way function */ hash(block,key) char *block,*key; { char b2[SIZE]; int i=SIZE; while(i--) b2[i] = *block++ ^ *key++; bcopy(b2,block,SIZE); }

1 0