December 2003 - cypherpunks-legacy

Re: Cryptography banned in the Netherlands....
by smb＠research.att.com 17 Dec '03

17 Dec '03

> So, among "liberals" we can include Reagan, J. Edgar Hoover, Joe > McCarthy, and Nixon, all of whom took some pretty extreme steps to > silence critics of "government and other large institutions," up > to and including political assassinations. Get real. With very few exceptions, the entire American political spectrum is made up of liberals. That most certianly includes Reagan, MaCarthy, definitly Nixon, and mabey Hoover. brad ``When *I* use a word,'' Humpty Dumpy said, in rather a scornful tone, ``it means just what I choose it to mean---neither more nor less.'' Reagan, McCarthy, Nixon and Hoover wouldn't call themselves liberals. We liberals certainly don't number them in our ranks. To call them ``liberals'' is to deny all meaning to the word. (Not that it's definition is clear -- but they sure aren't included.)

1 0

Politics do not belong here
by Jeremiah A Blatz 17 Dec '03

17 Dec '03

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. 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. This discussion is simply a bunch of messages that bait people with different political alignments than the sender's, please take it elsewhere. Jer darklord(a)cmu.edu | "it's not a matter of rights / it's just a matter of war finger me for my | don't have a reason to fight / they never had one before" Geek Code and | -Ministry, "Hero" PGP public key | http://www.cs.cmu.edu:8001/afs/andrew.cmu.edu/usr25/jbde/

2 1

tmp@netcom.com
by beker＠netcom.com 17 Dec '03

17 Dec '03

Organization: Oasis Pictures In addition to Tim's equating tmp@netcom with LD, here's some header info from an LD post on sci.crypt: From: ld231782(a)longs.lance.colostate.edu (L. Detweiler) Newsgroups: sci.crypt,comp.society.privacy,alt.privacy,sci.answers,comp.answers,alt.answers,news.answers Subject: Privacy & Anonymity on the Internet FAQ (1 of 3) Date: 12 Mar 1994 14:02:13 GMT Organization: TMP Enterprises

1 0

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