- cypherpunks-legacy@lists.ogf.org

WORD...
by Phiber Optik 16 Jun '93

16 Jun '93

I was just curious... I saw the WordPerfect crack files on soda, and I'm interesting in knowing if anyone knows where I can find a utility that can crack Microsoft WORD encryption. If you don't have an actual utility, but you know how they encrypt, that's fine too. Thanks.

1 0

on the radio
by Steven Levy 16 Jun '93

16 Jun '93

>Steven Levy was interviewed on FM91.7 (san francisco public radio, I >forget the call letters) this morning. My patch cable isnt working for >some reason, or I would have caught it in a ulaw file. >I don't know the name of the show, or if they will rebroadcast it, but >if you're interested, you might try to track it down. I think the name of the show was TechAmerica, or something like that, a show syndicated on public radio. I did the interview about a month ago, me in Amherst, a fairly sharp interviewer in San Francisco. Steven

2 1

Re: YAA (yet another article)
by Jason Zions 16 Jun '93

16 Jun '93

>ComputerWorld >June 14, 1993 >Volume 27, Number 24 >pages 73,74 > >However, a summary of some of those wiretaps, provided by the Federal >Bureau of Investigation, might cause even the most wary to warm up a >little closer to Clipper: > >* A wiretap led to the arrest and conviction of a "sexually deviant > serial murderer" who had operated in New Jersey and New Mexico. As an individual, who would he be talking to via Clipper? His victims? Not bloody likely. High-tech protection doesn't fall under the MO of this kind of killer. >* Another wiretap enabled authorities to thwart Chicago's "El Rukns > street gang" from a Libyan government-sponsored attempt to shoot > down a U.S. commercial airliner with a military weapons system. They find these all the time through other mechanisms. >* The entire leadership of the Mafia's Colombo family was convicted > with the help of wiretaps. Legalize drugs and prostitution and the Mafia will dry up and blow away. Besides, these guys have enough money to have purchased and used private scrambling gear anyway; the fact that they haven't (leading to their capture) leads one to believe they wouldn't use Clipper anyway. If the current leadership is smarter, they'll be smart enough to use non-Clipper gear anyway, eliminating the advantage Clipper gives to the Justice Dept. >Hellman has an ingenious idea that might appeal to those concerned >about civil liberties. He would require not one but three judges to >authorize a Clipper wiretap. A judge could answer the request with >"Yes," "No or "Oh, my God!" The latter means, "This looks like an >attempted abuse of power, as in Watergate." > >If a Clipper tap request got even one "Oh, my God!" decision, the >target of the wiretap would be notified. Because that is the last thing >the requestor would want, it would serve as a powerful check on >frivolous or improper requests. I gotta admit that I kinda like this. I should point out, though, that it ought to be applied regardless of the wiretapping technology applied; that is, this mechanism should be used today for all court-authorized wiretaps.

2 1

unsubscribe
by David Heck 16 Jun '93

16 Jun '93

Please remove me from the mailing list, I'm going to be gone for awhile, completely unplugged...ahhhhh...I'll catch up when I get back. Thanks, David

1 0

fast des
by nobody＠alumni.cco.caltech.edu 16 Jun '93

16 Jun '93

how fast is fast des these days? (i have measured over 2 mbps on decent workstations.) i was in a meeting today attended by someone from nsa who said that 2.4 gbps des chips exists today. (he got real silent after blurting this out. hmm.) 2.4 gbps is 37.5 million des per sec. it is probably not much challenge to put together a 65,536 element machine, which would run at 2.5 trillion des per sec. if i have my arithmetic right, this could exhaustively test the space of 56 bit keys in about eight hours.

2 1

unsubscribe
by Craig Ellis 16 Jun '93

16 Jun '93

Please take me off the cypherpunks mailing list. Thank you.

1 0

Re: Digital cash
by Richard Newsome 16 Jun '93

16 Jun '93

I have a friend who is working on developing a digital cash-like electronic payments system that would be connected to real financial institutions. He says that tthis system will essentially make the entire Internet a single ATM. I don't know any more about this as he is being very tight-lipped about this project.

1 0

MACWORLD article
by mulivor＠orion.crc.monroecc.edu 16 Jun '93

16 Jun '93

In case this hasn't been mentioned here: There's a sizeable story in the July issue of MACWORLD magazine called "Privacy in Peril." It's a general roundup on electronic privacy. I didn't notice any reference to Clipper or digital currency. See pp. 118-130. Carry on, patriots. Phil <mulivor(a)orion.crc.monroecc.edu>

1 0

Re: REMAIL: X-TTL and X-Discard
by jthomas＠kolanut.mitre.org 16 Jun '93

16 Jun '93

Hal wrote: > > What is needed to make X-TTL useful is for the remailer to choose another > remailer as its destination, and ideally to encrypt the message before > sending it. This way X-TTL can be used to insert a random remailer path of > n hops in the middle of a sender-constructed remailing path. This leads to > a system where the remailer decrypts an incoming message, reads the X-TTL > value, decrements it, re-encrypts the message for the next remailer in the > chain, and sends it. The X-TTL value is never exposed to outsiders. > > At one point I wrote a modification to my remailer to cause it to > encrypt any message which it sent to another remailer which supported > PGP. But I decided that this didn't really help security enough to > be worthwhile. It would be much better to encourage users to encrypt > their messages themselves in a nested fashion so that no remailer sees > any more information than the bare minimum necessary. Rolling your own encryption wrapper for the remailer chain you're sending through is a Good Thing, but your modification would be useful if you think of the cypherpunk remailer network as a "back end" for an anonymous/pseudonymous server like Julf's. Ideally, a pseudonym server will only keep an encrypted remailer chain for a user's return address (along with the unencrypted adress of the first remailer on the chain). The nymserver _doesn't_know_ what remailers are in the chain, so it can't encrypt the message with each of their public keys. But if the server can include a header line inside the encryption envelope that tells the remailer to encrypt with the next remailer's key, we can be sure that an adversary is still unable to match up incoming and outgoing messages. Setting up a pseudonym server with this kind of encrypted return address is good, of course, if you're worried about its database being seized. Without the cooperation of each remailer in the chain, the database doesn't give an adversary anything useful. And since now we've got TTL as another use for a next-step-encryption feature in the remailers... I'd better go get those remailer scripts and a UUCP feed for my new Linux box. Joe

1 0

REMAIL: X-TTL and X-Discard
by nobody＠eli-remailer 16 Jun '93

16 Jun '93

-----BEGIN PGP SIGNED MESSAGE----- I don't see that X-TTL is very useful as currently proposed. As I see it, I would have to create something like this: ======================================= :: X-TTL: 5 Request-Remailing-To: remailer1 :: Request-Remailing-To: remailer2 :: Request-Remailing-To: remailer3 :: Request-Remailing-To: remailer4 :: Request-Remailing-To: remailer5 Dummy message to be sent. ======================================= (Or an equivalent structure could be set up with nested PGP encryptions.) This would go through remailers 1, 2, 3, 4, and 5, decrementing the X-TTL field each time, and after the last one when it was 0 the message would be deleted. The X-TTL is not very convenient in this case since you still have to come up with a path for sending your message which is at least as long as the X-TTL value. It seems to me that the X-Discard idea is simpler; you can just put the X-Discard in the command block for the last remailer, and you don't have to count them. What is needed to make X-TTL useful is for the remailer to choose another remailer as its destination, and ideally to encrypt the message before sending it. This way X-TTL can be used to insert a random remailer path of n hops in the middle of a sender-constructed remailing path. This leads to a system where the remailer decrypts an incoming message, reads the X-TTL value, decrements it, re-encrypts the message for the next remailer in the chain, and sends it. The X-TTL value is never exposed to outsiders. At one point I wrote a modification to my remailer to cause it to encrypt any message which it sent to another remailer which supported PGP. But I decided that this didn't really help security enough to be worthwhile. It would be much better to encourage users to encrypt their messages themselves in a nested fashion so that no remailer sees any more information than the bare minimum necessary. Hal Finney 74076.1041(a)compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLB5mUKgTA69YIUw3AQHlRwQAmQ4t6ZcSNbieK4Y8ywj2t1vT1WR9amsY RB1H/cBGfIsVZOcpFb7K5OLrwhTh+aIO6b7sUzXVBsbsgNKLtv0yPjracDpPH5y1 EJ6U9k+74mXDpxl7vo4tqFUiEFd3s3I6by/TjmVAtKy8eX1+o83yo0BJgt9YgNSr psi8xbAFGUI= =4DtE -----END PGP SIGNATURE-----

1 0