December 2003 - cypherpunks-legacy

NNTP archives
by Todd Masco 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- If anybody ever actually uses the cypherpunks archives via NNTP on hks.net, please let me know immediately (we don't log). I'm probably going to be putting a reasonable expire time on the group and archive the articles at expire time: if people use it, I can set up a "cypherpunks archive group" for NNTP access. This won't affect folks who use the NNTP access to read cypherpunks normally: I'll probably set the expire time to something like a month. -- Todd - --- [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 iQBFAwUBLyrP8ioZzwIn1bdtAQF0VQF9HSyCQDkeUMiso29z3TOJY4cuj6EQdjq1 JpRBSoM35ZOfKcTQ2qSIvn6WvLk56pZD =RAyu -----END PGP SIGNATURE-----

2 1

Re: Encrypted Magazine Subscriptions Via E-Mail?
by Michael Sattler 17 Dec '03

17 Dec '03

>>>why Wired ... don't [use PGP] to make subscribing easier? >> >> Because if you saw the low-tech state of the Wired office... > >Yup, too busy to automate. After all, if they took orders by email, >they wouldn't need manual intervention. It all makes perfect >sense. Why spend effort to lower the amount of time their staff need >to spend on manual tasks? Makes more sense just to remain buried. That a bunch of their staff is the minimum-wage "gee, look at my Mac" crowd might have something to do with it. I was amazed to find out that there really are two sides to Wired: the professional computer geeks (eg. Negroponte) and the professional get-a-magazine-out geeks, and the twain never seem to meet. -----------------------------------------------------------------------+ Michael Sattler <msattler(a)jungle.com> San Francisco, California | Digital Jungle Consulting Services http://www.jungle.com/msattler/ | | And so these men of Indostan/ disputed long and loud/ each in his own | opinion/ exceeding stiff and strong/ though each was partly right/ and | all were in the wrong! - John Godfrey Saxe |

1 0

No Subject
by norm＠netcom.com 17 Dec '03

17 Dec '03

Protocols for a Data Bank The purpose of a data bank is to store large bodies of information for long periods of time. I suggest here some protocols and contracts for a data bank and its customers. We then discuss risks, incentives and stratification of the data storage industry. These ideas implicitly rely on several types of cryptography-- public key, secure hash, symmetric ciphers and blind signatures. To explain these technologies here would substantially obscure the presentation for those who know of such things and help very little for those who don't. Here are several transactions that a data bank engages in. Acquire data: A client anonymously sends a collection of data along with funds sufficient to warrant the bank's holding the data for a few days and computing its secure hash. The bank knows the data only by its secure hash. Selling Hat Checks: The bank will sell a hat check to anyone who will pay a negotiated price. The hat check specifies the secure hash of the data, the penalty to be paid upon failure to produce the data, and the cost of redeeming the data. The hat check is signed blindly by the bank and is a bearer instrument. Any holder of a hat check can present the check along with the redemption fee and demand the data. The data bank must then either produce the data or pay the penalty to the holder of the hat check. A particular hat check is canceled whenever the bank pays the penalty like a spent Chaum DigiCash note. The bank can sell multiple hat checks for the same data. Different hat checks for the same data may specify different penalties. Sell a copy of an acquisition: Any one can request a piece of data identified only by its secure hash. The bank is free to sell a copy of the data to anyone with the secure hash. The bank sets the price. Publish index: The bank can publish its list of hashes. (This makes data hunters possible.) Cancel a hat check: A holder of a hat check may sell it back to the bank at a negotiated price thus releasing the bank from the threat of paying a penalty in the future. This also allows the bank to retrieve the physical storage where the data is stored if it is sure that it has not sold other hat checks for the data. The hat check may specify expiration dates, cancellation terms etc. The bank is explicitly permitted to disseminate the data and may well do so to lay-off risks. In this sense a data bank is like in insurance company that spreads and shares risks. A hat check may be viewed as a life insurance policy for the data. Risks Dividing trust may be done by agreeing on a notary. Upon redemption, for instance, a trusted notary might examine the hat check, accept the payment specified therein from the client, pass over the data on its way from the bank to the client while computing the secure hash, and if the secure hash matches that in the hat check, deliver the payment to the bank. The notary need not have long term financial stability as must the bank. Brokers may have an interface similar to a bank. They return baskets of hat checks. This reduces the risk to the client that one of the data banks will fail financially and be unable to pay the penalty. The broker need not be financially stable. Data Hunters can engage in knowing who has what data. Given a hash they can tell you what banks have the data. This would presumably require a new protocol with the bank. This might be the ultimate URL or URI server. Inflation can damage incentives. Hat checks might be denominated in gold or currency baskets or what ever. RSA modulus size is critical for long term contacts. 2K bits of modulus or more may be warranted. Example I can imagine the Getty Museum digitizing its Rembrandts and storing the results in a data bank. The data might be insured for $100,000,000. The bank would disseminate the data to increase security and lower its risk. The museum would probably encrypt the data and share the key and hash ala Shamir for safe keeping. The museum would not share the hat check because it wants to be the one paid upon default. Incentives A data bank, or any other player, may find that keeping data profitable beyond the point of any outstanding hat checks. It can make money by supplying copies of the data in return for a fee plus secure hash. Indeed new hat checks may be sold after the last had expired. Data banks thus have an incentive to disseminate their list of holdings in the form of hashes, as input to bounty hunters. Design Considerations It may seem strange that the data bank does is willing to sell data to who ever will pay. I suggest that because it is so easy to encipher the data and not have to trust the bank. You can distribute the key thru what ever channels you transmit the secure hash of the data. Note that bank clients are always anonymous. Data is never held for some known person. Data may be held solely for speculation. The purpose of the penalty is to motivate the bank to keep data for which there is no reason to forecast sales revenue. The Bank's State Logically the bank can perform all of these transactions by merely keeping the unordered set of acquisitions. It is practically necessary to index these by their secure hash but this can be rebuilt on demand. It must keep canceled hat checks lest it become liable to extra penalties. The bank need not keep records of hat checks that it has sold unless it wants to know when it can delete acquisitions. It may want to keep marketing information to know when acquisitions are worth keeping merely to sell copies of.

3 2

Re: Remailer Specs
by Jaeson.M.Engle＠josaiah.sewanee.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >ftp myriad.pc.cc.cmu.edu /pub/remailer >ftp cs.cmu.edu /afs/andrew.cmu.edu/usr12/mg5n/public/remailer Thanks for the sites, but after looking at them, I can say they will NOT build in THINK C. But, They might help me figure out what to do with Remailer (the Mac version I'm building). Also, I'm not writing mine in C, I'm doing it in Pascal, because 1) I have the TCP libraries for it and 2) I don't now C very well at all. -----BEGIN PGP SIGNATURE----- Version: 2.6ui iQCVAgUBLyrN9UiLvmPjc4XdAQHeuAP/djk9XYKP3YmfdluJN8hMkNajetRAjKVK i0AvDyMUjN0fs5MXfez6v8tBx65qeWY0WIi8O53O5UzS7JOtiKNF4uLbDfJZiYRW okgdCutn6l4nHxz7MiNNCo1TXvMvPyYffy+cdPuRwX7IzfxdfaVHqD14e/x+S3Cs cy9zpuCnho0= =cDiR -----END PGP SIGNATURE----- aka: (-: Jaeson M. Engle || jme(a)josaiah.sewanee.edu :-) (-: www server: http://josaiah.sewanee.edu/ :-) (-: It's February 8th! IT'S TIME!!! Ask me for details!:-) (-: Finger 'jme(a)josaiah.sewanee.edu' for my Public :-) PGP block.

1 0

Re: Encrypted Magazine Subscriptions Via E-Mail?
by Michael Sattler 17 Dec '03

17 Dec '03

>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? Because if you saw the low-tech state of the Wired office you'd understand; they're at capacity just opening envelopes and manually entering names and addresses off the checques. Visit them whenever you're in downtown San Francisco. -----------------------------------------------------------------------+ Michael Sattler <msattler(a)jungle.com> San Francisco, California | Digital Jungle Consulting Services http://www.jungle.com/msattler/ | | And so these men of Indostan/ disputed long and loud/ each in his own | opinion/ exceeding stiff and strong/ though each was partly right/ and | all were in the wrong! - John Godfrey Saxe |

2 1

Again, where to upload code?
by Robert Rothenberg 17 Dec '03

17 Dec '03

I posted this query recently with no replies, then again it's not been "duped" back to my account either, so I'm not sure if it went through. I've written some fingerprinting code for MD4, MD5, SHA, RIPE-MD and HAVAL in assembly language for 386 machiens and would like to make it available, not sure of an ftp-site... pref. ITAR-safe or are those algorithms not covered under it?

3 4

Re: Protocols for a Data Bank
by norm＠netcom.com 17 Dec '03

17 Dec '03

At 4:39 PM 1/28/95, jpp(a)markv.com wrote: >> Date: Sat, 28 Jan 1995 15:49:13 -0800 >> From: norm(a)netcom.com (Norman Hardy) >> [...] >> Selling Hat Checks: The bank will sell a hat check to anyone who will pay a >> negotiated price. The hat check specifies the secure hash of the data, the >> penalty to be paid upon failure to produce the data, and the cost of >> redeeming the data. The hat check is signed blindly by the bank and is a > ^^^^^^^ >> bearer instrument. Any holder of a hat check can present the check along >> with the redemption fee and demand the data. > > Why in the world would the bank want to sign blindly? The bank >would be undertaking an obligation of an unknown nature. Would you >sign a blank check? A blank contract? I wouldn't. .... You are right. I forgot that the blind signer knows nothing of what we signs. The protocol requirements seem clear but I lack a protocol. I think I have a fix but I will be more careful before I post.

1 0

Re: MS Office NT
by Chris Claborne 17 Dec '03

17 Dec '03

Re: Office for NT, kahuna(a)fc.net writes: >I installed it yesterday, and played with it for about 5 minutes. ... I >wasn't able to save more than 8.3 in powerpoint, but Word did recognize this >feature, and I saved a file as 13456789012345.doc without a porblem. ...yay? This is one of the major features in NT, why the hell would they bother shipping it if it didn't support 255 char names??? ... __o .. `\<, Chris.Claborne@SanDiegoCA.ATTGIS.COM...(_)/(_). CI$: 76340.2422 --------------------------------------------------------------------------- PGP Pub Key fingerprint = A8 FA 55 92 23 20 72 69 52 AB 64 CC C7 D9 4F CA Available on any Pub Key server. PGP encrypted mail welcome.

1 0

Re: Philadelphia CyberCrime
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

> Heard on the news today that they arrested a plumber and are holding > him in lieu of $50,000 bail. > He used a PC to crack into the phone system and set up 'Ultra' call > forwarding which forwarded calls to other plumbers businesses to his. > He then took the calls and told the callers that his company was > covering for the one they actually called. The irony is that the original dial telephone switch was invented to prevent this kind of problem, by a Kansas City undertaker named Strowger who thought his competitor was bribing the phone operators to redirect business, and wanted to get the humans out of the loop. Bill

1 0

Re: Even more unix holy wars.
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

(Undeleting files is a security issue that's still got _some_ tenuous connection to cypherpunks :-) > How would I go around undeleting a file under Unix? It's easy on the > Mac. Doing it under DOS is ugly, but it works. But with unix, there > is no way. Sure there is. Multiple ways, depending on your objectives. All with different syntax, since this _is_ Unix :-) The simple way, implemented by lots of universities, is a fake delete, which actually renames or moves the file to some hidden location instead of deleting it; the undelete program renames it back, and there's a space-scavenger that genuinely deletes old rename-deleted files after a few days. Undeletes after that consist of getting the file from tape backup. While the System V filesystem doesn't save enough pointers to guarantee getting complete files back from deletion (if the space they used hasn't been reused already), there have been undeletes that scrounge up the newest n blocks off the free list. Of course, those were the first blocks to get used in new files, so it wasn't much use in a multi-user system, but it was there. Besides, disk drives on multi-user machines are always >95% full, and often over 98% full, so deleted files are fair game anyway... Bill

1 0

Tabloid TV coverage of pedophiles using BBS - with feedback #s
by craig＠passport.ca 17 Dec '03

17 Dec '03

On TV as I am hacking here, is some Tabloid Trash called "The Crusaders", which I would have definitely flipped off once the late movie was over, if it hadn't been for these 'intriguing' sound bites they ran: "Your children may fall victim to pedophiles in the safety of their own bedroom! And the Crusaders are out to stop them..." "The newest high tech scheme sex offenders use on your children, and how you can stop it! Child molestors on your home computer!" I am staying tuned through stories on adoption reunions and nursing home neglect, just to see how to protect my children... (20 min. later) They show a lot of kids using computers, then modems and BBS systems. They mentioned the usefulness of nets for 'homework' and games, but: "We recently tapped into a bulletin board containing hordes of files, from lingerie shots to shocking pictures... that show anything goes." "10% of the adult population on the boards are looking to solicit children, says a police chief in (Amish country in PA)." >From there I expected a lot worse, but actually it got a whole lot better: "Talk to your kids, and don't use the computer as a babysitter... parents need to know there are dangerous people out there..." An FBI expert said that the 'best way' to combat pedophiles was to educate police how computers work, and second to make people aware without implying that a computer is a bad thing. He said he thought teenagers would seek out sexually explicit material and that current 'protections' (e.g. warnings on explicit files) were inadequate. [What this had to do with pedophilia he didn't say. All the kids interviewed had been solicited on other premises... e.g. one had been lured to a pedophile's home to install a non-existent net. It seems that none of the pedophiles had lured kids with sexual materials but no point was made of this. They indirectly implied a relationship.] Other advice offered was to keep kids from offering personal information on the BBSs, and to accompany your child the first time they go to meet someone they met on a BBS. There was no brainless advocacy of censorship, nor a call to ban anoynimity (although the police chief in PA said he thought pedophiles were 'emboldened' by the 'anonymous computer environment' which is probably more or less true), even though they talked directly to one (male) kid who'd actually been raped. This was exploitative, but it was also real, and it was just stark enough to make the point. No hysteria, the kid was calm. This was the kid who had been lured to install the net. Given that they actually gave practical advice that might actually work and was not generally hysterical, it was about as good as one might expect. They fell short of saying that the pedophilia was isolated and unrelated to most of the graphic material on the boards. The "10%" was the only number they offered. Apparently they could find only 2 convictions for BBS-related pedo- philia in the US. Actually it seemed to me that the most objectionable things was this crazy 10% estimate, which might mean 10% of the adults on purely porn-oriented BBS sites, but it was left implied that 10% of *all* adult BBS/network users were trying to lure children into sexual situations! After that the most objectionable thing was the hysterical tag lines which are mandatory on Tabloid TV. They didn't seem to be written by the reporter. Reporter's name was Howard Thompson, editor was Ralph Herman Fax number for the show is 818-841-6500. Transcripts of the show are available for $6 at 1-800-777-T-E-X-T (Burrelle) Craig

1 0

Heavy Weather
by bart＠netcom.com 17 Dec '03

17 Dec '03

Just finished reading Bruce Sterling's newest novel. I enjoyed it and suggest it will interest hard sci-fi fans. Its a very much post cypherpunk world he writes about, e.g.: " ... It all had to do with unbreakable encryption, digital authentification, anonymous remailing, and network untraceability. These were all computer networking techniques that had once been considered very odd and naughty. They were also so elementary to do, that once they were in place, they couldn't be stopped without tearing the whole Net down. Of course once these techniques were in place, they conclusively destroyed the ability of governments to control the flow of electronic funds, anywhere, anytime, for any purpose. As it happened, this process had pretty much destroyed any human control at all over the modern electronic economy. ..."

1 0

Re: Secure (?) Remailer-net
by Nathan Zook 17 Dec '03

17 Dec '03

First, in case you all haven't noticed, I am seriously async here. Sorry that I sometimes seem to alternately really miss or firmly grasp the obvious. From: Hal <hfinney(a)shell.portal.com> >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. > Yes, but... Presumably those who feel that they need remailer and are willing to put out the effort to use one might also feel that they need a higher level of security. I suppose that my remark might be more accurately: "mainly just documents the superiority of the 'everybody a remailer' concept for TA purposes." Of course, if the remailer-in-a-box isn't much harder to use than PGP was two years ago, then maybe "everybody" will... >> 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. > No? Isn't the InterNet currently under a serious packet-spoofing attack? Don't we expect Eve to be AKA NSA? If I run a remailer, I want to know that I'm not being lied to in the process. That insistance might just save the legal butt of the guy being spoofed, by demonstrating that the packet did not in fact originate from the remailer. Just because remailers are legal doesn't mean that the govt won't still try to shut them down... >> 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). > In this instance garbage is defined as cryptographic random. If the message has a length indicator in the clear, then Eve can read it. (Remember, Eve runs snakoil(a)nsa.gov.) Therefore, such a marker has to be _inside_ the wrapper. Given this, (that everything is PGP wrapped) there is always the chance that PGP will compress a message, even one with cryptographically strong bits in the end. While compression can improve protection, it is not likely to do so if the original message was already PGPed. Only "clear" messages, therefore, risk losing protection. As you note, such messages don't deserve as much help as opaque ones. >> 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? > See below. Basically, we don't want to be spoofed ourselves. Bad security for our systems. Admittedly, this is probably not a real problem today. See my sig. >> 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. > Sure it does. If the whole thing is inside a PGP wrapper, then it is secure. "Only passing through the contents of a PGP block" is currently a security measure that makes good sense. But if you have two separate blocks _inside_ an outer wrapper, you already have full security. Strip off the outside, find two more wrappers. Strip the first, get remailing instructions. Attempt to strip the second. Fail. Attach second wrapper to forwarded message. Full security. >> 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. > Alice signs her messages to the remailer because she doesn't want anyone spoofing her use of the remailer. If a message goes in at 00:00:00.01, 1 Jan, 2001 that is "From:" her, it is FROM her. More of the same reasoning. This key doesn't have to have anything to do with the key she uses with Bob. It is the one that she wants the general public to use for HER. >> 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? > NoNoNoNoNoNoNo! ;) The key she includes is Bob's public key. The same one that is on the key servers. This is so the message can be standard sized for the final trip to Bob. As we have noted, messages are quite vulnerable at this stage. If every message that Bob gets from Chaum "looks the same", who is to say which is which? >> 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. > Suppose you were using the remailer net. Would you care to know that someone was spoofing a node? I would. It would indicate that someone is either hacking the system (probably no big deal), or that someone might be shadowing a remailer. That is, the remailer is no longer secure. Spoofing is a big deal on the net generally, and if we start being used a lot, we will have to deal with it as well. Why not now? >> 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. > Ever hear of "guilt by association"? See my sig. >> 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. > If the message length is world readable, it is world readable. The super- wrapping makes sure that it is not. It also makes clear messages indistinguishable from opaque ones inside the net. See below. >> 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. > Yes, but... Breaking an overly large file makes it indistinguishable from standard sized ones. See below. >> 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! > below: (Couldn't resist ;-) The point of "Uncling" insecure messages has nothing to do with improving the security of the insecure messages. I agree, as a good member of the Libertarian-Christian wing of the Republican party (NYET!) that these folks deserve snakeoil. But we're _not_ doing it for them. We're doing it for Frank, who does everything right. If Eve doesn't know anything we don't have to tell her about Alice's messages, then she gains no free negative information about Frank's. Judging by the remailer stats, there are a lot of messages traveling "in the clear." These messages currently do nothing for those of us that do things right. It's time that they do. So I'm not encouraging Alice to trust Chaum. I'm encouraging Chaum to give Frank all the help he can. Frank, who just blew the whistle on the "Justice" Department. Frank, who does everything right, and might even stand out because he does. Frank, the guy we are all really doing this for. To put it another way, if we really don't want centralized solutions, if no one should trust any of us, if the users should provide all of their own cover, then why are you running a remailer? Let them telnet to port 25. Let them do whatever. Maybe that was too harsh. I don't advocate holding people's hands. What I _do_ want to do is to provide the best service that we can. Note that from earlier and current work (thanks, guys!), we see that even if the remailer net itself is completely secure, the sender and reciever can still be traced with near-exponential speed. So our systems provide a delay in tracking of a couple of months. Big deal. The TLAs routinely take years to build a serious case. If we are going to be any help to folks that _really_ need it, we have to extend the black box all the way to people outside the net. As you said, not everyone will be remailers anytime soon. So if I am trusting a remailer net, wouldn't it be nice to know that no one but the ends can even think about compromising the message? (Until one of them does.) Wouldn't it be nice to know if the ends were being shadowed? -- As for signing intra-net traffic, suppose, at some time in the future, we agree that we do, in fact, need them. Will it be easier or harder to implement then? >> 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. > Actually, I did make this error when I first considered this, also. We do not hope for a short key. In fact, we know that the key will be long, when viewed in parts, as I now believe that it is. We hope that the key will be 0 rich. The chance of this just comes off of the binomial distribution, which is not nearly so bad. Sorry. And a, say, 10% improvement above expected allows a cooresponding length increase--which does something _more_ than improve security by 10% ;) >I'm sorry to have been so negative, Not at all. We're not talking about anything as important as unix vs windows. You must be a better person than I. I usually love shooting down lame-brain ideas. ;-) > 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 See below. I mean above. I mean below:. This is not, IMHO, a centralized solution, as I see it. As I see it, this is a _minimal_ solution to the problem that today, our net is laughably easy to crack. I assume that anyone that wants to spoof will have a reason to do so. I assume that if the NSA/FBI/CIA/DEA/DIA/ATF wants to trace a message, they will bring the full power of their systems to bear, including reading this list. Anyone else? Tim's usually pretty good at panning me. :-P :-) Nathan --- Cypherpunk's precausions today look hopelessly paranoid. Until you consider that their precausions from yesterday are now considered hopelessly quaint. --- "PGP?" "ITAR!" "Oh, RKBA!" |--------------------------------------------------+ ----------------- 14712B4D 1994/12/26 Nathan H. Zook <nzook(a)bga.com> ) |44B3D866 3D551E2E --------------------------------------------------- |F89222A6 338CDE24/ | -----------------

1 0

Always after me lucky primes...
by Nathan Zook 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- So Hal thinks that it would take a lot of work to get a private exponent that is even marginally short? Let n be the random number generated by keystrokes. Let m be n mod (0x10001 * 8 * 9 * 25 * 49). Let s be m mod 0x10001. Let n1 be n + 0x10000 - s. Let t be m + 0x10000 - s mod 8 * 9 * 25 * 49. Let t2 be m mod 8, t3 be m mod 9, t5 be m mod 25, t7 be m mod 49. Let n2 be n1 / 2, n3 be n1 / 3, n4 be n1 / 4, ... n7 be n1/7. using t's, determine if n1 is a mult of 2, 3, 5, 7. if so, check appropriate element of {n2, n3, n4, n5, n6, n7} for primeness. (there may not be one). if not check n1. EndELSE Loop: Determine if some element of {n1,...n7} is prime If so, let d = (n1 + 1 ) / 0x10001 [equiv: n1/0x10001 + 1] Let k = 0's in d. [check previous flamage for best method] If k is below threshhold, save and exit. (you may wish to ensure that k is _above_ a certain threshhold...) EndIF EndIF Let n1 += 0x10001 using t's, determine if n1 is a mult of 2, 3, 5, 7. if so, increment the appropriate elements of {n2, ... n7}. also, check appropriate element of {n2, n3, n4, n5, n6, n7} for primeness. (there may not be one). if not check n1. EndELSE EndLoop: :-D Cypherpunks write algorithms, and argue about operating systems. Clearly, if you wish to be a stickler about the number of digits that you end up with, you wouldn't use n2 through n7. The t's, however, or some version thereof, would speed the checking noticably. Nathan I hearby provide notice of claim to all intelectual copyrights relating to the above algorithm(s) against all entities using the algorithms for commercial purposes, specifically against PKP, and Viacrypt, their assignees, and anyone claiming the devolution of their patents. For non- commerical use, including inclusion into PGP (tm) packages that will be distributed free of charge, Fred Fish and similiar distributions, I release all claims, providing a copy of this notice is included. "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 iQEVAwUBLyu1SHmgMs8UcStNAQGXjQgAmr0PN2RbLwM4IN15YdQhwD/IvYFylTCS naRCyvqjgzdsPROZAhZKP5eoVbMn6xWmwRhxfplGTCKf3YMRu9FSQHEc7ekL7QQw mxRvGC2WOMkMuIRXt0DKu6keof9XwWUL2voni+eKme50sppf0ETmLu1outjcCyR6 bJD0XyUxbBPUKpP4prQSc/kT7XVt+wGJVRZtkN1F+43roLRLZYzzjItuR4gqUQ8D WpC8CDfQTCLb0GDKNC+ZirNdSKGg2t3XnHC2gQpXRLRykPlYG9SpBDm+VuIXV0vl dALZLV9UtNyulmOYqqkCqBmAavDQDuTjbRnELLsELLSSZrOIiKQ+Sw== =CaQ6 -----END PGP SIGNATURE-----

1 0

Re: Protocols for a Data Bank
by norm＠netcom.com 17 Dec '03

17 Dec '03

This is a corrected version. I was wrong to suggest that the protocol was similar to blinded signatures. Protocols for a Data Bank The purpose of a data bank is to store large bodies of information for long periods of time. I suggest here some protocols and contracts for a data bank and its customers. We then discuss risks, incentives and stratification of the data storage industry. Here are several transactions that a data bank engages in. Acquire data: A client anonymously sends a collection of data along with funds sufficient to warrant the bank's computing its secure hash and holding the data for a few days. The bank knows the data only by its secure hash. Selling (Hat) Checks: The bank will sell a check to anyone who will pay a negotiated price. The check specifies the secure hash of the data, the cost of redeeming the data, and the penalty to be paid by the bank upon failure to produce the data. A client proposes the details of a check as follows: Send (SH(acquisition), redemption price, penalty, SH(Secret)) to the bank along with a proposed price. 'Secret' is a secret random number chosen by the client for this negotiation. If the bank agrees it signs and trades the signed message for the proposed price, or it may propose another price. The signed message is the check and is a bearer instrument. Redeem data: Any holder of a check can present the check along with the secret, the redemption fee and demand the data. The data bank must then either produce the data or pay the penalty to the holder of the check. A particular check is canceled whenever the bank pays the penalty like a spent Chaum DigiCash note. The bank can sell multiple checks for the same data. Different checks for the same data may specify different penalties. Sell a copy of an acquisition: Any one can request a piece of data identified only by its secure hash. The bank is free to sell a copy of the data to anyone with the secure hash. The bank sets the price. Publish index: The bank can publish its list of hashes. (This makes data hunters possible.) Cancel a check: A holder of a check may sell it back to the bank at a negotiated price thus releasing the bank from the risk of paying a penalty in the future. This also allows the bank to retrieve the physical storage where the data is stored if it is sure that it has not sold other checks for the data. Checks may specify expiration dates, cancellation terms etc. The bank is explicitly permitted to disseminate the data and may well do so to lay-off and reduce risks. In this sense a data bank is like an insurance company that spreads and shares risks. A check may be viewed as a life insurance policy for the data. Risks Trust may be divided by agreeing on a notary. Upon redemption the bank examines the check to see if it has been canceled. If it knows the Secret which produced the SH(Secret) of the check, the check is canceled. Otherwise a mutually trusted notary takes the check, accepts the redemption payment specified therein from the client, passes over the data on its way from the bank to the client while computing the secure hash. If the secure hash matches that in the check the notary delivers the payment to the bank. If the hash fails to match, the transaction is aborted and a penalty transaction begins. The bank delivers the penalty to the notary and the client delivers the secret to the notary. If the hash of the secret matches that in the check then the notary delivers the secret to the bank (canceling the check) and the penalty amount to the client. The notary need not have long term financial stability as must the bank. Brokers may have an interface similar to a bank. They return baskets of checks. This reduces the risk to the client that one of the data banks will fail financially and be unable to pay the penalty. The broker need not be financially stable. Data Hunters engage in knowing who has what data. Given a hash they can tell you what banks have the data. This might be the ultimate URL or URI server. Inflation can damage incentives. Checks might be denominated in gold or currency baskets or what ever. RSA modulus size is critical for long term contacts. 2K bits of modulus or more may be warranted. Example I can imagine the Getty Museum digitizing its Rembrandts and storing the results in a data bank. The data might be insured for $10,000,000. The bank would disseminate the data to increase security and lower its risk. The museum would probably encrypt the data and share the key and hash ala Shamir for safe keeping. The museum would not share the check because it wants to be the one paid upon default. Incentives A data bank, or any other player, may find that keeping data profitable beyond the point of any outstanding checks. It can make money by selling copies of the data. Data banks thus have an incentive to disseminate their list of holdings in the form of hashes, to support data hunters. Design Considerations It may seem strange that the data bank does is willing to sell data to who ever will pay. I suggest this because it is easy to encipher the data and not have to trust the bank. You can distribute the key thru what ever channels you transmit the secure hash of the data. Note that bank clients are always anonymous. Data is never held for some known person. Data may be held solely for speculation. The purpose of the penalty is to motivate the bank to keep data for which there is no reason to forecast sales revenue. Unlike Chaum bank notes, the issuance of a hat check may be associated with the redemption. The depositing of data and hat check issuance, however, may be anonymous. Data redemption may be anonymous but collecting a substantial penalty may be difficult to arrange anonymously. Managing anonymous transactions is a difficult but orthogonal issue. The Bank's State Logically the bank can perform all of these transactions by merely keeping the unordered set of acquisitions. It is practically necessary to index these by their secure hash but this can be rebuilt from the acquisitions themselves. When it looses data it must keep canceled checks to avoid extra penalties. The bank need not keep records of checks that it has sold unless it wants to know when it can delete acquisitions. It may want to keep marketing information to know when acquisitions are worth keeping merely to sell copies of. The bank will need to keep records of the checks that it issues for financial auditors (to satisfy owners of the bank.)

1 0

Re: Data Bank
by norm＠netcom.com 17 Dec '03

17 Dec '03

My second posting crossed in the mail with Eric's notes. At 9:09 AM 1/29/95, Eric Hughes wrote: > From: norm(a)netcom.com (Norman Hardy) .... > > The hat check is signed blindly by the bank and is a > bearer instrument. > >There's no need to have it signed blind. A blind signature is useful >when two parties have some persistent relationship with the >intermediary; when they don't have identity, there's no need for >blinding. .... > We therefore conclude that there's no need for a blind >signature here at all. Yes, I was confused. jpp(a)markv.com had yet other valid objections. .... > Cancel a hat check: A holder of a hat check may sell it back to the bank at > a negotiated price thus releasing the bank from the threat of paying a > penalty in the future. > >This cancellation can't be done well. Remember that the parties are >remaining anonymous to the data bank. In order to release the data >bank of an obligation, some party would have to make some signed >statement releasing the data bank from the obligation. But making a >signature reveals identity, perforce. I have a novel sense of cancelation in mind. The check is canceled by the mere fact that the bank knows the Secret that produced the SH(Secret) in the check. The bank need not acquire or maintain a signed check revocation. This is sort of like Chaum's spent bills. This requires the client to trust the bank during the penalty transaction or to require escrow service. I have modified the original to describe this better. > >Furthermore the retrieval note is a bearer instrument, but it's a >_digital_ bearer instrument, which means you can't simply give the >note back to the data bank. There's no piece of paper to return. >Once the note is out there, it's out there forever. There can be lots >and lots of bearers. Which one of them gets to release the data bank >of its obligation? .... Any bearer. Just as any bearer of a Chaum bill can spend it. Only he who spends it first, can spend it. Disseminate your hat checks carefully. That is another reason that Getty, in the example, holds the hat check carefully. .... > The hat check may specify expiration dates, cancellation terms etc. > >The retrieval note very well should specify an expiration date, since >otherwise the data bank has specified an obligation in perpetuity. A >perpetual obligation is much less stable than a fixed-time one. The >value to the data bank of disappearance grows larger as the cost of >storing the data increases. No new external revenue is coming in (by >definition -- otherwise you've got a renewable agreement, which is >different) and all you've got is costs. So there becomes little >reason not to simply abscond with the assets and deny any outstanding >obligations. > >A customer, therefore, would be wise not to deal with a data bank >which signed perpetual obligations. If a customer wants indefinitely >long storage, the best way to do this is with a set of interlocking >obligations with mutually ignorant parties. .... Good points. I anticipate more complex broker services here. I like the idea of a penalty for delay in retrieving the data aside from penalty for loosing the data. This may be strategic in the bank's arranging for the storage and retrieval from other sites and banks. Thanks. I will try to produce an emmended version thru ftp soon.

1 0

Why encrypt intra-remailernet.
by Nathan Zook 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Lance Cottrell <lcottrell(a)popmail.ucsd.edu> >I agree completely that messages should be encrypted between remailers. >This does raise the issue of keeping a database of all other remailers at >each remailer. Lets settle for encrypting to the next remailer most of the >time. Well, actually, I'm suggesting a database that includes all remailers and all selected users. ICT: in order to beat TA, first or last remailers are going to _have_ to used standaradized, encrypted packets. The remailers are almost secondary here, except that we aren't sure that TA through the net is impossible. Or we could be facists, and _only_ send out PGP-ed, standard sized packets. (Forcing remailer-users to get into PGP.) Something would have to be done about lists & mail-to-news. Is there some difficulty in maintaining a database? Remailers would want to publicize their exsistance. This might involve pinging, but so what? That's just more noise. >The best way to do that is to open a socket between the remailers, and use >DH key exchange (authenticated with RSA?), to generate the encryption key. >This gives forward security to any intercepted messages. It is high on my >list of upgrades to Mixmaster. But doesn't this require a realtime connection to be practical? ie: remailers must be _on_ the net? As far as this all goes, the sender could stick _all_ packets together, PGP the whole thing, and send _that_. This would only require signing once per recipient per tick. T1, anyone? *** P.S. Could you mail me that essay? I'm long distance to the net right now. *** Adam Shostack <adam(a)bwh.harvard.edu> >Nathan Zook: >| >| Suppose Alice sends Bob a message e(M) through Chaum. Eve, a stong >| opponent, wants to trace the message. She keeps track of all outgoing mail >| from Alice, an MD5 hash of all incoming messages to Bob, and outgoing from >| Bob. Eve then sends Chaum e(M), and waits for a matching MD5 to Bob that >| doesn't correlate to an outgoing MD5 from Bob. (Eve knows that Bob is a >| remailer.) >| >| Gentlemen, I believe that I have just stumbled upon a strong proof of >| the necessity of remailer auto-encryption of all messages. Since the >| session key is PRG, MD5 will change (a lot;). Furthermore, remailer auto- >| encryption allows the mailers to number their messages to each other. A >| low number means a re-transmit from the remailer, which is not possible, >| unless some sort of ACK system is in place, and even then, would still >| flag. Of course, if the remailers _sign_ their messages (on the way out) >| as well, you could compare the timestamps of the signatures with the >| message itself. > > This is strong argument for encrypting your chain of messages, >using premail, or chainmail, or something similar. Why the remailers >should do this is not clear at all from your argument. Remailer >operator should be discouraged from cooperation beyond that which is >needed. > >Adam I think that you are missing the attack. Eve wants to prove that Alice sent a message to Bob. By resending Alice's message, it will route through Chaum just fine, producing identical output (message to Bob) as before. Assuming that Eve doesn't intercept the message, stopping Bob from getting it, Bob will know that something is up when he gets the message the second time, but by then it is too late. Eve knows that Alice's message, sent at time X, corresponds to a message received by Bob at time Y. This is exactly the sort of thing that LEAs love to use in building a case. My claim is that the only way to prevent this attack is for Chaum not to send out identical messages if he receives identical messages. Identical, in this case, would include messages identical except for "cryptographically strong random" data tacked on to the end, because if Eve had the storage space, she could compare messages _that_ way, stripping off the end bits, and getting the real message (encrypted) to Bob in the process. The natural way to do this is to super-encrypt. Of course, if Chaum just sends one rather large file to Bob each tick, Eve is hosed. BTW, if Chaum does an MD5-compare of all incoming messages, he can limit a spam to 1 per tick from his remailer with _no_ recordkeeping. Or maybe he could send a bunch of identical garbage messages to a random remailer, 85% of the time.... I really don't see how you can call this "cooperation beyond that which is needed". If the remailers default to strip nested envelopes, and to pad messages to standard sizes, the only "cooperation" between the operators is to publish PGP keys. They aren't "helping" each other, they are helping the end users. But this is all so trivial, compared to arguing operating systems. Nathan Finger or request keyserver for PGP 2.6.2 (tm) key. PGP<->Mail/News installation incomplete. Factors for modulous are not proven primes. Key may be far weaker than expected. Encode at your own risk. Key ID: 14712B4D 1994/12/26 Nathan H. Zook <nzook(a)bga.com> Key fingerprint = 44 B3 D8 66 3D 55 1E 2E F8 92 22 A6 33 8C DE 24 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBLywNqHmgMs8UcStNAQEgMAf/U+1rc6/5h6dZZAM9PuAJL0co25yE3JM4 vH3YSmRw31gQdjdRMw36XXZ4OLtTgV3CMBmlu5NoH5m80EAjUji3WCoRwhkin7G9 BgZnXhghR/ceLeE3MgyWZLTtApZkYO+z3zYxm1mYS4GLkuil/PENmuRrAFlihR4D jx/OgCbEU6EnR8Nyh0nGKqToOsE8wPZJfT5ff17vOSHV8hBre354ePB5tnkDoV5H MKgDTCkOx4vQJI8LNmQZHUCNyFmxuJTcYmxAM0j+8rAcdJzKo78eG7/vtJ4uxyBV AxPN7SJyCyplJGgQQ4+y9m5RkSYM6CQFy5PS+jLY66f3ZLmgDaW5vw== =Er9Z -----END PGP SIGNATURE-----

1 0

CERN Web Proxy
by Johnathan Corgan 17 Dec '03

17 Dec '03

Could someone post the host/port number of the proxy server at CERN? Thanks, Johnathan

3 3

Re: Secure (?) Remailer-net
by Hal 17 Dec '03

17 Dec '03

From: Nathan Zook <nzook(a)bga.com> > >> First, the message is signed with the sender's key. (More on that > >> later.) > > > >I did not see why this should be done. > > > > No? Isn't the InterNet currently under a serious packet-spoofing attack? > Don't we expect Eve to be AKA NSA? If I run a remailer, I want to know > that I'm not being lied to in the process. That insistance might just save > the legal butt of the guy being spoofed, by demonstrating that the packet > did not in fact originate from the remailer. Just because remailers are > legal doesn't mean that the govt won't still try to shut them down... I can see the advantage from the sender's point of view. If I sign all messages I send, then I have some defense against the charge that I sent a particular message, if it doesn't bear my signature. (OTOH the prosecutors can argue that I simply skipped signing that one.) This does of course expose me to the risk that if I _did_ send a particular message, my signature will be incriminating. In any case I am still puzzled by your statement that you as a remailer operator would want to be able to verify the source of all incoming messages. Would you do things differently with messages from different sources? I hear you saying that you care if you get a message claiming to be from Alice but not bearing a good signature from her. Why? Again, what would you do differently? > >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). > > > > In this instance garbage is defined as cryptographic random. If the > message has a length indicator in the clear, then Eve can read it. > (Remember, Eve runs snakoil(a)nsa.gov.) Therefore, such a marker has to be > _inside_ the wrapper. Given this, (that everything is PGP wrapped) there > is always the chance that PGP will compress a message, even one with > cryptographically strong bits in the end. While compression can improve > protection, it is not likely to do so if the original message was already > PGPed. Only "clear" messages, therefore, risk losing protection. As you > note, such messages don't deserve as much help as opaque ones. PGP already includes a cryptographically protected length field in the message. It will ignore any data past that, according to my experiments. All that is needed is a simple patch to add junk data to the end. > >> 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. > > > > Sure it does. If the whole thing is inside a PGP wrapper, then it is > secure. "Only passing through the contents of a PGP block" is currently a > security measure that makes good sense. But if you have two separate > blocks _inside_ an outer wrapper, you already have full security. Strip > off the outside, find two more wrappers. Strip the first, get remailing > instructions. Attempt to strip the second. Fail. Attach second wrapper > to forwarded message. Full security. I still don't quite follow this. Exactly what attack would be possible against Miron's remailer if it allowed encrypted reply blocks (as all others do) which would fail if the messages were wrapped as you suggest? > Alice signs her messages to the remailer because she doesn't want anyone > spoofing her use of the remailer. If a message goes in at 00:00:00.01, 1 > Jan, 2001 that is "From:" her, it is FROM her. More of the same reasoning. > This key doesn't have to have anything to do with the key she uses with > Bob. It is the one that she wants the general public to use for HER. Alice may not have a key whe wants the general public to use - she may just be using one for her private correspondents. Actually it seems to me given the nature of remailing that it would be superior if it were easy for people to "spoof" my use of the remailer. That would give me more credence to claim innocence. The more useless return addresses are, the less we even need remailers. > Suppose you were using the remailer net. Would you care to know that > someone was spoofing a node? I would. It would indicate that someone is > either hacking the system (probably no big deal), or that someone might be > shadowing a remailer. That is, the remailer is no longer secure. Spoofing > is a big deal on the net generally, and if we start being used a lot, we > will have to deal with it as well. Why not now? It's not my job to fix the damn Internet. So what if I get mail claiming to be from abc when it's actually from def? I of all people care the least, specifically because I throw away this data. Virtually everyone else on the net cares where their mail comes from, but I don't. My whole purpose is to discard the information about where it comes from. That is why I am so confused about your emphasis on checking signatures. > Maybe that was too harsh. I don't advocate holding people's hands. What I > _do_ want to do is to provide the best service that we can. Note that from > earlier and current work (thanks, guys!), we see that even if the remailer > net itself is completely secure, the sender and reciever can still be > traced with near-exponential speed. Although I agree with Wei Dai's mathematics, to my mind it points up the importance of successful countermeasures rather than implying that the remailer network is inherently insecure. For example, if you send one identical message every batch, Wei's math shows clearly that you can't be traced. Let's not get rumors started about how the remailers don't work. > So our systems provide a delay in tracking of a couple of months. Big > deal. The TLAs routinely take years to build a serious case. If we are > going to be any help to folks that _really_ need it, we have to extend the > black box all the way to people outside the net. As you said, not everyone > will be remailers anytime soon. Do you see your suggestion as protecting against Wei's in/out correlation attack? I don't see it. If fixed-sized packets are used, with chained encryption, I think you have as good a system as you do with all of your inter-node encryption and signing. Suppose one good encrypted message enters the net with 10 unencrypted ones. Won't the full path of each of the 10 be visible to an outsider? Even if the remailer helps out those 10 doltish users by encrypting them from there on out, the outsider already saw their whole paths! They will know how many unencrypted messages are going out to each destination, and from that determine where the encrypted message is going. > >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. > > > > Actually, I did make this error when I first considered this, also. We do > not hope for a short key. In fact, we know that the key will be long, when > viewed in parts, as I now believe that it is. We hope that the key will be > 0 rich. The chance of this just comes off of the binomial distribution, > which is not nearly so bad. Sorry. And a, say, 10% improvement above > expected allows a cooresponding length increase--which does something > _more_ than improve security by 10% ;) Yes, I see that you are right about this. It would be easy to generate e,d pairs and get a d which is significantly short on 1's by 10% or more. I did not quite follow your algorithm to do this (was n the modulus or was it phi, the sum of the modulus' divisors?). The one caveat is that if "high-zero" decryption exponents are widely used, it could conceivably reduce the search space somehow, although I don't see offhand how to exploit this. Hal

1 0

Six month mail processing delay :-)
by Robert A. Hayden 17 Dec '03

17 Dec '03

I just HAD to forward this message I received. About a 9 months ago I joined Adam Curry's "CyberSleaze" mailing list. About a month later I unsubscribed. The messages continued to come and I tried unsubscribing several more times. Finally I set up a filter rule to flush the message and sent some grumpy email to the postmaster of the site telling them to fix their software (this was about mid-June of 1994). This morning, I got the following message. Note the dates on it. Nothing like taking one's time. You'd begin to think the government was somehow involved. -----BEGIN INCLUDED MESSAGE----- >From MAILER-DAEMON(a)mtv.comSun Jan 29 16:25:27 1995 Date: Sun, 29 Jan 1995 16:46:32 -0500 From: Mail Delivery Subsystem <MAILER-DAEMON(a)mtv.com> To: hayden(a)krypton.mankato.msus.edu Subject: Returned mail: unknown mailer error 1 The original message was received at Tue, 24 May 1994 09:49:16 -0500 from root@localhost ----- The following addresses had delivery problems ----- "|/home/server/catmail -f -L CYBER-SLEAZE" (unrecoverable error) (expanded from: daemon) ----- Transcript of session follows ----- 554 "|/home/server/catmail -f -L CYBER-SLEAZE"... unknown mailer error 1 ----- Original message follows ----- [ Part 2: "Included Message" ] Date: Tue, 24 May 1994 08:54:59 -0500 (CDT) From: "Robert A. Hayden" <hayden(a)krypton.mankato.msus.edu> To: cyber-sleaze(a)mtv.com unsubscribe ------END INCLUDED MESSAGE-----

2 1

Telnet Acrobatics
by ghio＠myriad.pc.cc.cmu.edu 17 Dec '03

17 Dec '03

What follows are two small programs which I thought might be of interest to cypherpunks. The first (socket.c) is a simple daemon which binds a port and accepts connections, and then forks child processes for each one. The second (relay.c) is a simple telnet program which opens a connection to the specified remote host and port number. Put together they can be used as a telnet relay ("proxy server") that works like the term redir command. This in itself is useful, if you want to hide where you're coming in from, bypass a broken router or get through a firewall. But, take a look at the loop at the end of the second program. It simply reads input from one socket and writes it to another. It would seem to me very easy to add an encryptor/decryptor to this process and encrypt your telnet sessions. You'd just need to exchange a key (via PGP) with the remote system, and decide on a port number, then run crypt/dec daemons on both systems. The socket.c program might also be useful for socket-based remailing. (Tho you can set it up in your inetd.conf instead, if you have root access.) However, I'm having a bit of trouble compiling these on some platforms. I do not know who the original author is. (These came out of a toolkit for breaking system security and the author did not want to be known.) After including a few additional libraries, I was able to compile both under Linux, and it seems to work reasonably well. They'll also compile under SunOS, if you include <sys/termios.h>, but it won't handle non-blocking I/O correctly, and can hang. I can't get relay.c to compile under Ultrix, though socket.c seems to work. socket.c also has a tendency to leave zombie processes hanging under Linux. Anyone want to take a shot at debugging/porting it on other platforms or adding crypto? begin 644 socket.c M(VEN8VQU9&4@/'-Y<R]T>7!E<RYH/@HC:6YC;'5D92`\<WES+W-I9VYA;"YH M/@HC:6YC;'5D92`\<WES+W-O8VME="YH/@HC:6YC;'5D92`\;F5T:6YE="]I M;BYH/@HC:6YC;'5D92`\;F5T9&(N:#X*(VEN8VQU9&4@/'-Y<R]T:6UE+F@^ M("\J(%)E<75I<F5D(&9O<B!,:6YU>"`H8G5T(&YO="!3=6Y/4RD@*B\*(VEN M8VQU9&4@/'5N:7-T9"YH/B`O*B!297%U:7)E9"!F;W(@3&EN=7@@*&)U="!N M;W0@4W5N3U,I("HO"B`@("`@("`@("`@("`@(`IR96%P*"E["B`@("`@("`@ M:6YT(',["B`@("`@("`@=VAI;&4H=V%I="@F<RDA/2TQ*3L*?0IM86EN*&%C M+&%V*6EN="!A8SL*:6YT("HJ878["GL*("`@("`@("!S=')U8W0@<V]C:V%D M9')?:6X@;7EA.PH@("`@("`@('-T<G5C="!S97)V96YT("IS<`H@("`@("`@ M(#L*("`@("`@("!F9%]S970@;75F.PH@("`@("`@(&EN="!M>69D+&YE=RQX M+&UA>&9D/6=E=&1T86)L97-I>F4H*3L*("`@("`@("!S:6=N86PH4TE'0TQ$ M+')E87`I.PH@("`@("`@(&EF*"AM>69D/7-O8VME="A!1E])3D54+%-/0TM? M4U1214%-+`H@("`@("`@("`@("`P*2D\,"EE>&ET*#$I.PH@("`@("`@(&UY M82YS:6Y?9F%M:6QY/4%&7TE.150["B`@("`@("`@8GIE<F\H)FUY82YS:6Y? M861D<BP*("`@("`@("`@("`@<VEZ96]F*&UY82YS:6Y?861D<BDI.PH@("`@ M("`@(&EF*"AS<#UG971S97)V8GEN86UE*&%V6S%=+")T8W`B*2D*("`@("`@ M("`@("`@/3TH<W1R=6-T('-E<G9E;G0@*BDP*7L*("`@("`@("`@("`@("`@ M(&EF*&%T;VDH879;,5TI/#TP*65X:70H,2D["B`@("`@("`@("`@("`@("!M M>6$N<VEN7W!O<G0*("`@("`@("`@("`@("`@("`@("`]:'1O;G,H871O:2AA M=ELQ72DI.PH@("`@("`@('T@96QS92!M>6$N<VEN7W!O<G0]<W`M/G-?<&]R M=#L*("`@("`@("!I9BAB:6YD*&UY9F0L"B`@("`@("`@("`@("AS=')U8W0@ M<V]C:V%D9'(@*BDF;7EA+'-I>F5O9BAM>6$I*2EE>&ET*#$I.PH@("`@("`@ M(&EF*&QI<W1E;BAM>69D+`H@("`@("`@("`@("`Q*3PP*65X:70H,2D["FQO M;W`Z(`H@("`@("`@($9$7UI%4D\H)FUU9BD["B`@("`@("`@1D1?4T54*&UY M9F0L)FUU9BD["B`@("`@("`@:68*("`@("`@("`H<V5L96-T*&UY9F0K,2PF M;75F+#`L,"PP*2$],7Q\(49$7TE34T54*&UY9F0L)FUU9BDI9V]T;PH@("`@ M("`@("`@("!L;V]P.PH@("`@("`@(&EF*"AN97<]86-C97!T*&UY9F0L,"PP M*2D\,"EG;W1O(&QO;W`["B`@("`@("`@:68H9F]R:R@I"B`@("`@("`@("`@ M(#T],"E["B`@("`@("`@("`@("`@("!F;W(H>#TR.W@\;6%X9F0[>"LK*6EF M*'@A/6YE=REC;&]S92AX*3L*("`@("`@("`@("`@("`@(&9O<BAX/3`[>#P* M("`@("`@("`@("`@("`@("`@("!.4TE'.W@K*RES:6=N86PH>"Q324=?1$9, M*3L*("`@("`@("`@("`@("`@(&1U<#(H;F5W+#`I.PH@("`@("`@("`@("`@ M("`@8VQO<V4H;F5W*3L*("`@("`@("`@("`@("`@(&1U<#(*("`@("`@("`@ M("`@("`@("`@("`H,"PQ*3L*("`@("`@("`@("`@("`@(&1U<#(H,"PR*3L* M("`@("`@("`@("`@("`@(&5X96-V*&%V6S)=+&%V*S(I.PH@("`@("`@("`@ M("`@("`@97AI="@Q*3L*("`@("`@("!]"B`@("`@("`@8VQO<V4H;F5W*3L* 5("`@("`@("!G;W1O(&QO;W`["GT* ` end begin 644 relay.c M(VEN8VQU9&4@/'-T9&EO+F@^"B-I;F-L=61E(#QN971D8BYH/@HC:6YC;'5D M92`\<WES+W1Y<&5S+F@^"B-I;F-L=61E(#QS>7,O9FEL92YH/@HC:6YC;'5D M92`\;F5T:6YE="]I;BYH/@HC:6YC;'5D92`\<WES+W-O8VME="YH/@HC:6YC M;'5D92`\97)R;F\N:#X*(VEN8VQU9&4@/&9C;G1L+F@^"B-I;F-L=61E(#QS M>7,O:6]C=&PN:#X*(VEN8VQU9&4@/'5N:7-T9"YH/@HC:6YC;'5D92`\<WES M+W1I;64N:#X*+RHC:6YC;'5D92`\<WES+W1E<FUI;W,N:#XJ+R`@+RH@4F5Q M=6ER960@9F]R(%-U;D]3("AB=70@;F]T($QI;G5X*2`J+PH*=F]I9"!M86EN M*&EN="!A<F=C+&-H87(@*BIA<F=V*0I["B`@<F5G:7-T97(@8VAA<B`@("`@ M("`J<#L*("!R96=I<W1E<B!C:&%R("`@("`@("ID97-T.PH@(')E9VES=&5R M(&EN="!X.PH@(&-H87(@:&]S=&YA;65;,C4V73L*("!I;G0@861D<CL*("!I M;G0@8V]N;F5C=&EO;E]O:SL*("!S=')U8W0@:&]S=&5N="`J:&]S=#L*("!I M;G0@<F5M;W1E9F0["B`@:6YT(&9D.PH@('-T<G5C="!S;V-K861D<E]I;B!R M96UO=&5S97)V97(["B`@=6YS:6=N960@8VAA<B!C.PH@(&9D7W-E="!R96%D M9F1S.PH@(&9D7W-E="!W<FET969D<SL*("!F9%]S970@97AC97!T9F1S.PH@ M('-T<G5C="!T97)M:6]S('1I;W-T<CL*("!I;G0@<CTQ.PH@(&EN="!W/3$[ M"B`@8VAA<B!B=69F97);,3`R-%T["B`@:6YT(&\["B`@"B`@<W1R8W!Y*&AO M<W1N86UE+&%R9W9;,5TI.PH@(&AO<W0@/2!G971H;W-T8GEN86UE("AH;W-T M;F%M92D["B`@:68@*"%H;W-T*2!P<FEN=&8H(B5S.B!U;FMN;W=N(&AO<W1< M;B(L(&AO<W1N86UE*3L*("!B8V]P>2`H:&]S="T^:%]A9&1R+"`F861D<BP@ M-"D["B`@<F5M;W1E<V5R=F5R+G-I;E]F86UI;'D@/2!H;W-T+3YH7V%D9')T M>7!E.PH@(')E;6]T97-E<G9E<BYS:6Y?<&]R="`](&AT;VYS*&%T;VDH87)G M=ELR72DI.PH@(`H@('`@/2`H8VAA<B`J*2HH:&]S="T^:%]A9&1R7VQI<W0I M.PH@(&9O<B`H9&5S="`]("AC:&%R("HI)G)E;6]T97-E<G9E<BYS:6Y?861D M<BP@>"`](&AO<W0M/FA?;&5N9W1H.R`M+7@@/CT@,#L@*0H@("`@*F1E<W0K M*R`]("IP*RL["B`@"B`@<F5M;W1E9F0@/2!S;V-K970H:&]S="T^:%]A9&1R M='EP92P(a)4T]#2U]35%)%04TL(#`I.PH*("!C;VYN96-T:6]N7V]K(#T@8V]N M;F5C="`H<F5M;W1E9F0L("AS=')U8W0@<V]C:V%D9'(@*BDF<F5M;W1E<V5R M=F5R+"!S:7IE;V8H<F5M;W1E<V5R=F5R*2D["@H@(&EF("AC;VYN96-T:6]N M7V]K(#P@,"D*("`@('L*("`@("`@<')I;G1F("@B0V]N;F5C=&EO;B!%<G)O M<EQN(BD["B`@("`@(&9F;'5S:"`H<W1D;W5T*3L*("`@('T*"B`@+RH@3VMA M>2P@8V]N;F5C=&EO;B!E<W1A8FQI<VAE9"X@*B\*"B`@9F-N=&PH<F5M;W1E M9F0L($]?3D].0DQ/0TLI.PH@(&9D/3`["B`(a)9F-N=&PH9F0L($]?3D].0DQ/ M0TLI.PH*("!I;V-T;"AF9"P@1DE/3D))3RP@*&EN="`J*3$I.R`O*B!.;VXM M0FQO8VMI;F<@22]/("HO"B`@:6]C=&PH<F5M;W1E9F0L($9)3TY"24\L("AI M;G0@*BDQ*3L*("`*("!I;V-T;"AF9"P@5$-'1513+"`F=&EO<W1R*3L*("!T M:6]S='(N8U]L9FQA9STP.R`O*B!$:7-A8FQE(&%L;"!P<F]C97-S:6YG.R!U M;F%L=&5R960@."UB:70@8VAA;FYE;"`J+PH@('1I;W-T<BYC7VEF;&%G/3`[ M"B`@=&EO<W1R+F-?;V9L86<],#L*("!T:6]S='(N8U]C8UM624Y44ET],#L* M("!T:6]S='(N8U]C8UM6455)5%T],#L*("!T:6]S='(N8U]C8UM614]&73TP M.PH@(&EO8W1L*&9D+"!40U-%5%,L("9T:6]S='(I.PH*("!I;V-T;"AR96UO M=&5F9"P@5$-'1513+"`F=&EO<W1R*3L*("!T:6]S='(N8U]L9FQA9STP.R`O M*B!$:7-A8FQE(&%L;"!P<F]C97-S:6YG.R!U;F%L=&5R960@."UB:70@8VAA M;FYE;"`J+PH@('1I;W-T<BYC7VEF;&%G/3`["B`@=&EO<W1R+F-?;V9L86<] M,#L*("!I;V-T;"AR96UO=&5F9"P@5$-31513+"`F=&EO<W1R*3L*("`*("!& M1%]:15)/*"9W<FET969D<RD["B`@1D1?6D523R@F97AC97!T9F1S*3L*("`* M("!W:&EL92AR(3TP)B9W(3TP*2!["B`@("!&1%]:15)/*"9R96%D9F1S*3L* M("`@($9$7U-%5"AF9"P@)G)E861F9',I.PH@("`@1D1?4T54*')E;6]T969D M+"`F<F5A9&9D<RD["B`@("!S96QE8W0H,38L("9R96%D9F1S+"`F=W)I=&5F M9',L("9E>&-E<'1F9',L*'-T<G5C="!T:6UE=F%L("HI,"D["B`@("`O*B!4 M:&ES('=O<FMS(&)U="!I<R!W87D@=&]O('-L;W<N+BX@*B\*("`@("\J=SUR M96%D*&9D+"9C+#$I.VEF("AW/C`I('=R:71E*')E;6]T969D+"9C+#$I.RHO M"B`@("`O*G(]<F5A9"AR96UO=&5F9"PF8RPQ*3MI9B`H<CXP*2!W<FET92AF M9"PF8RPQ*3LJ+PH@("`@=SUR96%D*&9D+&)U9F9E<BPQ,#(T*3MI9B`H=SXP M*0H@("`@>PH@("`@("!O/3`["B`@("`@('=H:6QE*&\\=RD@;SUW<FET92AR M96UO=&5F9"QB=69F97(K;RQW+6\I.PH@("`@?0H@("`@<CUR96%D*')E;6]T M969D+&)U9F9E<BPQ,#(T*3MI9B`H<CXP*0H@("`@>PH@("`@("!O/3`["B`@ M("`@('=H:6QE*&\\<BD@;SUW<FET92AF9"QB=69F97(K;RQR+6\I.PH@("`@ L?0H@('T*"B`@8VQO<V4H<F5M;W1E9F0I.PH@(&-L;W-E*&9D*3L*("`*?0H@ ` end

3 2

Telnet Acrobatics
by ghio＠myriad.pc.cc.cmu.edu 17 Dec '03

17 Dec '03

BTW, usage is socket <portnumber> command relay <hostname> <postnumber> You can combine them to make a telnet relay/forwarded with: socket <localport> relay <hostname> <remoteport>

1 0

null What's Killing My Remailed Posts?
by nobody＠rebma.rebma.mn.org 17 Dec '03

17 Dec '03

[Please Reply-To: an105(a)vox.xs4all.nl as I am not receiving the group or list on which this message _hopefully_ appears. Thanks!] Though I have been vigorously using the various remailers for a long time, I am stumped by my sudden inability to get a post to a newsgroup by any remailed means. Example: For a long time I have used the following boilerplate form with usura(a)replay.com with flawless results: :: Encrypted: PGP :: Anon-To: my.anon.address(a)somewhere.org Cutmarks: * | Message Successfully Remailed, # 999 * :: Anon-To: mail2news(a)demon.co.uk Cutmarks: ___ Latent-Time: +6:00r ## Newsgroups: alt.some.group,misc.another.group Subject: Furballs in Wolverines My wolverine has nasty furballs... [...] My wolverine thanks you all for suggestions... ___ The current status of this is that I get the remailed receipt, but the message never shows in the group. Is mail2news(a)demon.co.uk down? I tried using the Usura Anon-Post-To: feature, but it fails as well. I've tried using _other_ remailers with the simple form... Anon-To: alt.some.group(a)comlab.ox.ac.uk Anon-To: alt.some.group.usenet(a)decwrl.dec.com Anon-To: alt.some.group(a)bull.com I've also tried Request-Remailing-To: with the same address form. Nada. I have been unable to make any of the usual remailers get through to the groups by any means for about three weeks, though evidence shows that the remailers are certainly getting the messages, as I can send anon netmail messages - - - the _posts_ just never show. I periodically suspect that someone somewhere is running a program to sweep all posts with "remail," "nobody" or "anon" anywhere in the header. Any thoughts on this...assuming it shows here? ___ Blue Wave/QWK v2.12

2 1

Re: CERN Web Proxy
by Johnathan Corgan 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >> CERN = http://www.cern.ch:911 > >Error 403 > >Forbidden - by rule > > >CERN httpd 3.0 This is what you get if you interpret the above as a URL...which makes sense since that was how it was posted. What it really is is the host name and port name to configure your Web browser so that all your HTTP traffic is funnelled through CERN first, and then relayed from there to the destination. I don't know how Mosaic supports this, but under Netscape for Windows, it is under Options | Preferences | Mail and Proxies | HTTP Proxy. While this doesn't provide complete anonymity, it does prevent your email address, site name, etc. from appearing in the log files of the HTTP server you are connecting to. I'm not sure why CERN has this running, but it is pretty usefull nonetheless. == Johnathan Corgan "Violence is the last refuge of the incompetent." jcorgan(a)aeinet.com -Isaac Asimov -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLywpCk1Diok8GKihAQHH+AQA4EG9IPrwZ76iLggvbyjaBRLiDETzTjyz ljz87cOeAZ/sXevexPRD3RDzkSzOGRfbsFHEEV6gNI1q+35saJYCCVMdxCZUggeO xIIkCg+lTC6vMjj4JLQ5nLH2yZX2na3DjeR5/vidaSw2oEEUM0n06e6XnXS19mZ9 /ggmzfYtt1U= =hxmC -----END PGP SIGNATURE-----

1 0

ESP -> ESM
by Matt Blaze 17 Dec '03

17 Dec '03

I've just been informed that there's a reasonably confusing name collision between my ESP and a working name for IPSP. Grumble. I'm easy. ESP is now called ESM (encrypting session manager). Everything else is the same. -matt

1 0