December 2003 - cypherpunks-legacy

Re: PGP mail disabled ???
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

> No, of course they were using the -a option and the > mail was normal ASCII armoured. Some of the FIDO and FIDO-like networks have policies against sending encrypted email. I don't know if this means their operators actually read the messages that go by, or do pattern-matching to look for "BEGIN PGP" or whatever, but they at least have that policy.

1 0

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

17 Dec '03

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. 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 The following is an envelope: ::envelope PGP [optional keyID] ----- BEGIN PGP ... ----- ..... ----- END PGP ... ----- ::end PGP I have defined several types of envelopes for the workings of my remailer, one of them is for internal packetizing/splitting of large messages. ::envelope PACKET part#/partmax:idstring For example ::envelope PACKET 1/5:<aa1024xaf#remailername> [important data] ::end PACKET When creating envelopes, I escape any commands/escape chars inside them by preceding the command line with '\'. This is removed when removing the envelope. The other envelope I have defined is "PAD startline:endline" When removing this envelope, the remailer simply deletes lines numbered startline to endline in the message. The first line is 0. Header formating: 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 Depending on how the remailer is set up, incoming subject headers may or may not be preserved. Anonymous Posting: On any mailer which supports virtual addresses, the following special feature shall be implemented: If the virtual address contains any '.' characters, the address is first assumed to be a newsgroup. If the newsgroup exists and/or it is not blocked by the operator, two possible actions can take place. 1) if the variable NNTPSERVER is defined, the remailer will open a tcp connection and post the message directly to the newsgroup specified in the virtual address 2) if not condition 1, then if the variable NEWSGATE is defined, the remailer will mail your message to newsgroup@NEWSGATE doing any translations on the address string as needed. e.g. NEWSGATE=cs.utexas.edu, it sends the message to alt-news-group(a)cs.utexas.edu 3) else posting is disabled (visible flag in the remailer list) Example: ::to remailer1#remailer2#talk.politics.crypto If asked, I will supply the magic perl subroutine needed to do this. [note above, I have eliminated the redundant "request-remailing-to". When mailing through a remailer, you know the mail is going to be remailed. ::to is easier to type] 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 ::envelope PGP [below is encrypted] ::envelope PACKET 1/2:#xxyyblahblah ::to darkmodem ::@Subject Hello World <part one of the message> ::end PACKET ::end PGP ::envelope PGP [below is encrypted] ::envelope PACKET 2/2:#xxyyblahblah <part two of the message> ::end PACKET ::end PGP 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) Most of the envelope I/O is hidden from the user. Additional ideas: A command ::error-to to specify where errors encountered during processing of the message should be sent. e.g. ::error-to idstring an99999(a)anon.penet.fi or ::error-to idstring alt-waste(a)cs.utexas.edu [idstring will let you know which message the error was for] I also propose ::route which would specify preferences preferred for remailers when searching for other remailers to chain your message to. e.g. ::route Private [attempt to chain to remailers which are running on single-user non-public machines first] ::route Stealth [don't use sendmail if possible, use socket-to-socket delivery remailers first] Comments welcome, -Ray p.s. most of the above proposals are not complicated to code for -- Ray Cromwell | Engineering is the implementation of science; -- -- rjc(a)gnu.ai.mit.edu | politics is the implementation of faith. --

2 1

Al Haig and Secure Communictions
by Black Unicorn 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- About two weeks ago while making a point about the absurdity of taking government on its word, I mentioned an 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. Among other points, I indicated that there was significant reason to doubt bald assertions made by government officials, especially in a public relations capacity. One of the examples I used relied on the events following the attempted assassination of President Reagan, (who's name I then spelled incorrectly). Specifically I noted that Secretary of State Haig appeared before the press and announced (in some form or another) that he was in charge. The implication in my statement was that Secretary Haig was not in charge at all, and that relying on government to operate by its own rules, even with the scrutiny of the press is silly. An irate Haig supporter, who also defended the President's name (by correcting my spelling error anyhow) insisted that this event was a big fabrication by the press and that indeed Secretary Haig was in authority in some way or another. He insisted the press had blown the issue out of proportion. I was forced out of town for some time, and was unable to reply immediately. I bring up the point now to clarify my information, and to tie in some interesting concerns regarding secure communications and operations in a Emergency. 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. The first sixteen successors in the Presidential line of succession are: 1. The Vice President 2. Speaker of the House of Representatives 3. President pro tempore of the Senate 4. Secretary of State 5. Secretary of the Treasury 6. Secretary of Defense 7. The Attorney General 8. Secretary of the Interior 9. Secretary of Agriculture 10. Secretary of Commerce 11. Secretary of Labor 12. Secretary of Health and Human Services 13. Secretary of Housing and Urban Development 14. Secretary of Transportation 15. Secretary of Energy 16. Secretary of Education. 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. etc. When President Reagan was injured, and the Vice President (George Bush at the time) was out of town, the successor to the Presidency was the Speaker of the House, Tip O'Neill. The Secretary of State was two more rungs down the ladder. The Secretary of State appears nowhere in the command authority side of succession. Casper Weinberger was the then Secretary of Defense and next in line there. Al Haig's source of sovereignty? Control of the national media? Perhaps that's a touch conspiracy oriented, but how does the proper authority convince the citizenry that he or she should be followed when another authority figure is effectively seizing the reigns? Herein lies the stuff of constitutional crisis. It is the responsibility of the Federal Emergency Management Agency to keep track of the Presidency and the line of succession. The question becomes, if a figure claims authority how is this verified, and enforced? Former FEMA director Giuffrida: "One of the things we discovered is there was no authentication system.... if [someone] got on the horn and said, 'I'm the successor,' and somebody said 'prove it,' [no one could]." Of course this was some time ago, but how much things have changed is a real question. It seems to me that the Unites States has never recognized the potential problems that national crises may cause. I cite a particularly interesting tale that might be amusing if it were not so alarming. On the presidential emergency evacuation procedures from National Security Advisor Brzenzinski's Memoirs: I called in the person responsible for evacuating the President in the event of a crisis. I obtained a detailed account on how long it actually would take to evacuate the President by helicopter.... I ordered him to run a simulated evacuation right now, turning on my stopwatch. The poor fellow's eyes...practically popped: He looked so surprised. He said, "Right now?" And I said "Yes, right now." He reached for the phone and could hardly speak coherently when he demanded that the helicopter immediately come for a drill. I took one of the secretaries along to simulate the First Lady and we proceeded to the South Lawn to wait for the helicopter to arrive. It took roughly two and a half times longer to arrive as it was supposed to. We then flew to a special site from where another evacuation procedure would be followed. To make a long story short, the whole thing took roughly twice as long as it should have. Moreover, on returning we found that the drill somehow did not take into account the protective services and we were almost shot down. There have been significant changes in technology no doubt since the Carter Administration. For one thing fiber optics seem to present some resistance to EMP effects that before threatened normal lines of communication, but how have authentication methods changed? It seems to me that there are great potentials for advance in authority authentication with new technologies not limited to and newer than public key cryptography. On the other hand it seems the United States culture of vulnerability, justified by theories of Mutually Assured Destruction or budgeting concerns, is so strong that such advances would never take hold in a meaningful way. Can you see a reporter in the famed President Haig press conference asking: "Excuse me Secretary Haig, may we examine your FEMA signed authority key?" - -uni- (Dark) -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLaI9HxibHbaiMfO5AQEBZgP/fZaGM/WG4sgJuqmmn/uBgLIoUzn9bBe1 CDaOUYzCvyssFWp23qIqXZMgKVorxQXIObbKORFSfG2Nj+n3gcyKF2oRUtrbqmsT oam6h+wABTpawNt2Kc3P0MwwX9QyHK/afPNpuztwCntdvCOmXd3YHybQ5dLHAk5d ku9cQlHjMBo= =Qz+l -----END PGP SIGNATURE-----

1 0

San Jose Mercury News Article
by wwweb＠aol.com 17 Dec '03

17 Dec '03

SAN JOSE MERCURY NEWS Copyright 1994, San Jose Mercury News DATE: Sunday, April 3, 1994 PAGE: 1F EDITION: Morning Final SECTION: Computing LENGTH: 41 in. Long ILLUSTRATION: Drawing SOURCE: SIMSON L. GARFINKEL, Special to the Mercury News KEEPING SECRETS SECRET ENCRYPTION SOFTWARE SPARKS DEBATE OVER PRIVACY LAW ENFORCEMENT AGENCIES CONTEND UNFETTERED ENCRYPTION POSES A THREAT TO INTELLIGENCE GATHERING, COURT-ORDERED WIRETAPS AND THE EXECUTION OF SEARCH WARRANTS. IN THE last year, a piece of public domain software has become the bane of the FBI, the rallying cry for a new generation of anti-government radicals and the focal point of an international debate about privacy on the information superhighway. Pretty Good Privacy allows two people anywhere in the world to exchange electronic mail messages by telephone or over the Internet in absolute and total privacy. PGP accomplishes this feat of technological magic with a technique called public key encryption, the newest twist on the time-honored technique used by spies for protecting their messages from interception by the enemy. What's significant about PGP, say both its admirers and critics, is that the encryption it uses is so powerful that PGP-protected messages cannot be forcibly decrypted, or broken, by even the world's most sophisticated code breakers. ''The problem is that guaranteeing privacy to everybody will guarantee privacy to people who are going to misuse that technological sanctuary,'' said Stewart Baker, general counsel of the National Security Agency, addressing the fourth annual conference on Computers, Freedom and Privacy last week in Chicago. The nation's intelligence and law enforcement establishments have mounted a crusade against unfettered encryption in general and PGP in particular, saying they pose a serious threat to intelligence gathering, court-ordered wiretaps and the execution of search warrants. ''With respect to PGP, the only use that has come to the attention of law enforcement agencies is a guy who used it so police couldn't tell which little boys he had seduced over the Internet,'' Baker said. PGP users at the conference said such characterizations are grossly unfair. The overwhelming majority of people using PGP, they said, are law-abiding individuals who simply wish to protect their communications from the prying eyes of computer hackers and unscrupulous system administrators. ''If privacy is outlawed, only outlaws will have privacy,'' said Phil Zimmerman, the Colorado-based*cryptography*consultant who wrote the first version of PGP in March 1991. That year, the U.S. Senate considered an amendment to the Anti-Crime Bill of 1991 that would have made it illegal to use encryption within the United States unless law enforcement agencies were provided with a copy of the keys. Although the proposal was ultimately withdrawn, it put the electronic underground on notice that widespread encryption might be outlawed by government before most people even realized what encryption was all about - or its value for protecting individual privacy. Zimmerman's solution was to write PGP and flood the country with high-quality cryptographic software. Leveling the playing field ''Intelligence agencies have access to good cryptographic technology,'' Zimmerman wrote in the PGP manual. ''So do the big arms and drug traffickers. So do defense contractors, oil companies and other corporate giants. But ordinary people and grass-roots political organizations mostly have not had access to affordable 'military grade' public-key cryptographic technology . . . until now.'' While personal computer-based encryption programs have been available for years, Zimmerman's PGP was the first to bring public-key encryption - which is ideal for encrypting communications to a variety of people - to the masses. Most*cryptography*programs available for personal computers use private-key*cryptography.*With private-key schemes, the same encrypting ''key'' is used to encrypt and to decrypt any given file. This means you can't exchange encrypted e-mail with somebody unless you first exchange a cryptographic key. Public-key cryptographic systems, first developed in the 1970s, use two keys. The first key is called the public key; it encrypts the message. But it takes a second key, called the private key, to decrypt the message and recover the original text. The big advantage of public-key systems is that the public keys of many people can be gathered and published in electronic address books. Then, if you want to send somebody an encrypted message, all you have to do is look up her key and use it: No prior arrangement is necessary. Launching the Clipper One year ago, the National Institute of Standards and Technology, working in conjunction with the NSA, proposed a system for encrypting communications within the United States called the Clipper chip. Like PGP, Clipper uses public-key encryption so that any two Clipper chips can communicate with each other without fear of wiretappers. But Clipper also uses a system called key escrow to make it possible for law enforcement agencies - with authorization by a court of law - to wiretap an encrypted conversation. Key escrow means the private key used by each Clipper chip is held in a central repository. The Clipper system actually splits the key into two parts, each stored with a different agency, to minimize the chance of an illegal wiretap. The agencies are supposed to give up their copies of the private key only when they are presented with a warrant for a wiretap. This March, NIST published a notice in the Federal Register setting forth Clipper as a voluntary encryption standard for the federal government. By endorsing an encryption standard, the Clinton administration hopes that telephones, faxes and modems implementing a compatible encryption system will soon be widely available. ''The rationale behind the Clipper and key escrow is to lower the cost, to make encryption tools available to a large number of people while maintaining the ability of the government to do the 1,000 or so authorized wiretaps every year,'' said David Lytel, a policy analyst with the president's Office of Science and Technology Policy. ''If you don't think Clipper keeps your communications secure, don't use it,'' said Lytel. ''And if you want to use your own encryption on top of it, go ahead.'' Many people at the Computers, Freedom and Privacy conference said they would avoid Clipper and added that it was likely that drug dealers, organized crime and terrorists would do the same. ''The administration can't come up with examples of criminals bright enough to use encryption in the first place but dumb enough to do it with the government's chip,'' said Charles C. Marson, a San Francisco-based lawyer. Nevertheless, many organizations might be interested in telecommunications systems based on Clipper, said the NSA's general counsel. For example, said Baker, a company might prefer that its employees use a system like Clipper, which provides security but can be wiretapped in extraordinary circumstances, so it can monitor its employees should the need arise. The next generation To use Clipper, however, these organizations will have to wait for manufacturers to build the expensive Clipper chips into the next generation of telephones. In the meantime, PGP is a solid system that provides privacy today. PGP is free software, so if you have a friend who has it, you can simply make a copy. If you have access to the Internet, you can also get a copy from the computer SODA.BERKELEY.EDU using the Internet's File Transfer Protocol system. Companies and individuals who feel more comfortable buying their programs can now get a version of PGP that works on DOS and several Unix systems from Viacrypt of Phoenix. Most oppose Clipper plan Buying the program entitles you to customer support - important for people new to*cryptography.* Will the Clipper plan fly? No one knows. But a recent New York Times/CNN poll found 80 percent of the U.S. public opposed to the Clipper and key escrow when the proposal was explained to them, said Marc Rotenberg, director of the Computer Professionals for Social Responsibility's Washington office. On the other hand, Zimmerman and others like him say unrestricted*cryptography*is already making a difference around the world. As proof, he cites an electronic mail message that he received from Russia in October on the day that President Boris Yeltsin was shelling the Russian Parliament building. The e-mail said, in part: ''Phil, I wish you to know: Let it never be, but if dictatorship takes over Russia, your PGP is widespread from Baltic to Far East now and will help democratic people if necessary. Thanks.'' IF YOU'RE INTERESTED The public-domain version of Pretty Good Privacy is available on many bulletin board systems or can be obtained from the FTP site SODA.BERKELEY.EDU via the Internet. A commercial version is available from Viacrypt, 2104 W. Peoria Ave., Phoenix, Ariz. Phone: (602) 944-0773. Fax: (602) 943-2601. CAPTION: DRAWING: CHRISTINE BENJAMIN - SPECIAL TO THE MERCURY NEWS [An eagle, representing the US government, scans a flow of data from one computer to another to interpret encrypted data.] [940403 CO 1F; color] KEYWORDS: COMPUTER SOFTWARE PRODUCT ETHICS CRIME END OF DOCUMENT.

1 0

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