December 2003 - cypherpunks-legacy

Re: Even more unix holy wars.
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

Perry E. Metzger wrote: >Did I mention that DOS used to make you use EDLIN out of the box? Did I mention that UNIX used to make you use ED out of the box? > that Unix is somehow harder to use than DOS. Of course it isn't. Train somebody under BSD (say using csh/tcsh/zsh) and they are totally prepared to get to work under ksh/bash/sh under SVR4. The commands are the same and so are the options, on say things like ps. NOT. Unix commands are powerful and easy to use. For example, to kill a process I have to use "ps -aux" or "ps -ef" depending on which flavor of unix I'm running, note the process id, and do a "kill -9 id". Why can't I kill a job by name (i.e. I can do a "fg %emacs" but not a "kill %emacs".) Unix is filled with design abortions like this. > that X is harder to use than Windows How about better Windows software is available?

1 0

alt.religion.your.operating.system.sucks
by Joe Turner 17 Dec '03

17 Dec '03

I mean no disrespect, but the attrocities commited by the aged masters who wrote most of the operating systems are well documented. I have run into this line of thinking in many occasions (my <insert compiler or operating system> is better than yours...), although it it seems to be more of a sore spot to those who love thier compiler/ interpreter. Most of these observations are made out of ignorance. I get paid for programming under NT, windows, MS-DOS, VMS, RSX, and UNIX, not insulting the designers or users. Additionally, I deal with other people in other companies who love thier AS/400s and IBM mainframes. Hell there is even several programmers here who go misty-eyed everytime the word Amiga is mentioned. I bet there is even someone out there who believes that he/she could write a GUI operating system in COBOL (if someone has accomplished this I would love to see the punch cards...). UNIX is a programmers environment. It is very flexible, and you can do just about anything you want to, provided you have the ability. Spawning processes and child processes are trivial, and much more efficent compared to windows-NT and VMS. Additionally, I don't know of too many operating systems where the source code is floating around. I mean so what if it doesn't come with a pretty shrink wrapped package and a thick getting-started, if you have a question just go find the source code. Geez. And as far as a GUI, most of my work revolves around plain old ASCII. X windows may be "standard" now, but it didn't stop SUN, DEC, etc., from making their own proprietary (errr.. I mean "optimized") versions. I don't know why there is so much whining about: - My GUI interface sucks - Your GUI interface sucks - Your mother's interface sucks. I see no reason to puke up this garbage other people. VMS is more secure (interlock intrusion detection, etc.), but any operating system is only as strong as its users/administrators. The one thing I do not like about VMS is the way the system libraries are structured, but such is life. I was not consulted when DEC was designing the operating system. Thier Xwindows system needs some work, but it does work. NT is cool (if you are running on a 300MHz Sable). I think it is something special when you can run UNIX, Windows, and OpenVMS applications simultaniously on the same box. Can your operating system do that? Hell, for $3500 you can by a 166MHz alpha that will do this. System 7 is great. I just didn't like it. I didn't like the way I was isolated from the hardware, forced to take what the designers thought I needed. Just my preference. Besides, Apple equipment was, and still is overpriced (I should know I used to own several). Windows isn't a true multitasking operating system, and besides its like the old joke, Q: "how do you turn a 486/66 into a 286?" A: "run windows!". But like it or not, it is here to stay. I do like programming under windows over dos, simply because it is a pre-emptive operating system and forces the programmers to write structured code (for the most part) to intercept the messages. But the serial driver code sucks. PDP-11/RSX. Ewwwwww.. MS-DOS. If you want to write fast graphics, assembly is the way to go. Windows just can't keep up. Sure Micro$oft released win-G, but what's the point. Your operating system is so much better than mine are, as is your keyboard, your mouse, etc., My point is that every operating system, programming language, or whatever has benefits and detracting points. If you want to continue this discussion, I will be more than happy to create a list for it,.. then you can rant until you fingers are bloody. -- Joe N. Turner Telecheck International turner(a)telecheck.com 5251 Westheimer, PO BOX 4659, Houston, TX 77210-4659 compu$erv: 73301,1654 (800) 888-4922 * (713) 439-6597 Finger for PGP KEY.

6 7

Secure (!?) Remailer Net
by Nathan Zook 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Maybe I'm way behind the curve on this, but... The traffic analysis that we've seen so far mainly just documents tcmay's "everybody a remailer" concept. If you look, you will notice that these analyses all assume that Alice and Bob are _not_ remailers themselves, and for a good reason. If Alice and Bob _are_ remailers, analysis of the type used here is worthless, especially if Alice and Bob have a policy of not sending any mail unless they first receive garbage, and of sending out garbage whenever they get a letter. HOWEVER, the analysis makes another assumption--that messages are indistinguishable. This assumption does not correlate, as I understand it, with the current remailer net. There are, as I see it, a couple of modifications that (I think) would not impose to great a burden on our longsuffering coders, and, as a side benefit, might allow more flexibility in other matters as well. Standard packet sizes, as I see it, are not very difficult to implement, with a couple of assumptions. (I now assume that all traffic is intra-remailer-net) First, the message is signed with the sender's key. (More on that later.) Suppose a signed message to be forwarded is smaller than the standard packet size. The sending remailer adds a Cutmarks: header. At the end of the message, the cutmark is added, followed by sufficient garbage to fill out the standard packet size. The message is then pgp'ed to the recipent _with COMPRESS = OFF_. Upon receipt, the message is decrypted, and its origination can then be triply verified (at least). From: line, packet size, and PGP signature. Since the message claims to be from a packeting remailer, the packet size should be the standard one. The recipient now has the message that was sent to it. This message is probably itself encrypted, so it can be handled (almost) as if this message were just received. This includes stripping the garbage and (probably) decrypting the message to get the forwarding information. Note that this system would allow the extropian remailer to be compatible with Matt Ghio's alias system. (Right now, the remailer doesn't like separate pgp packets, or packets it can't read, or something.) Under the current system, the precausion is entirely warranted. To make life even more fun, there is no good reason that non-remailers cannot be in on the action! Alice, sending to Bob through Chaum, pretends to be a remailer. That is, she prepares her message to Bob, (encrypted), and adds the Request-Remailing-To: Bob(a)nowhere.org, and signs it. She then observes that the message is too small, so she adds the Cutmarks: header, etc. When Chaum receives the packet, he opens it, removes the cutmarks, and sees a signature he does not know. Chaum then sends a request to pgp-key-server(a)omniscient.gov for the key, and holds the message until he gets it. He then compares the address and name on the key recieved to the message. The signature is good, so he is ready to send the packet to Bob. But Bob can be in on the game as well, since there is no reason that he cannot handle the Cutmarks:, the signature, and the nested encryption. In fact, Alice could include a copy of Bob's key in the message for Chaum to use, after a Recipient-Key: header. Bob can also verify that the message was actually routed through Chaum. If Chaum is concerned that, at some future time, Eve might supeona his key ring in order to demonstrate that Alice and Bob are using Chaum, Chaum can alternately request keys that he does not need from the servers, and delete (older) keys in the ring. In other words, if all the remailers can handle nested pgp packets and cutmarks, we are close to moving all small messages to a standard size. What if the file is too big? If the file is too big, break it in pieces. We need a header, Multipart Message: n of m. Note that since this is assumed to be _inside_ a pgp wrapper, it is secure. The recipient could hold and merge the files as needed. If the message to be forwarded is too big, split and continue. Since the messages are ascii armored, the split/combine protocal is to concatenate. Message parts could be made equal size to minimize the chance of a message barely bumping over the limit as it moves. Of course, Alice could break her message to Bob directly, but we cannot assume that all would do this for us. This also means that if Alice sends a message to Bob in the clear through Chaum, and David, that the message will be encrypted from Chaum to David. Thus, if Eve wants to know which message from Chaum to David is the one from Alice to Bob, (perhaps to know that it is _not_ the message from Frank she is interested in) she knows only that it was one of the messages from Chaum to David after Chaum got the message from Alice, and before David sent it to Bob. While Chaum and David can both read the message, it still provides mixing capabilites inside the remailer net itself, and thus, some protection to Frank. (Who apparently needs the help.) A word on remailer keys: Since pgp uses square-and-multiply for exponentiation, we see that the amount of work needed to sign a message is d(m) * (d(e) + o(e)) where d(m) is the digits of the modulous, d(e) digits of the exponent, and o(e) is the number of ones in e. (I don't remember the technical term.) Since the public key is small, each of the parts of the private key will be large, BUT, there is no reason to assume that we cannot get lucky, and find an m such that d(e) + o(e) is much smaller than expected, (d(m) * 3/2, roughly) thus greatly reducing the system demand of the remailer. In fact, it might be possible to move to 768-bit keys for those that have kept their sizes down in the past. If pgp handles each prime separately, we look for a double-lucky modulous. (And a source of random numbers that does not involve striking keys!) Cypherpunks come up with really neato ideas for somebody ELSE to code... (Sorry guys, but I've not figured out how to get Unix/TCP/etc working on my Amiga...yet...) By the way, the following key id's are showing on the list, but are not on the servers: 27D5B76D 231C7021 34ED427F E37385DD. The first is the auto-signer at bb.hks.net. Also, my modem isn't too thrilled with my connection these days, If the signature fails, look for obvious errors in the text. Sorry. "PGP?" "ITAR!" "Oh, RKBA!" |--------------------------------------------------+ ----------------- 14712B4D 1994/12/26 Nathan H. Zook <nzook(a)bga.com> ) |44B3D866 3D551E2E --------------------------------------------------- |F89222A6 338CDE24/ | ----------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBLym3unmgMs8UcStNAQEAZggAlIsw7HDs4V2GU3DQo7Fx5TiRO6+6mW2B 7Qjn6I+CY1URQQbA3bhPvYoJUt2o3DJ0BCLRej03L/7mdRJmqS3f/1m+juflqPm7 oKlonwpOpFNg2kFSzjE4IpAgIcgi7tHgaLKsIfQ4+QO3s4pJdwAf8VMBHGLyWd2Z h9mNaKgUeKHjhHys2zATm6FNMipcAQgU8sFOl4/YIGyso+cfj4iSXAK4NM4tolDZ uca7l6bQdW5vwRjCJhNmKo+GuSHCY/QczbZZ9R5SkE58LrOVj1MY2x3qcg6gD04X Veddx83tLLsvnh02psRkWH+n0tv7GP8s8cle1ziJcgT96DrQIW6qMw== =t9x5 -----END PGP SIGNATURE-----

1 0

NYT on Target Shimomura
by John Young 17 Dec '03

17 Dec '03

John Markoff writes today on security expert Tsutomu Shimomura, the target of the break-in Markoff wrote about on Monday. For email copy send blank message with subject: TSU_shi Here's an excerpt: Mr. Shimomura, one of the country's most skilled computer security experts, is the person who prompted a Government computer agency to issue a chilling warning on Monday. Unknown intruders, the agency warned, had used a sophisticated break-in technique to steal files from Mr. Shimomura's own well-guarded computer in his home near San Diego. And the stealth and style of the attack indicated that many of the millions of computers connected to the global Internet network could be at risk. There have been at least four other known victims so far, including computers at Loyola University of Chicago, the University of Rochester and Drexel University in Philadelphia. Since Monday, as the F.B.I. has continued to investigate the crime and look for evidence of break-ins elsewhere, Mr. Shimomura has been answering telephone calls and E-mail from government, corporate and university computer administrators seeking advice on how to arm themselves. Between replies, he has been working feverishly to perfect a new type of protective software that would thwart the burglars. Once it is finished, he intends to distribute the software free over the Internet. But more than anything else, Mr. Shimomura, who is 30, wants to help the Government catch the crooks. And while he acknowledges that the thieves were clever, Mr. Shimomura has also uncovered signs of ineptitude that he says will be the intruders' eventual undoing. "Looks like the ankle-biters have learned to read technical manuals," Mr. Shimomura said derisively. "Somebody should teach them some manners. "

1 0

Encrypted Magazine Subscriptions Via E-Mail?
by werewolf＠io.org 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I posed this question in alt.wired. Am I missing something obvious as to why Wired (or magazines in general) don't do this to make subscribing easier? ========================================================================= Why doesn't Wired if it is sooooooo hooked in the online culture have a PGP public key that 'net users could use to send in their credit card numbers for subscriptions? Its a hell of alot easier than mailing in a cheque or money order. And just as safe. Wired could have an electronic "form" you could request for them, to which the public key is attached. You type in the info on the form (ie name, address, phone number, credit card number etc etc) and encrypt it and send it to their e-mail address for subscriptions. Wired then fires off a followup message to the e-mail address from which it came. Obviously if the address bounces, then the subscription is cancelled. Or it can also snailmail a subscription confirmation to the persons adress. Whatever. I just think it would be an easier, on-line way of doing things. They could use Via Crypt, the commercial PGP version, in keeping with the widespread use of PGP on the net. =========================================================================== Personally, I think that IF major enterprises like Wired would use a PGP application in subscriptions it would contribute greatly to the use of PGP awareness on the 'net. And that I thought was one of the cypherpunk items on the agenda. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBLypnMHBFBj7pSNyhAQFFCQf/SWuPYA4oPtm4Q0eoavJ5wPiaIzLZTOwE 0K75TfUKFbCD3r9gKKR/KauwiClERWmOWYsGjL8sI2LYABRlYeONaSdCCxdtbUfa um40Y0fsEo8v7xgxZnIozRHvCCb8TqWCxLTmJ/sg8DRGd5L907eiBmoRRB4lPuqJ Hqmp9NbrTxo06qu3Bm2PdhNaJKQjDtBQ/tMN/yeQI3oHk/eMFuWkByW52PpWTE7q WZfAZKSXuTQtWyHygaH8hkN3Bcwhtno6ncYSaIRXsQ0KvtwwowMGqFi3Mbuza6SV MCoQTLjWFEgmY3WmkKVv0MptUT2ZcrvqtowoxcytARzdXjHJJ+WCNA== =qva1 -----END PGP SIGNATURE-----

1 0

Encrypted Magazine Subscriptions Via E-Mail?
by A5113643667＠attpls.net 17 Dec '03

17 Dec '03

Look at mpj/pub/pgcharge.zip in ftp.csn.ofg. It was designed to do that sort of thing.

1 0

SHA Reference?
by perry＠imsi.com 17 Dec '03

17 Dec '03

Does anyone have the FIPS reference for the latest SHA? I'm writing up the SHA-AH document and I find that I don't have such a reference -- the best I've got is "Proposed Federal Information Processing Standard for Secure Hash Standard", Federal Register, v57, n21, 31 Jan 1992, p. 3747-3749 And I know that this has since been corrected. Perry

5 4

EFF letter to Church of Scientology (FWD)
by adam.philipp＠ties.org 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- From: Stanton McCandlish <mech(a)EFF.ORG> Subject: File 4--EFF Open Letter to Church of Scientology Date: Mon, 23 Jan 1995 18:25:35 -0500 (EST) *****POST FREELY AS APPROPRIATE***** An Open Letter to the Church of Scientology (CoS) and the Net from the Electronic Frontier Foundation (EFF) Over the past several days, the Electronic Frontier Foundation has received several reports from system administrators and others about threats of lawsuits they have received from attorneys for the Church of Scientology and the closely associated Religious Technology Center and Bridge Publications, Inc. These threats apparently are designed to convince sysadmins to discontinue the carriage of certain newsgroups that involve discussions of the Church of Scientology and its teachings, solely on the ground that some of the messages sent through these newsgroups allegedly involve infringements of CoS copyrights or other intellectual property rights. EFF has also received a letter from CoS stating that it would not use the threat of lawsuits against sysadmins if there were any other way to deal with allegedly wrongful messages. EFF believes there is a better way to deal with allegations of wrongful messages -- and that using the threat of litigation to shut down entire newsgroups, or to persuade sysadmins who have not originated any allegedly wrongful messages to shut down newsgroups, is itself highly inappropriate. Electronic communications are in their infancy, and most of the providers are not big corporations with substantial funds to spend on expensive litigation, but rather small operators who cannot afford protracted litigation, even if they are in the right. The mere threat of a lawsuit could result in some sysadmins refusing to carry all sorts of contentious newsgroups simply because they could not afford to put on a case to show that they should not be held responsible for another party's alleged wrong. Rather than attempting through threats of lawsuits to induce innocent sysadmins to censor speech, Church members are encouraged to participate in Usenet discussions to make their views known and refute erroneous posts -- in other words, to answer allegedly wrongful postings with more speech. As U.S. Supreme Court Justice Louis Brandeis articulated in 1927: "If there be time to expose through discussion the falsehood and the fallacies, to avert the evil by the processes of education, the remedy to be applied is more speech, not enforced silence." If CoS claims that a copyright violation or other wrong not remediable by speech has been perpetrated by a particular person, then it should confine its legal threats to that person -- not direct them at an innocent sysadmin who did no more than forward a message, and certainly not at the innocent participants of a newsgroup seeking to exchange views through the newsgroup channel. Even if CoS cannot determine the identity of the person perpetrating an alleged wrong against it, that provides no excuse for cutting off the free flow of information over the net. Events like these show us how important it is to search for new paradigms for handling disputes that arise from time to time. We think the better way to handle this dispute would be to submit the claims and counterclaims to arbitration or mediation, perhaps in a proceeding conducted over the net among the parties to the newsgroup discussion. EFF offers its services to help find an appropriate mediator or arbitrator who would be available online for this purpose. Any party to this dispute that refused to participate in such a forum would, of course, have to explain why it had done so if a case were brought in a more traditional court. Meanwhile, we urge CoS to leave the innocent sysadmins out of their fight. We urge CoS not to take actions designed to cut off the free flow of information through the net. Where there are legitimate disputes about particular messages or the wrongful actions of particular individuals, those can and should be addressed -- perhaps most efficiently through the new communications medium itself. The Electronic Frontier Foundation 1667 K St. NW, Suite 801 Washington DC 20006-1605 USA +1 202 861 7700 (voice) +1 202 861 1258 (fax) +1 202 861 1223 (BBS - 16.8k ZyXEL) +1 202 861 1224 (BBS - 14.4k V.32bis) Internet: ask(a)eff.org Internet fax gate: remote-printer.EFF(a)8.5.2.1.1.6.8.2.0.2.1.tpc.int - -- ---------------------------------+------------------------------------------ |PGP Key available on the keyservers|GJ/CS d H S:+ g? p? au+ a- w+ v++ c++ UL+| | PGP Encrypted E-mail welcome. |UU+ US+ P+ 3 E N++ k- W++ M-- V po- Y++ | | |t++ 5+ jx R G' tv+ b+++ D++ B--- E+++ u**| |SUB ROSA: Confidential, secret, not|h-- f++ r+ n+ y++-- | |for publication. |[ For the geek impaired, a description ] | - ------------------------------------+------------------------------------------ - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLyqzDioZzwIn1bdtAQGingF/TK6A/nChN15OtfVBsFz+arWW7x7n0EQ8 x7Bd8XLvBvvE0r1iU2YHNHPlu1ju6pyq =OsP5 -----END PGP SIGNATURE-----

1 0

Re: Secure (!?) Remailer Net
by Hal 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- From: Nathan Zook <nzook(a)bga.com> > The traffic analysis that we've seen so far mainly just documents > tcmay's "everybody a remailer" concept. If you look, you will notice that > these analyses all assume that Alice and Bob are _not_ remailers > themselves, and for a good reason. If Alice and Bob _are_ remailers, > analysis of the type used here is worthless, especially if Alice and Bob > have a policy of not sending any mail unless they first receive garbage, > and of sending out garbage whenever they get a letter. Realistically, though, everybody is not a remailer, and there are no prospects of everybody becoming a remailer anytime soon, so the analyses of Wei and others are certainly relevant. > HOWEVER, the analysis makes another assumption--that messages are > indistinguishable. This assumption does not correlate, as I understand it, > with the current remailer net. Mixmaster is supposed to do splitting and, I think, padding. I hope to have time to look at it soon. It sounds very good. > First, the message is signed with the sender's key. (More on that > later.) I did not see why this should be done. > Suppose a signed message to be forwarded is smaller than the standard > packet size. The sending remailer adds a Cutmarks: header. At the end of > the message, the cutmark is added, followed by sufficient garbage to fill > out the standard packet size. The message is then pgp'ed to the recipent > _with COMPRESS = OFF_. A better approach IMO is to embed the message length in the encrypted information (as PGP does) and pad with cryptographic random garbage (which PGP could be patched to do). > Upon receipt, the message is decrypted, and its origination can then be > triply verified (at least). From: line, packet size, and PGP signature. > Since the message claims to be from a packeting remailer, the packet size > should be the standard one. The recipient now has the message that was > sent to it. This message is probably itself encrypted, so it can be > handled (almost) as if this message were just received. This includes > stripping the garbage and (probably) decrypting the message to get the > forwarding information. Why does the remailer care where the message came from? What difference does that make? I can see the final recipient caring about the original sender, so a PGP sig makes sense at that level, but why at each hop? > Note that this system would allow the extropian remailer to be > compatible with Matt Ghio's alias system. (Right now, the remailer doesn't > like separate pgp packets, or packets it can't read, or something.) Under > the current system, the precausion is entirely warranted. I don't think so. The problem with Miron's extropy remailer is that it only passes through the contents of a PGP block. For anonymous addresses to work, the (chained,encrypted) address must be in a PGP block which precedes the message body. I don't see how any cutmarks idea would affect this. > To make life even more fun, there is no good reason that non-remailers > cannot be in on the action! Alice, sending to Bob through Chaum, pretends > to be a remailer. That is, she prepares her message to Bob, (encrypted), > and adds the Request-Remailing-To: Bob(a)nowhere.org, and signs it. She > then observes that the message is too small, so she adds the Cutmarks: > header, etc. When Chaum receives the packet, he opens it, removes the > cutmarks, and sees a signature he does not know. Chaum then sends a > request to pgp-key-server(a)omniscient.gov for the key, and holds the message > until he gets it. He then compares the address and name on the key > recieved to the message. The signature is good, so he is ready to send the > packet to Bob. Again, why does the remailer go to all this trouble to verify a signature from Alice? That sig is for Bob! She may not even want to post her public key for everyone; Bob may be the only one who has it. I don't understand why the remailer, which exists to hide identities, is going to such trouble to verify them on its own. > But Bob can be in on the game as well, since there is no > reason that he cannot handle the Cutmarks:, the signature, and the nested > encryption. In fact, Alice could include a copy of Bob's key in the > message for Chaum to use, after a Recipient-Key: header. Alice is the one who should encrypt the message for Bob, not the remailer! Are you suggesting that she should let the remailer see the message contents? > Bob can also > verify that the message was actually routed through Chaum. Why on earth does he care? I really don't see what problem you are solving here with all this checking. > If Chaum is > concerned that, at some future time, Eve might supeona his key ring in > order to demonstrate that Alice and Bob are using Chaum, Chaum can > alternately request keys that he does not need from the servers, and delete > (older) keys in the ring. Eve would be more likely to subpoena Chaum's secret key ring. A public key ring proves nothing. > In other words, if all the remailers can handle nested pgp packets and > cutmarks, we are close to moving all small messages to a standard size. This mostly makes sense (although as I said I prefer simply enhancing the crypto program to take a parameter for output pad size) but I don't see where all the rest of it came from. > What if the file is too big? > > If the file is too big, break it in pieces. We need a header, > Multipart Message: n of m. Note that since this is assumed to be _inside_ > a pgp wrapper, it is secure. The recipient could hold and merge the files > as needed. If the message to be forwarded is too big, split and continue. > Since the messages are ascii armored, the split/combine protocal is to > concatenate. Message parts could be made equal size to minimize the chance > of a message barely bumping over the limit as it moves. Of course, Alice > could break her message to Bob directly, but we cannot assume that all > would do this for us. I believe Mixmaster provides a client mode to do this. I prefer putting more functionality in the hands of the users and not relying on kindly old Uncle Remailer to do it for you. > This also means that if Alice sends a message to Bob in the clear > through Chaum, and David, that the message will be encrypted from Chaum to > David. Thus, if Eve wants to know which message from Chaum to David is the > one from Alice to Bob, (perhaps to know that it is _not_ the message from > Frank she is interested in) she knows only that it was one of the messages > from Chaum to David after Chaum got the message from Alice, and before > David sent it to Bob. While Chaum and David can both read the message, it > still provides mixing capabilites inside the remailer net itself, and thus, > some protection to Frank. (Who apparently needs the help.) This is a commonly made suggestion, but philosophically I am opposed. We got into this fix (lack of privacy) by letting people rely on others to do things for them. It's time for people to take responsibility on their own. The kind of thing you are suggesting provides the illusion of privacy. Never trust remailer operators! > A word on remailer keys: Since pgp uses square-and-multiply for > exponentiation, we see that the amount of work needed to sign a message is > d(m) * (d(e) + o(e)) where d(m) is the digits of the modulous, d(e) digits > of the exponent, and o(e) is the number of ones in e. (I don't remember > the technical term.) Since the public key is small, each of the parts of > the private key will be large, BUT, there is no reason to assume that we > cannot get lucky, and find an m such that d(e) + o(e) is much smaller than > expected, (d(m) * 3/2, roughly) thus greatly reducing the system demand of > the remailer. In fact, it might be possible to move to 768-bit keys for > those that have kept their sizes down in the past. If pgp handles each > prime separately, we look for a double-lucky modulous. (And a source of > random numbers that does not involve striking keys!) Since the secret key d is effectively a random number from 0 to m, you would have to create, say, 1000 key pairs to have a good chance of finding a d that was as much as 10 bits shorter than m. Then o(d) might be 5 bits shorter. So you'd be done from 768+384 to 758+379 or about a 1% reduction in time. And it will take a while to generate 1000 keys. To get a 2% reduction you would have to generate 1000000 keys. I hope you have a lot of time on your hands. I'm sorry to have been so negative, but this message is part of a long tradition advocating putting more responsibility into the remailer net. I strongly feel that better solutions put power into the users' hands. I oppose centralized solutions. Hal -----BEGIN PGP SIGNATURE----- Version: 2.6 iQBVAwUBLyqgIRnMLJtOy9MBAQF1YAH/Yu68NkN0NnbCTfxDoGm4oc6lCs+dCp6V pmjinw8zdwBM133eAaaorjtW0KhEvBNMGQTFHeiGJTOt94bE8ELB5g== =owIt -----END PGP SIGNATURE-----

1 0

Re: NNTP archives
by Todd Masco 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Michael Froomkin writes: > I would like to use it to read c'punks in netscape. what do I put in > the box which says NTTP news reader? just putting the machine name seems > to produce no result... Not knowing netscape, I couldn't tell you. The newsgroup name should probably be in there, tho: it's hks.lists.cypherpunks on nntp.hks.net. The URL might be something like "nntp://nntp.hks.net/hks/lists/cypherpunks" or "nntp://nntp.hks.net/hks.lists.cypherpunks", but I'm just guessing. - -- Todd Masco | "If we don't make utter fools of ourselves from time to time, cactus(a)hks.net | we grow smug - that is, we do not grow at all." - T. Peters Cactus' Homepage - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLysYkSoZzwIn1bdtAQGEXgF/QzfXQmikP3AGwXBjJaUPPXPDpmy8dlVM NDcjQbtG125EIoBXGLa9GR6dfrp4HhBy =fGHU -----END PGP SIGNATURE-----

2 1