- cypherpunks-legacy - lists.cpunks.org

Eugene Kashpureff in custody
by Anonymous 17 Dec '03

17 Dec '03

Date: Sat, 01 Nov 1997 15:41:13 +1100 To: aussie-isp(a)aussie.net, link(a)www.anu.edu.au, aursc(a)lists.ah.net From: Adam Todd <at(a)ah.net> Subject: [Oz-ISP] Eugene Kashpureff in custody. Date: Fri, 31 Oct 1997 10:40:20 -0500 (EST) ---------------------------------------------------------------------------- RSCTALK Discussion List. Open. ---------------------------------------------------------------------------- Eugene Kashpureff, known for his redirect of the NSI web page, was apprehended this morning in Toronto by undercover RCMP detectives. Pending a deportation hearing, he will be returned to New York to face Felony Wire Fraud charges that were sworn out against him after he had settled out of court with NSI in regard to their civil suit. Early in the week Eugene relinquished control of the Alternic to an adhoc industry group. ---------------------------------------------------------------------------- It is alledged there are 40,000 individual charges being laid agains Euegene. It is strongly expected ISP's and DNS operators world wide will provide support to Eugene through RSC organisation to ensure his safe return. For more information contact the Author. ------------------------------------------------------------------------- The advice offered in this email is not considered professional advice, or it would be accompanied by an invoice. ------------------------------------------------------------------------- Business Development, Technology Domain Registration and Network Advisory Telstra Convery Member Adam Todd Personal http://adamtodd.ah.net Phone +61 2 9729 0565 Network http://www.ah.net AU Root Server Confederation http://aursc.ah.net AU Internet News mailto:internet-request@ah.net with "subscribe"

1 0

Reduce your taxes
by s67e3tG8D＠actrix.gen.nz 17 Dec '03

17 Dec '03

You were recommended for the following information. If it is of no interest to you, there is no need to respond as you are not on a mailing list with us, also if this doesn't interest you Please Hit Your Delete Button, my apology. Now for the first time ever, you have the opportunity to join the most extraordinary and most powerful wealth building program in the world! This program has never been offered to the general public until now! Because of your desire to succeed, you have been given the opportunity to take a close look at this program. If you're skeptical, that's okay. Just make the call and see for yourself. My job is to inform you, your job is to make your own decision. If You Didn't Make $200,000.00 Last Year... You Owe It To Yourself And Your Family To Give Our Program Serious Consideration! Also, when you start making this kind of money within weeks, after joining our team, you will actually learn how you can legally reduce your taxes up to 95%, and how to strategically invest your finances. I invite you to call for more details TOLL FREE 1-888-289-9705 call right now! This is a 2 min introduction. If you want more information, Leave a message and we will get back to you. Like I said, only if your serious. Inviting you to see what we really have, Cory. This Is Not Multi Level Marketing/Serious Inquiries Only Please.

1 0

BXA Agenda
by John Young 17 Dec '03

17 Dec '03

BXA has published its semiannual regulatory agenda scheduling the issuance of export rules for encryption, dual use technology, Wassenaar implementation, communications intercept devices, and, a new one (to me), controlling access to source code by foreign nationals, among other banes. http://jya.com/bxa-sra.htm (60K) Here's the abstract for GAK: ----- 604. LICENSING OF, AND EXPANSION OF NATIONAL SECURITY AND FOREIGN POLICY CONTROLS ON, RECOVERABLE ENCRYPTION SOFTWARE Abstract: This rule will amend the Export Administration Regulations by imposing enhanced national security and foreign policy controls on certain recoverable encryption to supplement the national security controls on those items. This rule will also amend the EAR to exclude recoverable encryption software from the de minimis provisions for exports from abroad of foreign-origin software incorporating U.S.- origin software. In addition, this rule amends the Commerce Control List by adding ECCNs to control recoverable encryption software transferred from the U.S. Munitions List. ----- FIM, all departments of the USG are required to pulished twice yearly (April and October) regulatory agendas for implementing rules devised to breed FAL outside GovBot and LAM within. See compendium of all agendas published October 29 under "Unified Agenda" at: http://www.access.gpo.gov/su_docs/aces/aaces002.html

1 0

Iridium satellite xceivers idea?
by Rich Graves 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Several months ago, someone was raving about getting Linux PCs and cheap satellite comms into Hong Kong in preparation for the mainland takeover so that the ensuing human rights violations could be documented. If there's anyone left on cypherpunks who knows or cares about that kind of thing, let me know. - -rich group 19 - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBMnr5qyoZzwIn1bdtAQHtWgF+J46Kz4kUiAdbZ8JWbiRPp5VSAfi4qAqk ZfMXNPh4ma/eUMBnxrDmfgKJuhdUGXcq =hUZX -----END PGP SIGNATURE-----

1 0

Re: apropos list talk and our culture
by Brian B. Riley 17 Dec '03

17 Dec '03

On 10/29/97 7:38 AM, Brad Dolan (bdolan(a)USIT.NET) passed this wisdom: >"Michael Hays" is a new CBS series about a U.S. District Attorney. Last >night's episode was about how a radio talk-show host incited a listener >to kill a BATF agent and was brought to justice. DA convinced a jury >that some things were "more important" than the first amendment. No that was not the point made, in fact the show made a strong point in favor of the first amendment. They went after the shock-jock because he specifically incited a specific individiual with words which we he knew would have an immediate cause and effect result in getting this guy to go out and kill someone. There is a difference, and I personally thought they made the point well .... now the accused did try to hide behind the first amendment but that was not what the first amendment is all about. You have to pick yopur mountains to die on in those arenas and the shock-jocks cause would not have been one I would have touched were I a Constitutional lawyer. Brian B. Riley --> http://www.macconnect.com/~brianbr For PGP Keys <mailto:brianbr@together.net?subject=Get%20PGP%20Key> "Never ask what sort of computer a guy drives. If he's a Mac user, he'll tell you. If not, why embarrass him?" - Tom Clancy

1 0

PGPsdk is out, but not for free
by lcs Mixmaster Remailer 17 Dec '03

17 Dec '03

More proof that the PGP folks have some kind of alterior motive. Translation: They created a software package which purposefully breaks the previous free versions of that package. Then they release a development kit for that package with outrageous licensing fees. Welcome to the new PGP Inc. >First, PGPsdk has been released: > http://www.pgp.com/sdk/ >The bad news: the licensing fees are so high that there will be no >freeware or shareware applications using it. Here's an example of the >licensing: >License Plan #1 > Authentication, Encryption/Decryption, > PGP/MIME, Key Management: $25,000 advance on >royalties + 2% of product revenues (minimum $1 per client and $35 per >server) >Add Certificate Server Integration: > $5,000 advance on royalties >Support/Upgrades > (includes email support by a trained > developer support technician) > $1,500 per year + 15% of royalty payments

1 0

PGPsdk is out, but not for free
by Anonymous 17 Dec '03

17 Dec '03

More proof that the PGP folks have some kind of alterior motive. Translation: They created a software package which purposefully breaks the previous free versions of that package. Then they release a development kit for that package with outrageous licensing fees. Welcome to the new PGP Inc. >First, PGPsdk has been released: > http://www.pgp.com/sdk/ >The bad news: the licensing fees are so high that there will be no >freeware or shareware applications using it. Here's an example of the >licensing: >License Plan #1 > Authentication, Encryption/Decryption, > PGP/MIME, Key Management: $25,000 advance on >royalties + 2% of product revenues (minimum $1 per client and $35 per >server) >Add Certificate Server Integration: > $5,000 advance on royalties >Support/Upgrades > (includes email support by a trained > developer support technician) > $1,500 per year + 15% of royalty payments

1 0

Re: Privacy Software
by Mix 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Adam Back wrote: >Monty Cantsin writes: >> The PGP source code is not the worst I've ever seen, but it's kind of >> odd. > >I had a go at doing something with it (I'll let you know when I get >it to work) -- I had the damnest job figuring out what was going on. >The problem I found with understanding it were all of the nested >functions called through vectors of functions and handler functions. >Makes it hard to inspect what will happen without running the code >under a debugger -- lots control flow is decided at run time. So in other words, even though we have the source code we don't really have confidence that we can tell what it is doing. Even though the source code is available, I don't think it has been studied all that carefully. For example, hardly anybody knew that the PGP 5.0 source had CAK features lurking in it. Or, remember that bug with the random number generator? As I recall (i.e., feel free to correct me), it was in Colin Plumb's code and he found it himself. This would imply that it got by whoever went over the code when it was released. Not reassuring. C is a big part of the problem. Also, PGP was originally designed to operate on some fairly slow machines and they tried very hard to optimize the hell out of it. Now, however, cycles are a lot cheaper. I think we should give up speed for clarity. Slow code that we can really trust is better. And, the PGP code does a bunch of careful things which complicate it like burning the stack all the time. In my judgement, this is misplaced. If you don't trust the platform you are using you can't fix it in your encryption code. >> We should consider a rewrite, which gives us the added benefit that >> it will be completely unencumbered. > >Sounds maybe worth doing. It's at least worth talking about. Hashing out the design is a good exercise and it can inspire other people when they are designing their own crypto systems. >> It also gives us the opportunity to write it in a language other than >> C, one which truly supports encapsulation. C code is hard to verify >> with great confidence because it is possible to obfuscate it and >> introduce security holes. This means that C requires one to trust the >> authors to a greater extent than is desirable. > >Some C programmers do have fun writing obfuscated chicken scratchings, >but you _can_ write C code optimised for readability. What's really bad is that any part of the code can betray the rest. Let's say you had somebody who was really very good who wanted to weaken things. All he or she has to do is have a little obfuscated code someplace that undermines the majority of nicely designed and implemented C code. A truly encapsulated language is a lot easier to verify because if none of the magic functions exist in the code (easy to check), you can be confident that when you have verified one piece of code that the other pieces can't interfere. >What language did you have in mind? modula-3? iso-pascal/borland >pascal? Hadn't thought of Modula-3, but that is an excellent idea. Java would be a candidate, although performance is an issue. There's been some good buzz around about Ada. It might perform well and it's here to stay. Is Modula-3 being used in any serious way by anybody? If it is, let's consider it. (I think there is a Modula-3 -> C compiler out there someplace, which means it's totally portable.) A good language choice would probably save a lot of time. >> The whole issue of compatibility is an interesting one. Would it be a >> good idea to have a cryptographic system which was completely >> incompatible with PGP, given the Big Brother risk? > >Theoretically perhaps, however I'm not sure a system will get very far >unless it can automatically interoperate with pgp2.x and 5.x. It would be nice to just shed the PGP baggage for the moment and think about how we would do a system from scratch for our own uses. Ultimately, this system could reside in an application which also speaks PGP. Or, it could just be its own thing. >You could build something which did the right thing automatically >based on public key types: > >hypothetical cpunks mail system (HCMS) We should use the acronym CMR. (Cypherpunk Message Remodel? Suggestions invited.) >HCMS -> pgp2.x use RSA/MD5/IDEA and pgp2.x message formats >HCMS -> pgp5.x use DSA/EG/3DES/SHA1 and pgp5.x message formats >HCMS -> HCMS use whatever goodies you want, stego, mixmaster, etc. CMR nee HCMS should be an independent system. The mail system you are using should decide whether to use it or some other system depending on the correspondent. While it may seem crazy to toss compatibility, it has some advantages. For instance, the only people who will use it are the hardcore types. I like the idea of an exclusive crypto system that only cool people who are fairly with it use. What do you think about mandating a key size? I like the idea that use of the protocol communicates "I am very serious about my privacy." It's also slightly cripple resistant. (And, were I to consider mass market concerns which I am not, I would say that it makes it easier for the user to make the right choice.) How about finding a way to eliminate indicators? It's nice not to leak any information at all. It also makes super-encryption stronger. If each encrypted layer looks like noise, the total key size is the sum of the bits of each layer. One way to eliminate indicators is through the prior agreement of the meaning of random bits. In effect, you can say "when you see 0x234B4D234F, it means, outside layer RSA/IDEA, middle layer 3DES/SHA1, and inner layer the Captain Crunch decoder ring." This information can be exchanged at the time of key authentication, securely, by telling your correspondent how you are encrypting everything. Later, you can send more random bits when the tank starts getting low. Super-encryption is something we should do more of. Let's say we believe, conservatively, that any particular cipher we are using has a 10% chance of falling in a particular year. In ten years, that's a 35% chance of compromise. But if three different ciphers are used, there is only a 4% chance that it will fall in a decade. Super-encryption has been unpopular because it takes too long. However, if you are using a modern OS, even if it takes five minutes running in the background it's just not a big deal. It doesn't seem unreasonable to me to break out authentication from the communication protocol. Strictly speaking they are not the same thing. Both programs can be called by the same message composition program. This naturally leads to using separate communications and authentication keys. I am not fond of PGP's signature design. The "BEGIN PGP SIGNATURE" stuff clutters things up. How about a one line signature with a previous character count? Note that this wraps beautifully without modifying the message itself. It's unobtrusive. ASCII armor also sets off alarms with me, but I'm not sure exactly how to solve this problem. It seems right to define protocols in terms of full 8 bit bytes. Perhaps just uuencoding encrypted messages is the way to go? For authentication, it would probably be okay to define an ASCII mode. I think key management is good to think of as a separate application. The right way to do this isn't clear, yet. The Web of Trust is a neat idea, but I think the concept is flawed because you are unlikely to tell something sensitive to somebody you wouldn't (or couldn't) authenticate yourself. Ultimately it relies on things like driver's licenses issued by Big Brother, which is terrible. >> Something I've never liked about PGP is their approach to encrypting >> to multiple keys. For one thing, the PGP crowd seems overly >> conservative with bit expenditure, which is silly because bits are >> cheap. This means that creating entirely separate messages is >> completely economical. > >This is more secure I agree. The real kicker with this problem is >people who turn on encrypt to self -- I don't want messages with >encrypt to self (an extra door into the message) on them in my >mailbox, nor coming over the wire headed to me. > >You can see the reason for multiple recipient though -- it's too ease >integration into mailers -- you can process the message and give it >back to the mailer, and then it can still send the message To: x, y; >Cc: z. But this is just bad design if you care about security in a serious way. Even assuming you have to reveal who you are sending the message to, why reveal that three messages are related to each other? This is yet another mass market issue. If we were to do it the right way, all the mail header fields would be contained inside the encryption envelope. >Doing away with multiple crypto recipient risk is more an issue of MUA >integration than rabid conservation of bits. I'll buy that. >> So, perhaps a protocol which does not support anything more than one >> encryption key per message would be a good idea. > >You don't have to use it. I tend not to. I never use encrypt to >self, and I get annoyed with people who send me messages encrypt to >themselves, and very rarely do I use Cc on encrypted messages. If the protocol doesn't accept multiple keys for a message it is slightly CAK/GAK resistent. And, it's a nice statement of intent. It's also nice to have tools which help you to behave securely without carefully thinking about it when you are using them. >> And, I wonder if compression doesn't actually weaken security? Let's >> say I forward a known message with some commentary. Since the >> compression tables will be known, it seems like the increased size of >> the message could provide some interesting information about the >> preceding commentary. All by itself, this probably doesn't matter, >> but combined with other information it might result in a breach. In >> any event, that which is ambiguous should be eliminated. > >I don't understand this comment. Let's say it is known with high probability that I am forwarding a particular message with some unknown prefacing comments. It seems to me that (possibly) some information is be revealed by the size of the compressed encrypted text. That is, the known message will compress to a different size depending on your prefacing comments. For example, if I use lots of words that are in the known message, it will compress very well. The result will be significantly smaller than if I use words that never appear in the known message. This might not be a problem, but I don't like "mights". Also, I like things which are really orthogonal. There's no particular reason for the compression to be part of an encryption program, if you use it at all. >One thing that some people don't realise is that the plaintext gets >mixed into the random pool as an additional source of entropy. In >automated environments (lots of MUAs which set +batchmode), this is >all the entropy you'll get -- except for the original key presses to >generate the key, and a small bit of entropy from the system clock. > >It's fairly good normally because the way entropy is mixed in is a one >way function of the randseed.bin based on IDEA. To make use of this >an attacker would need a copy of your randseed.bin before you sent the >target message, and to have suspicions of what the message is. Even >after a few known messages it would still likely be possible to >attack, because the entropy added by the clock is partly predictable >from the message headers Date: field, and because it isn't that much >entropy each time. The randseed.bin file has always bothered me. What we really want is some good sources of entropy in which we have tremendous confidence. Also, if you signed the message the Date: field won't be needed. This is bad design, in my opinion. A signature and a time stamp are two different things. For instance, I would prefer not to time stamp my messages as it reveals the state of my clock and the transit time of the messages I send. >> It would also be nice if the messages were padded to predetermined >> sizes, say 10K, 20K, 40K, etc. (Once compression is eliminated this >> is less of an issue.) > >It would be nice to have a system where you send 100k and receive 100k >per day regardless. Say in 10 10k packets which get poured into a >mixmaster node. Yes, this would be good. Although, I would think of this as being on a higher level than the encryption program itself. Probably we want an entire communications management program which tracks everything you've sent and analyzes your activity for weaknesses. >> How about a one time pad mode? One time pads are more practical than >> widely believed. Many things we talk about we *do* want to keep quiet >> for the rest of our natural lives. > >Right. > >The problem with this is that you need random numbers. How do you >generate them? You only need to generate keys once in awhile. This means that you can go to some trouble when doing it. For instance, you might have some hardware which is not routinely connected to your machine. >If you use PGP's random pool, one suspects that if IDEA becomes >attackable at some point in the future the random pool will start to >look more like a predictable PRNG to the attacker. > >I wonder how good linux's /dev/urandom would be if MD5 becomes even >more suspect. Well, neither of these would be good for a one time pad, of course. It would be neat to have, say, three sources of hardware randomness and then XOR the result with the above pseudo random output. It's hard to recognize non-randomness, so some overkill is good practice. BTW, it would be nice if PGP or CMR/HCMS would let you supply bits of entropy by hand. It takes awhile to generate 128 bits by hand, but for some things it would be worth it. >> It's clear that going the corporate route has to be handled with some >> care. Given the political implications, investors have certain risks. >> >> Also, many people seem to switch into a different mode as soon as they >> have a company. Anything which they perceive as increasing their >> profits becomes good. PGP, Inc. has gone this way, we've seen First >> Virtual do some unsavory things, > >What did FV do? I know they don't use encryption, and Nathaniel >Borenstein wrote a few hype-hype articles about the _gasp_ newly >discovered security danger of "key board sniffers". The hype article was what I had in mind. I doubt very much that Borenstein would ever have been involved with such a thing outside a corporation. It seems to have a bad effect on some people. The problem is, you don't always know where that bad effect stops once you've noticed it. >> and even good old C2 has made a few people uncomfortable. > >Only thing slightly negative C2 did was to make a dubious decision in >handling of Mr Nemesis's fabricated claims about stronghold flaws. >C2 still rocks, though right? Comme ci, comme ca. The libel suit business was uncool. Also, there was a press release relating to one of the cracks which was somewhat misleading, I thought. C2 has shown some symptoms of institutional paranoia, which is bad. Sameer's comments along the lines of "this isn't some cypherpunk hobby" are also not reassuring. All of these things arise from being in a corporation. The problem is that I'm not tapping their phones. I don't really know what they are thinking or doing. When something happens that is troubling, it's hard to restore trust. I don't give C2 five stars. That said, C2 has done some very good things. People seem to like Stronghold a lot. It really is a secure product. They publish their source code. I do like what they have to say in many of their press releases and they are getting certain ideas into the mainstream. (The Forbes article, for instance.) Sameer's one line comment "sell code" had a lot of influence on me, too. >> It doesn't have to be this way, of course. Look at Comsec Partners. >> We don't see any "conversation recovery", lying press releases, or any >> other nonsense from them, just a beautiful product. > >Quite so. C2 hasn't got "web traffic recovery" either :-) No kidding. Yes, C2 is miles above PGP, Inc. in my book. But, Comsec gets the five stars. They have never done anything or said anything that gave me less than complete confidence. >> What I like about selling software is that you could actually make >> good living by doing the right thing. And, after all, if you've spent >> six months writing something, why shouldn't the users kick in a little >> money instead of freeloading? I would like to see more crypto users >> in the habit of paying for tools and in the habit starting security >> companies. > >New payment models will need to come in. How can you extract money >from a cryptoanarchist? Copyright? Patent? Hah, hah. The important thing is establishment of the custom. Most cryptoanarchists with class will pay. The way to do this is to make it clear from day one that it is not free software. If you want to run it, you should buy it. (The problem with share ware is that people get used to "borrowing" it.) This should work well. Cryptoanarchists, in my experience, have pretty high integrity. Some people will pirate, true, but that's life. Ironically, people who honestly discuss their skepticism of intellectual property laws are probably less likely to pirate. >If we get a real eternity service going (not the poor imitation perl >script up now where all traffic goes through a server unless you >install it locally) software copyright could become a thing of the >past :-) > >Trust might be one way to go, rely on good will. Or paying for >technical support. Or mixmaster, or DC net packet delivery postage >charges. These are good ideas. You know, it would be cool to define a software architecture for remailer software. Different remailers have different properties and different strategies. They may continue to differentiate. When you decided to trust a particular remailer, it could give you a module of code with a standard external interface which prepares messages for that particular remailer. Putting your idea another way, the code is "free" but the remailers cost money. Monty Cantsin Editor in Chief Smile Magazine http://www.neoism.org/squares/smile_index.html http://www.neoism.org/squares/cantsin_10.htm -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBNF1+s5aWtjSmRH/5AQFvHQf+PFXqriw8FoMMcsflEf1Jo55Myl94Luj8 UxSQ9YCq6+dedih7j/FJ3RLL0LtCTa7Sn6E/kGmgqzwcAcfzcjavpl7joNdHU9Yo pS81mXeZ3kw34Nj1hbaX2j6Shx4+46uNUskfXThi6bz3lh1OM2hy7xF63blB2m1I MVt786tah76UfveYlWR/MXK+ZN2DwUvejiPX+bP7vNqaDsXRyrW5mX1vVUuKf6po 5PRZ5wSMKQF/ULm7tOb/g8otoj2w84iir8kckLJiiSs4Xm3hk6+QbDVIhz31aPD3 D2PXIDEXz+x+Vtr5xPIurvpfEo5GpgFdMv5Ox1y796yHr6jjJ8BJjQ== =rjFe -----END PGP SIGNATURE-----

5 6

Re: cute.
by Mix 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Amad3us wrote: >Matthew Nuckolls says >> What's the point in distribuing your public key through the same >> channels as a signature? Kinda defeats the purpose. > >The purpose is to create a persistent nym. The signature, and public >key ensures that you know that this message is from the same person >as you were attempting to nit pick :-] It has been my experience that it is more fun to operate a persistent identity than to post unsigned and unverifiable messages. Providing the key is at least a convenience for people who don't have it already - it saved me a trip to the key server. >> I can't verify that the given public key is indeed yours, since >> you're anonymous. > >True. So it's only as good as the keys you might fetch from a >keyserver that you have no connection to in the web of trust. > >You aren't supposed to link it to my True Name. > >All that can be done is to get a signature from a timestamp server, >and a signature from Bill Stewart's nym key signing service. What would be really nice is if the mailing list machines time stamped messages. There was a discussion a little while ago suggesting that toad.com had been compromised by people who were sowing dissension by partially distributing certain messages. Had toad signed all of its messages, it would be possible to obtain evidence supporting this hypothesis without relying entirely on the word of people we may not know. Had somebody compromised toad, they would still have to correctly sign messages. Later it would have been possible to prove this had occurred by comparing messages and signatures. This would also prevent an attack where somebody forges mail from a cypherpunks list machine to flush out identities. If the attacker sends a unique message to every person, he or she will be able to break an identity if the message is replied to on the list. >This is important because it prevents someone else from generating more >keys with the same userID, such as happened with Tim May's blacknet key. >The only protection I have against that is the public record of my key >being posted to cypherpunks. The http://infinity.nus.sg/cypherpunks/ >archive helps as a public record of first publishing of a key with this >userID. I'm not sure a timestamp matters that much for "authenticating" your key. After all, you don't own "Amad3us", you own key 0x4D162BBE1. If another "Amad3us" shows up, what matters if their string of posts are worth reading, not whether they borrowed your handle. It would cause confusion, but since the cypherpunks are so good at slinging bits, we should be able to handle this. It might even have an advantage: reporters and secret police types will have a harder time dealing with the cypherpunks without adopting some of our technology and ideas and sharing them with others. Monty Cantsin Editor in Chief Smile Magazine http://www.neoism.org/squares/smile_index.html http://www.neoism.org/squares/cantsin_10.htm -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBNFu/fZaWtjSmRH/5AQGSdAf8DdZj05c4/WS/V9YF/o1lZ9W7/5vGlTDf mvU8nFPNT4TB9eha7UW/Ub2xaUI4TneBrWrIwXTeEqo1slUbzmShneeUoUlKMEho +PlrA8NjQhh/QRwMXsVUp4vtoV3oDUbCTRLE8PWIikC7Rpo92UocujfFhsey3Ewu /SCA/TrkjVO8efeR4H6GOBnVWd/+4YigLPtZhP6QzlKjf3Soq5OJNfVlHA3ci+3a UgbM+IQ/OTTkXMVbya60veWrN6/Njo/66D0EyUuHB5/bUHkFIjnWaz1DSG8g0vJq XfFNOusz9Dkrhz0gearv/fbRb93GxXRejTK/Jo9sMJta8pWAm4d1Yg== =5Loi -----END PGP SIGNATURE-----

1 0

Free Market Anarchy (Beck's Folly) - Fundamental flaw
by Jim Choate 17 Dec '03

17 Dec '03

The fundamental flaw with the justification of a Free Market Anarchy and also the fundamental condemnation of Democracy is that of taxation. However, the theory of democracy does not in any way address the issues of taxation, only how laws are made and what the boundaries on those laws are. In fact, until about the first third of this century there was NO personal taxation in this country at the federal level. Clear prima facia , and to use Beck's verbage 'real', evidence that the assertion that personal taxation and democracy are irrevocably wedded. Ask yourself, why is it that no free market anarchist *ever* mentions commenality in humanity? Why do their have inherent and implicit in their systems a class structure? They would have you believe this is natural, it is not. Class structures are reflections of the beliefs of the people, not some fundamental law of nature. Furhermore, Free Market Anarchy does not address the issues of protection from abuse. It does not recognize in any manner any mechanism for redress of grievances unless you happen to be one of the few who controls the wealth. It further assumes that those who don't have wealth will willingly take this station in life as a given and simply work for those who do have wealth and accept without resentment that they will forever be denied any sort of opportunity to change their station in life except at the whim of the power brokers. It further does not in any way address issues of life, liberty, or pursuits of happines - only monetary wealth. It is clear that having wealth does not in any manner guarantee any sort of empathy for others in the holder. If anthing, history demonstrates that such 'lords of wealth' are pragmatic about collecting wealth to the point of predation. This argument from the specific to the general is fundamentaly flawed and the conclusion suffers because of it. Power corrupts, absolute power corrupts absolutely. How that power is obtained, by vote or specie, is irrelevant as clearly shown by history. Some hold that the majority of the populace suffer taxation at the point of a gun. This assertion is also false. There have historicaly been several political parties which have promised to eliminate personal taxation. In every case those parties could not control more than a truly minimal percentage of the vote. Yes, people say taxation is too high, they do not hold the assertion that taxes should be completely eliminated. Free Market Anarchies are doomed to the same sort of death, and if ever implimented the same sorts of abuse, as all other non-democratic systems. Also, recognize that those who support such systems have a set of commen character flaws. First, they can't differentiate the implimentation from the theory of political systems. They would have you believe that if a given implimentation of a system is flawed or broken than all systems of that ilk are then broken or flawed. Clearly history does not support such assertions. In short, they would throw the baby out with the bathwater. Secondly, these in general are the sorts of people who find glee when they see a polic officer run over in the street. Do you seriously believe that anyone this cold and uncarring would not hesitate for an instant in putting pepper spray in your eyes? Thirdly, they express a view which I call Theory X equality. In short, as long as they are the ones making the profit, the fact that you suffer for it, justly or not, is irrelevant and justified. In more prosaic words, the ends *always* justifies the means. An assertion that history also does not support. ____________________________________________________________________ | | | The financial policy of the welfare state requires that there | | be no way for the owners of wealth to protect themselves. | | | | -Alan Greenspan- | | | | _____ The Armadillo Group | | ,::////;::-. Austin, Tx. USA | | /:'///// ``::>/|/ http://www.ssz.com/ | | .', |||| `/( e\ | | -====~~mm-'`-```-mm --'- Jim Choate | | ravage(a)ssz.com | | 512-451-7087 | |____________________________________________________________________|

1 0