December 2003 - cypherpunks-legacy

Re: Bekenstein Bound (was: Crypto and new computing strategies)
by Hal 17 Dec '03

17 Dec '03

From: mpd(a)netcom.com (Mike Duvos) > Jim Choate writes: > > > If you accept the universe as unbounded then you have to throw out the Big > > Bang and much of conventional physics, including large parts of what you > > are trying to prove. > > I think you may be confusing the notion of "unbounded" with the notion of > "finite". The Big Bang is perfectly consistant with the notion of a > finite but unbounded universe. The big bang is also perfectly consistent with an infinite and unbounded universe. This is part of the well-known debate over whether the universe is "open" or "closed". An open universe is infinite in extent. However, at any given time only a finite portion of the universe is avail- able, so the infinity is not really accessible. Hal

1 0

Re: Proposal: some more standard remailer features
by hfinney＠shell.portal.com 17 Dec '03

17 Dec '03

From: rjc(a)gnu.ai.mit.edu (Ray) > Here are some proposed remailer standards some of which I have > already implemented. > > Command Formatting: > > I propose that all remailer commands start on the first non-blank line of a > message body and start with the string '::' followed by a command-name > with no spaces in it. A command block should end when two blank lines are > encountered (which are stripped from the output) or a non-blank > line that doesn't start with '::' is encountered. Why look for *two* blank lines to end a command block? Why not just end a command block when you find a line not starting with ::? > Message Encapsulation: > > I propose a standard format for recursively storing messages in > envelopes with standard formats. Each envelope should begin with the > command "::envelope" followed by the envelope method, followed by the > body. The end of the "envelope" is specified with ::end METHODNAME This is reminiscent of MIME. Have you looked at that? They already deal with encapsulation as well as message splitting, I think. You could copy their message formats without committing to full MIME support. Plus it might be possible to add encryption and remailing support to MIME mail user agents by using the hooks they already provide. > I propose the header pasting token, "::@" which gets applied > only after the message is delivered to someone (not chained). > For example > ::@Subject this is the subject line > ::@From this is the from line > ::@x-foo this is the x-foo: header The only thing that seems wrong about this is that the remailer apparently has to know whether it is sending to a person or another remailer. I think you should follow instructions about pasting these header fields by what the user has requested rather than deciding for him. Maybe I don't under- stand exactly how Ray is proposing that these commands be used. > Depending on how the remailer is set up, incoming subject headers > may or may not be preserved. I would recommend that they not be preserved, but I suppose that is up to the operator. This may sound crazy, but I am concerned about adding these features which make the system too easy to use. It seems that at the limit a person can just put "::To: friend(a)college.edu#remailer1#remailer2#*#*#remailer3" at the top of his message and his mail goes zipping down this extremely com- plicated path. But the problem is that this is really deceptive in terms of how secure it is. All this ease of use is at the expense of having to put a lot more trust into one or a few remailer operators. It's not clear that it's better to provide the temptation of easy-to-use but falsely secure remailers. At least with Julf you know you're trusting him. With addresses like the above users may not realize how many eggs they're putting into that first remailer's basket. > EXAMPLE MESSAGE: > > ::envelope PGP > [PRETEND EVERYTHING FROM HERE DOWN IS ENCRYPTED FOR THE REMAILER] > ::to ann's_remailer#darkmodem > ::@Subject Hello World > > <Message text> > ::end PGP > > when sending this out, the remailer might encrypt the message > for ann's remailer and split it into two pieces > [...] > Now when ann's remailer receives a two parted message, it queues > each piece until it gets the full message (timing out after a few > days) After all pieces are received, it removes the envelopes, > pieces the message together, and sends the message off to darkmodem > (which may be a virtual address for lightmodem#bob's_remailer) This kind of splitting would be more useful if it were carried through to the end user. Otherwise the reassembled message is conveniently provided for inspection by the spooks as it goes to him. Again, I think MIME may provide for reassembly at the end user. > I also propose ::route which would specify preferences preferred for > remailers when searching for other remailers to chain your > message to. e.g. Would this be used with the "*" remailer-chooses-remailer feature? If the user specifies the path then presumably there is no provision for remailers to make choices like these. Despite my concerns, I think Ray has so many good ideas here that it will be great to see his software operating. The "market" for remailers is the users who want both privacy and ease of use. Ray's enthusiasm and energy in putting all these ideas into code will go a long way towards finding out what kinds of trade-offs the market wants. Hal

1 0

Chaum on Traceable Cash
by Hal 17 Dec '03

17 Dec '03

I wrote something last week on whether digital cash should be traceable. Here is a quote by Chaum in favor of traceable cash. It is from Eurocrypt 87, "Blinding for Unanticipated Signatures", on page 228: "The ability to anticipate a large number of signature types can benefit the payment system described in [Chaum, D. "Security without identification: transaction systems to make big brother obsolete," Communications of the ACM, 28, 10 (Octoboer 1985), pp. 1030-1044]. This would allow customers of the bank providing a system to each supply a large number of blinded items when their accounts are opened, without the customers knowing in advance which particular type of signature will later be applied by the bank. Not only can this provide economy of data transfer, but it protects the bank's customers from being able to (and hence from being coerced into) making payments that they cannot later trace." The technical basis for Chaum's statement is obscure, but the political point is that if you can make an untraceable payment, you could be coerced into doing so, for example by being robbed at gunpoint. Contrariwise, if the cash system used by you and your bank is such that all money is in- herently traceable, it will be a lot harder to commit robbery, extortion, kidnapping, and all those other horrors which people fear will come with digital cash. Hal

1 0

Rubbish Lister
by Istvan Oszaraz von Keszi 17 Dec '03

17 Dec '03

I've been following the remailer debate, and have found it's easier to understand in code. Right now, I am trying to find a regular expression which unfolds the from line. All it does is parse on the message using ::<cr><lf> for a command block. (That should finish up the first parse.) It keeps a subject from the header but overwrites it. And it keeps track of who sent the mail in case they want something sent back. It looks for /^command/ in the command block (it reads in lines of 2) and acts accordingly. (To: is understood, but unfolding the rest?????) It also sends an operator message based on log and debugging levels. I'm editting this code myself, both so that I understand it and can maintain it. My problems are twofold, first, the operator can look at the messages. Although, why would anyone want to, given the risks? Second, PGPPASS on a multi-user system gives a false sense of security. Definitely, not a feature. So, I've got skeleton code, which way to turn, how to flesh it out. -- "My memory is so bad, that many times I forget my own name!"

1 0

Re: Proposal: some more standard remailer features
by rjc＠gnu.ai.mit.edu 17 Dec '03

17 Dec '03

Hal writes: > From: rjc(a)gnu.ai.mit.edu (Ray) > > with no spaces in it. A command block should end when two blank lines are > > encountered (which are stripped from the output) or a non-blank > > line that doesn't start with '::' is encountered. > Why look for *two* blank lines to end a command block? Why not just end a > command block when you find a line not starting with ::? Experience from the Extropians list. A large number of people made the mistake of inserting blank lines between commands and some people's mailers did it automatically (one of the more stupider one's actually removed a leading colon from the line changing ::exclude to :exclude) I got a lot of complaints, so I removed the restriction of single blank lines being able to terminate. In fact, the regular expression which parses lines looks like this: /^\s*::\s*(.*)$/ So that spaces are allowed before and after the '::' On the extropians list, an arbitrary amount of whitespace is allowed because ':::' is used to separate command blocks from the body of messages. > > Message Encapsulation: > > > > I propose a standard format for recursively storing messages in > > envelopes with standard formats. Each envelope should begin with the > > command "::envelope" followed by the envelope method, followed by the > > body. The end of the "envelope" is specified with ::end METHODNAME > This is reminiscent of MIME. Have you looked at that? They already deal > with encapsulation as well as message splitting, I think. You could copy > their message formats without committing to full MIME support. Plus it > might be possible to add encryption and remailing support to MIME mail user > agents by using the hooks they already provide. I thought of MIME, but I didn't know it was so popular (I last looked at it over a year ago). I just looked at the comp.mail.mime FAQ and the RFCs and I see that MIME is gaining momentum. Two problems instantly jumped out at me when reading the MIME documents: 1) more than 2-level encodings are not supported (no recursion) 2) no application/viewpgp or transfer-encoding: pgp type MIME actually takes care of the multipart issue nicely. I'm going to do some more research and I may end up scraping ::envelope if MIME's encapsulation is powerful enough for inter-remailer I/O. (the one pain in the butt is that now I will have to process the headers instead of throwing them away) Perhaps the PEM/MIME documents will be of help. > The only thing that seems wrong about this is that the remailer apparently > has to know whether it is sending to a person or another remailer. I think > you should follow instructions about pasting these header fields by what > the user has requested rather than deciding for him. Maybe I don't under- > stand exactly how Ray is proposing that these commands be used. Correct. You don't want headers to be visible during the chaining, and the remailers throw away incoming headers. Therefore, I felt that ::@ shouldn't be applied until the message is posted or sent to a real e-mail address. Any suggestions on a better method? > This may sound crazy, but I am concerned about adding these features which > make the system too easy to use. It seems that at the limit a person can > just put "::To: friend(a)college.edu#remailer1#remailer2#*#*#remailer3" at > the top of his message and his mail goes zipping down this extremely com- > plicated path. But the problem is that this is really deceptive in > terms of how secure it is. All this ease of use is at the expense of having > to put a lot more trust into one or a few remailer operators. You could concentrate your trust on the first remailer in the chain. Once it goes through that remailer, it is now encrypted for the recipient and the source of the message is destroyed. Keep in mind, the other remailers in the chain can not snoop on the message because it is encrypted for the recipient automatically (if a key is present). The other remailers can do traffic analysis if the user doesn't use any wildcards ("*"), but this can be limited using recursion. e.g. ::envelope PGP ::to remailer1 ::envelope PGP [for remailer 1] ::to remailer2 ::envelope PGP [for remailer 2] ::to remailer3 ::envelope PGP [for friend] ::to friend(a)college.edu I agree most of the power should be in the client (hopefully, my approach allows both a powerful client or simplemail use), but there also needs to be a "lowering of transaction costs" as Eric suggested. Many people don't have unix accounts and with the advent of Compuserve/Delphi/Genie/AOL internet gateways, some sort of server approach is required. Part of the reason for including a socket-server in the remailer is to allow clients to hook into the network and get data fast. > This kind of splitting would be more useful if it were carried through > to the end user. Otherwise the reassembled message is conveniently > provided for inspection by the spooks as it goes to him. Again, I think > MIME may provide for reassembly at the end user. If I understand correctly from my fast reading, it does: the multipart/partial content-type. (the comp.mail.mime faq is an example) The hurdle is getting a MIME type registered which can recognize pgp encrypted and/or signed messages. > > I also propose ::route which would specify preferences preferred for > > remailers when searching for other remailers to chain your > > message to. e.g. > Would this be used with the "*" remailer-chooses-remailer feature? If the > user specifies the path then presumably there is no provision for remailers > to make choices like these. Correct. It would be used with the "*" feature and also the auto-chaining. (if a user just says ::to friend(a)college.edu, the remailer may choose to chain this through several other remailers automatically) Thanks, -Ray

4 3

remailer fyi...
by Evil Pete 17 Dec '03

17 Dec '03

------- Forwarded Message Return-Path: geek(a)imageek.york.cuny.edu Return-Path: <geek(a)imageek.york.cuny.edu> Received: from imageek.york.cuny.edu by merde.dis.org (8.6.8.1/MERDE-940323) id TAA26402; Tue, 5 Apr 1994 19:51:09 -0700 Received: by imageek.york.cuny.edu (931110.SGI/931108.SGI.evr1) for remailer(a)utter.dis.org id AA15418; Tue, 5 Apr 94 22:58:31 -0400 From: geek(a)imageek.york.cuny.edu (Erik VanRiper) Message-Id: <9404060258.AA15418(a)imageek.york.cuny.edu> Subject: entropy.linet.org To: root(a)dis.org, remailer(a)dis.org Date: Tue, 5 Apr 1994 22:58:21 -0500 (EDT) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 579 I am the MX and the site admin for linet.org. You have a "user" remailer(a)utter.dis.org that is sending PGP messages to entropy.linet.org!remailer Can you please stop? entropy.linet.org has not polled for almost 2 months, and I have not been able to contact him. I assume that he is down for good. Thanks! - -- geek(a)imageek.york.cuny.edu Erik VanRiper (718) 262-2667 Systems Administrator Janitor Photon Counter Chemistry Department & MBRS York College, City University of New York ------- End of Forwarded Message

1 0

Security Contingencies
by Jeff Davis 17 Dec '03

17 Dec '03

Date: Tue, 5 Apr 1994 23:48:29 -0400 From: Black Unicorn <unicorn(a)access.digex.net> Subject: Al Haig and Secure Communictions >incident involving then Secretary of State Al Haig. >Specifically the point was in reply to Mr. Sternlight's >assertion that because a public relations official for the >NSA had made statements regarding the Data Encryption >Escrow plan's harmless nature and the equally harmless and >benign character of the NSA's paternal hand, they were >unquestionably authentic and complete. Sternlight is an idiot educated beyond his intellegence, unworthy of futher comment, exept to say you're beginning to make an exceptional point. >Secretary of State Al Haig was not next in line for either >succession stream, and his asserting so in the national >media was a gross error. >The relevant authorities are the Department of Defense >Directive 5100.30 (1971) and the Constitution of the United >States. [skipping the event of peacetime Presidential elimination] >The national command authority line kicks in when the >President and his/her successors are dead or cannot be >located and immediate U.S. military decisions must be made: >1. Secretary of Defense >2. Deputy Secretary of Defense >3. Secretary of the Army >4. Secretary of the Navy >5. Secretary of the Air Force >6. Under Secretary of Defense for Policy >7. Under Secretary of Defense for Research and Engineering >A plethora of the Assistant Secretaries of Defense and >General Council to the Defense Department in order of their >lengths of service. Well let's hope that the President survives the unlikely event of a tactical nuclear detonation or we're all fucked. While we're on the subject: -- Article III, section 3. Treason against the United States, shall consist only in levying war against them, or in adhering to their enemies, giving them aid and comfort. No person shall be conviced of treason unless on the testimony of two witnesses to the same overt act, or on confession in open court. The Congress shall have power to declare the punishment of treason, but no attainder of treason shall work corruption of blood, or forfeiture except during the life of the person attained. -- So if encryption is outlawed, outlaws will get life. I talked to Federal Reserve President Thomas Hoenig (KC Branch) in an open public forum yesterday. I asked him if the Fed was going to let Clipper encryption cripple US competitiveness in the world monetary market. He looked down at his feet and said, "No." He was very suprised that I was already using public key encryption. He knew well the superiority of software encryption. However, he had never heard of Phil Zimmerman. When I elucidated a brief history of PGP, he agreed that embargoing encryption is tantamount to embargoing wind. This hand is an economic warfare expert. He agreed the 4 February policy decision is economic warfare. I don't think the Fed is going to let the NSA severely hobble its ability to wage economic warfare in the world monetary market. Digital cash is the Fed's dream. That's my analysis based on the facts presented and what I saw in the man. So I think now, more than ever, we really have to stick together. -- PGP PUBLIC KEY via finger! JAFEFFM Speaking & Thinking For Myself! * eagle(a)deeptht.armory.com email info(a)eff.org * *** O U T L A W S On The E L E C T R O N I C F R O N T I E R **** ***** Committed to Free Public Internet Access for World Peace *****

1 0

Remailer Pinging
by Black Unicorn 17 Dec '03

17 Dec '03

It occured to me, and I'm probably not the first, that it would be quite a resource to have a finger server that dumps the last ping responses for the active remailers. Would it be difficult to cook up a script that pings the remailers every 12 or 24 hours and then stores the "last ping received" data and dumps it on a remote finger command? I would myself but I dont have the hardware resources :( My programming leaves much to be desired as well. Problems? Comments? -uni- (Dark)

1 0

Re: How Many Games of Chess: Exact answer given!
by tim werner 17 Dec '03

17 Dec '03

>From: Eli Brandt <ebrandt(a)jarthur.cs.hmc.edu> >There are a finite number of legal positions in chess. If any >shows up a third time, the game is over. Thus we have a bound on >the length of a legal chess game. Hence the number of games is >finite, and we don't have to quibble about whether it's countably >or uncountably infinite. Since this is the second time this has shown up here, I must clarify it by saying that it is only a draw when the pieces are in the same position with the same person to move for the third time. It is possible to repeat the position but change the opposition, which constitutes a different situation. tw

1 0

Reinventing the wheel, was Re: Proposal: some more standard remailer features
by Pat Farrell 17 Dec '03

17 Dec '03

In message Tue, 5 Apr 1994 22:50:46 -0700, hfinney(a)shell.portal.com writes: > This is reminiscent of MIME. Have you looked at that? They already deal > with encapsulation as well as message splitting, I think. You could copy > their message formats without committing to full MIME support. Plus it > might be possible to add encryption and remailing support to MIME mail > user agents by using the hooks they already provide. > One major reason that I pay attention to the IETF-EDI discussions on EDI over the Internet it to make sure that someone brings up encrypting EDI transactions. I'm convinced that EDI over the 'net will explode, and strong encryption (PGP, PEM, etc.) will be required. The IETF-EDI is basing their work on MIME. While it isn't perfect, it is an existing standard, has a published RFC, etc. I strongly second Hal's suggestion that developers of mailers and remailers look at MIME and use it as a starting point. Pat Pat Farrell Grad Student pfarrell(a)gmu.edu Department of Computer Science George Mason University, Fairfax, VA Public key availble via finger #include <standard.disclaimer>

1 0