December 2003 - cypherpunks-legacy

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

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

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

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: Bekenstein Bound
by Jim choate 17 Dec '03

17 Dec '03

> > I know this is off topic, but as an astrophysicist I can't let it lie. > >First off, Black holes are singularities or points and have no volumes. > > Black Hole refers to the event horizon, the geometry is not nice inside that. > > > >Second, the 'surface' of the event horizon is a fractal and is therefore > >better represented by a volume. > > The 'surface' is not fractal. It is a simple bounded spheroid of finite area. > > > >Third, Black holes are not de-coupled from the rest of the universe, they > >emit 'Hawkings Radiation' which eventually leads to the evaporatio of every > >black hole, the bigger the faster. > > Blackholes evaporate through Hawking radiation the SMALLER the faster. > Stellar mass black holes will not evaporate in the age of the universe. > This radiation does not carry information about the interior. It is formed > from the quantum field just above the surface. > > > >Fifth, volume is not an issue because several accepted theories imply a > >'many worlds' type of reality. Some of these theories even allow a certain > > > >amount of information to leak between them. This occurs because when the > >Hamiltonian is constructed some states prevent or exclude other states and the > >state space turns out to be smaller than at first apparent. > > This is philosophy not physics. > > > >Sixth, everyone (incl. me initialy) was discussing QED in exclusion. This is > >completely incorrect. You must include QCD and it is a complete unknown at this > >point. When QED succeded because of Feynmann the tools were applied to the > >Quantuam Chromodynamics of Quarks and it has not solved any problems. > > I have no idea what you are trying to say here. > > -------------------------------------------------- > Lance Cottrell who does not speak for CASS/UCSD > loki(a)nately.ucsd.edu > PGP 2.3 key available by finger or server. > > "Love is a snowmobile racing across the tundra. Suddenly > it flips over, pinning you underneath. At night the ice > weasels come." > --Nietzsche > > > I appreciate your feedback. From what I have read of Hawkings and others work I would have to disagree w/ your statements that a black hole is equated w/ the event horizon. In every text (incl. the Hawkings book from the 70's on the subject) to makes a clear distinction. Several years ago (around '90) there was a whole raft of work dealing w/ the event horizon and the consensus that I got was that the event horizon was a fractal. Perhaps you would site some references where this theory is not accepted and a argumetn as to why it fails? What I am saying as far as QED/QCD is that w/o discussing both then the actions of electrons and photons are not quantum mechanical in the sense that they require statistical terms to describe their behaviour. Nowhere in Maxwells Equations is there a statistical term. If you know of a hole in the equations please let me know of it. I am not aware of any behaviour of electrons/photons which are not covered by these equations until hadrons are introduced.

2 1

DEATH TO THE
by rjc＠gnu.ai.mit.edu 17 Dec '03

17 Dec '03

re: Hal's suggestion I don't think that banning multiple recipients solves the whole problem which is the spamming of the remailer network by cybervandals like Detweiler. What needs to be done is to create some system that "charges" remailer requests to the sender which then limits the size or frequency of their messages based on their ability to pay. For a play money system, the issue is, how do you distribute the play money accounts without letting spammers open up as many accounts as they like? (e.g. if Detweiler spends his one account dry with his cyberterrorism, how do we prevent him from opening up an unlimited number of accounts without trying to attach accounts to a user's e-mail address?) By making remailers charge users, and even other remailers on the network, we can also prevent rogue remailers from allowing Detweiler attacks through the network (since they'd have to pay for his traffic) Here's a nutty idea I had one night which would accomplish these goals and also encourage more people to run remailers: o each remailer upon being setup distributes a large but finite amount of digicash certificates. These certificates are one use only. The initial distribution and price system can be altered to tailor the usage of the remailer to the owner's wishes. o after the initial distribution, the remailer distributes a somewhat smaller amount of digicash each renewal period (probably once a week) This smaller amount is sufficient for casual use, but not abuse o if you want more than what a remailer is willing to give you, you must trade service for it. That is, you must set up your own remailer and issue some cash to the other remailer which can be redeemed for chaining service. Example: Bob was unsatisified with his $10 of Ann's remailer coupons, so he set up his own remailer and issued $100 worth of service to Ann, in return, she gave him $50 of service for her remailer. (obviously, her remailer is more popular and is more in demand so his is only worth 1/2 of hers. Ann could use bob's coupons to either chain requests through him, or she could sell them off to other remailer operators.) The hard part is making sure that Bob doesn't cheat, offer to run a remailer, issue $X worth of credit to Ann, and then just file her remail requests to /dev/null I'm hopeful that a "consumer reports" like organization will pop up which periodically tests remailers to make sure they aren't cheating. (besides, the remailer network itself should do such testing with fake traffic) Call it "the free market of remailers" Other issues: How to distribute coupons/stamps/dollars? First come first serve? Popularity/Reputation? Reputation market? We want to prevent people from collecting digicash certificates multiple times during distributions, but at the same time, we don't want to use their real e-mail address. So in a system where users can create as many identities as they wish, how can we achieve a fair distribution? The only thing I can think of is to distribute cash to users based on their reputation or trust level. If a Detweiler is found abusing remailers, operators simply stop giving him cash for their remailers. Remailers which sanction Detweilers end up paying for them in the long run. (either because he runs up the costs for the remailer to use other remailers on the network, or because the operator gets too many complaints from systems which it directly delivered Detweiler mail to) Anyway, limiting multiple recipients will stop geometric growth, but it won't prevent Detweiler from hacking up a script to send a hundred thousand remail requests posting to every newsgroup and mailing list out there. Remailers would also have to limit the amount of remailer requests allowed per day, but this would still allow Detweiler to spam up the system by preventing anyone else from using it (by running out the global quota) Some sort of authentication is needly, IMHO. -Ray -- Ray Cromwell | Engineering is the implementation of science; -- -- rjc(a)gnu.ai.mit.edu | politics is the implementation of faith. --

1 0

Code Obfuscation
by garet.jax＠nitelog.com 17 Dec '03

17 Dec '03

>ÿTimothy C. May adds: >Hal Finney writes: >> The other issue, which I know less about, is the possibility of cryptograph- >> ically strong obfuscated code. Mike Duvos first mentioned this. You could >> have an algorithm running on your own computer and have it be impossible to >> determine what it is doing, or (presumably) to effectively alter the >internals >> of the algorithm. >.....stuff detiled.. >> discussing here (self-decrypting code and such tricks), but rather some >> mathematically strong transformation has been done on the structure of the >> code to hide it in a cryptographically strong way. >> >Brad Cox, of Objective-C notoriety, and now at George Mason >University, has also been interested in this area of "complexifying" >code so that reverse engineering is difficult or impossible. Okay if you want to obfuscate your code on a much more secure level albeit with some execution penalty, build public key encryption into the CPU. One would simply compile the program and encrypt it using the public key of the chipset (680xx, 80x86, &c), then the CPU would decrypt and execute the code on the fly using its private key.

1 0

Hi... :)
by lile＠netcom.com 17 Dec '03

17 Dec '03

I would like to join this alias/list. Please direct mee to the list server or wjhoever I need to talk to about getting added. thanks, -lile ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lile Elam | "Remember... No matter where you go, there you are." lile(a)netcom.com | Un*x Admin / Artist | Buckaroo Banzai ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0