December 2003 - cypherpunks-legacy

Re: Collapse of the Wave Function Predicted, Timing Uncertain
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

>> The moniker -- Information Highway -- itself seems to be >> responsible for SB #040194. Introduced by Senator Patrick Leahy, >> it's designed to prohibit anyone from using a public computer >> network (Information Highway) while the computer user is >> intoxicated. I know how silly this sounds, but Congress > > ....rest of Dvorak's April column elided.. > > Further provisions: How about... ---------------- THE WAR ON DRUGS REACHES THE BEACHES OF CYBERSPACE WASHINGTON(AP) Prompted by the rising number of reports of online addiction, Congresswoman April Fhurst is preparing a bill that would designate network connections a controlled substance. Only government certified professionals would be allowed network connections, and only for a limited number of hours per day. The bill also mandates that all network venders, manufactures of network equipment, and network software developers must design in mechanisms to record the length of time each person spends accessing a networked resource and to automatically contact the DEA when a person exceeds safe limits. Use of unauthorized or noncompliant network devices, computers, or software will be a felony. Any equipment used in the act of felonious network access, and any files obtained via the network would be subject to forfeiture under the RICO laws. ---------------- Jim_Miller(a)suite.com

1 0

Re: Politics do not belong here
by greg＠ideath.goldenbear.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Jeremiah Blatz writes: > I may very well be completly wrong here, but IMO there is no place for > politics on this list. Cryptography, by its very nature, is an > anti-political thing. I disagree here - politics is what makes Cypherpunks different from a sci.crypt mailing list. As Eric Hughes points out, cryptography is economics - and politics is economics with the gloves off. Crypto is inherently political. ("political" doesn't have to mean liberals - v. - conservatives.) > All politicians who try in increase the power of > government are against the cypherpunk agenda of increasing the use of > encryption, it doesn't matter what party they belong to. Be careful the way you use the word "agenda", you're gonna get Detweiler all worked up again. I don't think there is one agenda shared by all list subscribers. As I see it, "cypherpunks" follows the Earth First! model of (dis/anti) organization - there are no leaders, there is no "policy", there is no voting, there is no platform. There are folks who do what they choose to do, and putting a name on it makes it easier to talk about. Myself, I'm not so wound up about getting everyone on the planet to use crypto as I am interested in making sure we all can if we want/need to; and that's mostly useful insofar as it more clearly delineates a boundary to the power/ability of the state. > This discussion > is simply a bunch of messages that bait people with different political > alignments than the sender's, please take it elsewhere. I do agree that baiting and flaming are useless. The list is interesting because it's where folks with different interests/talents/orientations intersect, not where we diverge. Our differences and disagreements are significant but they can also distract us from shared goals. -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLZ34an3YhjZY3fMNAQF9xQQAgAJp7WXDmZre7mKMQpNZUOGQsc/bMTlw BD7xtXO12cbpIh4bgCt2N9ekogCBwrC9+y8ll0rL/rJ9UyuCkpgurrTElSROot8R umN+l5ENRiZKG3VeAE+FbbYIzQfMV4FBN1VaOQsRldMBPwbA0pRgJ8BsjFvSC//R lWf2xtUtkCc= =DYQ+ -----END PGP SIGNATURE-----

1 0

Secure deletion
by dwomack＠runner.utsa.edu 17 Dec '03

17 Dec '03

Gentlemen: Mr. Mike Watson, who writes an encryption program named "Enigma 2.2" based on DES also writes a really nice deletion program for the Macintosh. Burn 2.0 is FREEWARE, and will overwrite with 0's, with 1's, with random 1's and 0's...even with your own pattern. You can also erase all free space on the HD...and you can choose the number of passes. If you want a copy, I'll be glad to send you one...and, if you want me to upload a copy to a site, please pass on any suggestions. I don't know about ITAR restrictions, so I probably won't go outside the US and Canada; what the rest of you do is your biz... Regards, Dave

1 0

Re: Politics do not belong here
by Julietta 17 Dec '03

17 Dec '03

Jer- I'm sorry, but I feel so strongly about your message "Politics do not belong on this list" that I was compelled to reply... Where else should the poltical implications of encryption be discussed, if not amongst those who are most involved in its creation and proliferation? The political use and misuse of power is central to the issues regarding encryption, and these ramifications should be discussed as the technology is in its infancy. Encryption technology can be used as a tool to empower the individual, or it can be used as a means to lend a false security to the individual in his communications. If in fact the Clipper Chip with its easily obtainable (by government agencies) escrow keys is allowed to be implimented, we may in fact be assisting the government to effect a survelliance state of a maginitude never before seen in society. As American homes become host to "interactive" technologies, we need to realize the increased ability this brings for surveillance by both government and capitalistic enterprises. Encryption is one viable solution to re-instate the privacy equlibrium in the face of such a condition- this is where its power lies. Encryption, then, is not merely a mathematical tool, but also a sociological one; to discuss merely the technological and not the social and moral implications of this techology would be to not realize its full potential as a mediator to the coming state of "Big Brother is watching You". Politics, then, is not periferal but central to the discussion of encryption technology. Julie __________________________________________________________________________ Julie M. Albright Ph.D Student Department of Sociology University of Southern California albright(a)netcom.com

2 2

REMAIL: standardized remailer syntax
by nowhere＠bsu-cs.bsu.edu 17 Dec '03

17 Dec '03

Sameer writes: > Here's my suggestion.. > > Header pasting: > The '::' header pasting syntax should be available-- i.e. when >a message comes into a remailer with a body starting with '::' the >lines following until a blank line are pasted into the header. > > The '##' header pasting syntax-- when a remailer is sending >out a message, if the body begins with a '##' line then the lines >following that are pasted into the header of the outgoing message. > > Header commands: > "Anon-To","Request-Remailing-To": strips headers and sends the >message to the specified recipient. Both of my remailers (nowhere(a)bsu-cs.bsu.edu and remailer(a)chaos.bsu.edu) support all of the above as of 4/2/94. > "Encrypted: PGP": The message has a pgp block encrypted with >the remailer's key. The remailer will decrypt the pgp block before >acting furthur upon the message. Neither of my remailers supports encryption. The bsu-cs one has too small of a quota and I haven't compiled PGP for the chaos one yet. I will write more later, but basically what you need to know is this: 1. The bsu remailers no longer paste ANYTHING from a "::" header into the header of the outbound message. 2. They both support the "##" header pasting syntax now. The "##" block must come after the "::" block if both are being used or else the "::" block will be considered part of the body of the message. 3. They also support multiple recipients. You can place as many "Request-Remailing-To:" lines in the headers as you wish and it will individually address and send each one. 4. Full debug logging has been turned on until I can verify that both remailers are acting as they should. This form of logging includes a mirror of the message as it is received and a one-line message listing each recipient. 5. The C source is available via anonymous FTP at: chaos.bsu.edu:/pub/cypherpunks/remailer/chaels-remailer.tar.gz It should compile as long as you have getopt(). There is no fancy signal processing in this version. Note that there is nil documentation. This is not a release. Apparently my other posting got eaten somewhere between here and toad... Oh, well! Chael -- Chael Hall nowhere(a)bsu-cs.bsu.edu 00CCHALL(a)BSUVC.BSU.EDU nowhere(a)chaos.bsu.edu chall(a)bsu.edu

1 0

DEATH TO THE
by Hal 17 Dec '03

17 Dec '03

One thing worth noting about the burst of remailer messages is how much worse it could have been. Each message was sent to many remailers, with requests to send it on to many more. Potentially the message could be duplicated n-fold at each step, until horrendous numbers of messages were circulating through the remailer network and being sent to the other destinations. Luckily, this didn't happen, apparently because most remailer software does not support multiple recipients. But the lesson is that as people deploy new remailers and improve the software, "multiple recipients" should *not* be added as a feature, IMO. Doing that would make the network vulnerable to these kinds of geometric-growth attacks. It would be so easy to do it that people would probably be tempted to try just for kicks. So I think this feature should definately be left out of future remailer plans. Hal

1 0

REMAIL: standardized remailer syntax
by Hal 17 Dec '03

17 Dec '03

From: nowhere(a)bsu-cs.bsu.edu (Chael Hall) > Sameer writes: > > > Here's my suggestion.. > > > > Header pasting: > > The '::' header pasting syntax should be available-- i.e. when > >a message comes into a remailer with a body starting with '::' the > >lines following until a blank line are pasted into the header. > > > > The '##' header pasting syntax-- when a remailer is sending > >out a message, if the body begins with a '##' line then the lines > >following that are pasted into the header of the outgoing message. I like Sameer's goal of standardized syntax, but I have to admit that I find the :: and ## bit confusing, and hard to explain. The way Eric Hughes' original remailer worked was that the "remailer commands" were in the message header, up with Subject and In-Reply-To and such. However, many mailers won't let people put custom material there, so the "::" pasting token was invented to take the following lines and put them into the header before the remailer processed them. The effect was that you could put remailer commands after "::" and they would work. But there were also some situations in which the user might want to control message headers as they *leave* the remailer. For example, they might want to put a Reply-To to some anon pool so that they could receive reply messages. So Eric created the "##" pasting token for those. The remailers based on his scripts first look for "::" and add in any headers following it; then they process the message, looking for command lines in the header; then as they remail it they look for "##" and stick any following lines in the outgoing message header. This all makes sense but it makes for a complicated system. I think people would find it easier to understand an approach in which they put remailer commands at the top of their message, marked in some way to separate them from the rest of the message. "::" on a line by itself could indicate the beginning of a block of remailer commands, terminated by a blank line. Or, as an alternate syntax, each remailer command line could start with "::" followed by the text of the command. Both approaches have been used by different software on the net and they could be considered two different ways of expressing the same thing. This would get away from the add-to-header/process-header/add-to-header approach of the current Perl remailer scripts and use a simple one-step "process remailer commands" approach which I think would be simpler. You could still have all the functionality of the current approach (perhaps a paste-outgoing-header command could be used for the "##" functionality) in a package which is conceptually simpler (to me, at least). Another advantage of this approach is that you could make use of the order of the commands in the remailer block so that you could have finer control over what you are asking the remailer to do. > > Header commands: > > "Anon-To","Request-Remailing-To": strips headers and sends the > >message to the specified recipient. I would suggest abandoning one of "Anon-To" or "Request-Remailing-To", as they are redundant. I know above I suggested two redundant ways of specifying remailer commands; maybe that should be reduced to one, as well. > 1. The bsu remailers no longer paste ANYTHING from a "::" header > into the header of the outbound message. Many of the remailers pass Subject lines. I don't think they should. Chael's approach makes sense to me. The best thing is to have a way to set the subject as the message leaves the last remailer in the chain. (My "chain" program does this automatically.) > 3. They also support multiple recipients. You can place as many > "Request-Remailing-To:" lines in the headers as you wish and > it will individually address and send each one. I sent mail a few minutes ago (before seeing Chael's message) suggesting the danger of this in making it easy to create huge numbers of messages. > 4. Full debug logging has been turned on until I can verify that > both remailers are acting as they should. This form of logging > includes a mirror of the message as it is received and a > one-line message listing each recipient. We have had a lot of talk about logging. My feeling is that one should get security in using the remailer network by going through a number of machines in widely different regions. It should not, as was suggested here some time ago, be a matter of trusting any given remailer operator. Privacy is not a gift being provided by remailer operators to their users. It is still some- thing that the users must provide for themselves. The remailers are just a tool to help achieve that. Thanks to Chael for re-kindling this discussion. Hal

4 3

Re: tmp@netcom.com
by cfrye＠mason1.gmu.edu 17 Dec '03

17 Dec '03

I'm not sure what the time-delay features for the "nowhere" anonymous remailer ler are, but the messages that arrived last night all came through within a few minutes. Interestingly, the messages were sent at around 3:00 am, corsimilar to LD's posting patterns from before. I deleted the most recent postings, but if someone could send them to me, I'd like to run them through a grammar checker and compare the results to the message base I developed before. Curt

1 0

MAIL: prank
by Karl Lui Barrus 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >The Zimmerman prank---I'm sure not funny for him---hardens my line >further against anonymity online. At its best, as here, it is an >unholy nuisance. Why? If you think about it, the prank doesn't demonstrate why anonymity is bad - it could have been off with ordinary mail forgery. What is does demonstrate is the need for digital signatures and authentication. In the future you would just ignore an announcement of this sort if it doesn't have a valid digital signature. Karl L. Barrus klbarrus(a)owlnet.rice.edu -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLZ9wY4OA7OpLWtYzAQHV1gP+IXt0zpdjh+97V9I6SASc29dWW2JZR5QV kI7EJyk5e6/gacULgr+nkGz4KAPIImQ6M4+QNDjplxnRwrwrljSMPewqZLpd1REF kZWGC8rnKOxFlwuXamMCF8+0+3+XrGqCxD6H2WuOGVZ82nUc5fHO25nNDes0B2tp /nf9TI8+zYY= =kyRX -----END PGP SIGNATURE-----

1 0

Positive uses for PGP
by Philip Zimmermann 17 Dec '03

17 Dec '03

To all PGP users: We've all heard arguments raised by the law enforcement and intelligence communities that PGP and other encryption technology can be used by criminals to hide their activities. This line of reasoning is being used to justify Government key escrow systems like Clipper, and to clamp down on encryption technology like PGP. It would be helpful to come up with real-world examples of how PGP has been used for good constructive purposes. Journalists sometimes ask me for examples of positive uses for PGP. But most of my fan mail from PGP users do not tell me what they are using it for. If you have any stories about how PGP is used for good purposes, I'd like to see them. Not just disaffected paranoid libertarians embracing it for the theoretical benefits for a free society. We need to be able to cite examples of real people using PGP for good ends. Human rights activists using it are a great example. But it doesn't have to be in the Nobel-Prize winning catagory of human endeavor (although that would be nice). It could just be any positive upbeat application that normal people can relate to in a positive way, so I can tell reporters about it. I'd like to hear (actually, see some email) from real people who are actually using PGP for good things. It could be for helping others, like protecting HIV patient records, or keeping psychological counseling records. Or conducting good wholesome business that must remain confidential. Or lawyers using it to maintain confidential records and communications with their clients. Or, it could be for your own personal life, but for wholesome upbeat uses, like sending love letters (you don't have to supply any actual love letters), or keeping your diary. For those that don't know what PGP is: Pretty Good Privacy (PGP) is a free software program that encrypts email using public key cryptography, allowing you to communicate securely with people you've never met, without the prior exchange of keys over secure channels. PGP has become the worldwide de facto standard for email encryption. It's available on many Internet FTP sites and BBS systems. Please send me some email (to prz(a)acm.org) with the subject line "Positive uses for PGP", so that I can quickly sort it out from the rest of my email. If it's a really good story, I may want to use it, so let me know if I can and if I can give reporters the information. You might not get a reply-- it depends on how much mail I get or how busy I am when you send it. There is no prize for the best story, but for what it's worth, I'll sign the public key of the person who submits the best story by Monday, April 11th. But keep sending stories after that date if you've got them. This notice can be copied and reposted on any newsgroup or mailing list that is likely to be familiar with PGP. Philip Zimmermann prz(a)acm.org

5 5