December 2003 - cypherpunks-legacy

One Time Pads (Real Ones!)
by Mix 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- One time pads are under rated, in my view. Not only are they secure forever, but the executive branch of the U.S. government says they are exportable. I've been thinking about how practical they are. One diskette holds about 150 messages. The people we trust tend to be people we communicate with a lot. An exchange of one box of diskettes should last a long time in most cases. The first 128 bits of the pad can be used as a key to identify it. This the recipient can figure out how to decode it by hunting through his or her key collection for the one that matches. When keys are exchanged, additional information can be exchanged and associated with each key. Length, for example. This means no length fields are needed because it can be recovered from the key itself. There are probably more examples. One time pads are self authenticating. For increased security, the use of a double one time pad is a good idea. Both correspondents generate key sets. The message is encrypted using one key from each key set. Again, no identifying information is needed, because the recipient can look for pairs of keys that work. If these key sets are exchanged through separate secure channels, they will be especially hard to compromise. Also, each user can be confident that the message is secure with regard to key material if they have generated the keys themselves. Keys should be destroyed immediately after use. This means that the only time the rubber hose attack is effective is during message transit. Key destruction is a hard problem, though, because it is difficult to be confident that the key has been completely erased from a disk. Use of diskettes improves the situation. Other media might be better, such as static memory. There is no good reason not to wrap one time pads in other encryption protocols. It is hard, maybe impossible for some algorithms, to crack a message when the contents have the appearance of noise. This means that it is hard to tell who is using one time pads and when they are doing it. Naturally, the user will send many messages which consist of noise, indistinguishable from a one time pad. This gives the user plausible deniability, especially if the practice is common. If the wrapper encryption protocol has not been compromised at the time of use, it has the pleasing result that it buys time. Should the message be recorded and filed on tape at Ft. Meade, and the encryption protocol broken ten years later, the user will have a very difficult time producing the key material. Key generation is an inadequately solved problem right now. There are chips which generate streams of random bits, but it is impossible to tell if they have been compromised. A home brew hardware based random number generator with a serial interface is probably the best way to go. The output of this device could be XORed with other source of randomness to increase confidence. One time pads seem practical to me. Comments? 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/WZaWtjSmRH/5AQER3Af+M+T31s+VOdrCE61a0kbp0fe3Eyosoub2 YkAWZs48knTFgtAS0sv5IRrKparKaKdgAQISscBSuW5YXGi9WJCA2/3+2/+iwvrK 1tIoEDF+fYaq6/a2yiyI4PVZ8qPMpyLayZ3K89P8N8zzuQSMS6pB7yOf4waOufcF 6nAmcVG8/O4BddID15XiKbdc7QSpHKK2R3LlwrS4ZQBHyhYvC5Quo41SHNiWIGjO N6zMkBKuDXEpjmnX9O1LRelT7hEMX0ss6b4ZTmFw39NXwDwgFahP+C2/Zw+Kt0Je +/PNDJXWWQDWovVrCW2yKmpKeTPgxTJ1R4aEpt2CBwdQlMqVwpVrAg== =O5oZ -----END PGP SIGNATURE-----

3 2

Re: Remailer hating Nazis (was Re: The BIG Lie (Jesus Confesses))
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

Anonymous <anon(a)anon.efga.org> wrote: >> > If so, then burn in hell, Nazi scum-sucking weasel! >> > >> Ditto for Paul Pomes and Gary Burnore. > >I'm familiar with the role of Gary Burnore <gburnore(a)netcom.com> and that >of his DataBasix associates Belinda Bryan <eridani(a)ix.netcom.com> and Billy >McClatchie (aka "Wotan") <wmcclatc(a)primenet.com> in getting the Mailmasher >and Huge Cajones remailers shut down. Jeff Burchell posted a public >expose' of their harassment to Usenet back in June, apparently catching the >DataBasix folks off-guard. But what's the story with Paul Pomes? What has >he done? Paul Pomes was complaining about Jeff Burchell's huge cajones remailer to Jeff Burchell's upstream and employers about the same time the rest of the Databasix gang was doing it. Paul Pomes appears to be a part of the Databasix gang. >Perhaps the best thing that can be done with people like Burnore is to put >together an FAQ about their tactics, similar to what his "fans" have done >for the "Rev." Steve Winter. Then when Burnore tries to stir up trouble by >first fabricating anonymous "abuse" and then demanding that it either be >stopped and the culprit(s) identified (knowing in advance that's >impossible), or else that the remailer be shut down, someone can forward >that FAQ to the remailer's upstream provider, or whoever is being pressured >to pull the plug. And if Paul Pomes engages in the same dishonest tactics, >that needs to be done with him as well. Gary Burnore had a mongo page at http://www.netscum.net/burnorg0.html. So did Paul Pomes, Belinda Bryan, and the rest of the Databasix gang. Too bad it's down for now, but it'll be back.

2 1

Re: Jim Bell sentencing delayed
by Blanc 17 Dec '03

17 Dec '03

Greg Broiles wrote: >perhaps I'm just low on conspiracy juice this week, but I think that Kent's >suggestion that he's in the hospital is probably the best - his recent >letters/calls to Blanc mentioned a persistent staph infection. Ach! Greg, that was supposed to be a "secret", since Jim said he didn't want publicity over his case and I cheated by letting John post it on his web site. Although, it's not like most everyone suspected, hmh. But anyway, what do you mean by saying that John's books were returned to him? I sent a letter to Jim in the mail this past Saturday, encouraging him to call me again and update me on his situation and on the sentencing date. So I'll be waiting and will pass the info on to John. .. Blanc

1 0

Washington Times: "FCC wants to extend V chip to computers"
by Declan McCullagh 17 Dec '03

17 Dec '03

Front page: "Not content to monitor the progrom on your television set, the FCC now wants to install a vchip in your personal computer -- a move that could extend the agency's reach into cyberspace... "Lawmakers said the vchip law was intended only for TV sets..." "Some question whether this will lead to FCC regulation of the Internet..." Dave Banisar, Rep. Tauzin, Ed Black make appearances. -Declan

2 1

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: Forwarded mail...
by Anonymous 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Jim Choate wrote: >> Fortunately some of these "good" lawyers already exist at the Institute for >> Justice. Basically, they are a libertarian version of the ACLU. They've >> accomplished some good things and deserve the support (read $$$) of >> freedom-minded individuals everywhere. (note: I'm not connected with them >> in any way; just letting the cypherpunk community know about an organization >> in sync with our views) >> >> "If you seek a courtroom champion for individual liberty, free market >> solutions, and limited government, look only as far as the Institute >> for Justice. When politicians pass sweepingly intrusive laws and >> bureaucrats build their empires of paperwork and power, only the >> Institute for Justice brings them to account in court." >> -- http://www.InstituteforJustice.org/ > >Thanks, I'll check them out as I am unaware of their position. I should add that they haven't done anything in the field of cryptographic or technology issues, but have focused most of their efforts on protecting small entrepreneurs from overly zealous government agencies, particularly on the local level. One item I found of particular interest was a report they published in July 1996 about the restrictive barriers New York City has erected to prevent entrepreneurship (i.e., expensive/restrictive licensing fees, tough penalties for doing business without the required permits, etc.). An earlier post on this list referred to NYC as a cesspool of socialism. There is truth to this statement. Socialist politicians tend to punish those who help themselves, all for the public good of course. [snip] >> Bill Benson has done some extensive research (his book is called The Law >> That Never Was) regarding the 16th Amendment (the so-called Income Tax >> Amendment) and how it was ratified. According to the information he has >> uncovered through exhaustive research in D.C. and all of the state capitals >> of the then 48 states, the 16th Amendment was never ratified by 3/4ths of >> the states. (see http://www.trustclarks.com/theman.html for more info) >> >> Friends of mine have spoken to Mr. Benson about this, and he says that the >> courts won't touch it with a ten foot pole. He even sells a package (or at >> least he was selling it back in 1995) of legal information about the >> non-ratification of the 16th that can be used as a defense in an income tax >> case. According to Mr. Benson (in 1995), each of the cases was dropped when >> the defense made it clear they were going to argue their defense based on >> this point. >> >> I understand that folks in the "patriot" movement have tried to take this to >> the Supreme Court without success. The Court refused to hear it. >> >> Assuming Mr. Benson's research is accurate and legitimate, the 16th didn't >> even come close to being ratified and is truly a Law That Never Was. Think >> about that next April 15th...the IRS's "lawful" authority is based upon a >> legal fiction. That's why it's called >voluntary< compliance. > >Actualy, his research is one of the reasons that I am so interested in an >actual lawsuit. > >What if somebody were to go for several years with no contact at all with >the IRS, and no intention of making contact. Then when approached that >person makes enough noise to guarantee that they will be going to court. Funny you should mention this. A few folks have this very intention. :-) >What would it then take to bush-whack the beggars? What is the absolute last >point that your defence must be revealed prior to your presenting your case >to the jury? I'm not following the wording of this last question. Could you clarify? > The reason I use the first person is because to me it seems >critical that no lawyer is actualy used in the defence. As I understand it, >and I ain't no lawyer, there are some actions that a defendent may do if >representing themselves that lawyers are prohibited from doing. Among them >is stating the obvious fact, if the jurors don't believe the law is just >they may refuse to find for that reason. If the Constitution and the actual >record of votes in concert with the general feeling of excess regarding this >matter doesn't prove the case, what will? That's exactly the point. And that, I believe, is why the Supreme Court -- or any court for that matter -- will not go near this issue. It is the pivotal point that would collapse the whole house of cards that is the Income Tax. The feds have a huge vested interest in keeping the system going as long as they can (Y2K bugs and all) and this issue is a veritable hornets' nest. Nerthus p.s. For those of you keeping tabs on nyms, this is the last time I will include my public key in the body of my email. - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: PGP for Personal Privacy 5.0 mQENAzRc0lEDFQEIALF2JX7RgDLC6nnSa7BmcczGumTRxhXx5mHoqPcGY95VGAVD 49iN/+59BBrHKxOU5JX5F9kWEsBG92KbOdB3XGCsub7AYmCl+iMrG+h+vJl9qCyc 134sq7WNfInA9TxiQ28/DldHj++gDeQJr9BvUU8Ez2Iu70uW5T7rlHFyBUWQBh3P 2dB/Q9A/dixhAzNTaeTuVH4TunoyDN6OrRrSTdZhsPs8dLVLLeqKC3qM28wLX5Mt qQCUb/pRb9TR9ygwaznAIdqSJ1qc/xqlQY6U0Vh6YVOaId+MQwzsq1ZRPlW0kYSS wgka2WXELH5ZpQLmCppM1pdkHhm54VbBl7TmNwkABRG0I05lcnRodXMgPGN5cGhl cnB1bmtzQGN5YmVycGFzcy5uZXQ+iQEVAwUQNFzSUeFWwZe05jcJAQFxVQf/WUSH ltCrUpoQwQ9oTGCJiRycTQqUzDuqaqR55xgyz8W5mARixBigd/sL63EoBlQmyHR3 NIgwIW3I8hcPfUlXi84hsZ+89/HVW3CoMk2g6692UEoKHUX6bMkeAi85hIfJVhFj EONhx3xFmdOZqkEbdFm81J/0JJIhtAe0Ut2DPu4B49yjO7NBTg97QWwO6ZymE09v BUv5esuvdxFbmn8qfPHdurs+MrvoKbhZIA8Xz03eTS1auT8pNvdEO4EDaac0njZ4 5wAbAeC79AqztS75GpT7cf0jZcYJPwtW8LPXj7SQCMimseZ7/2OxNPditI9e58CI EL/Dl0D9qn1NRPiVwA== =8W8j - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQEVAwUBNF0knuFWwZe05jcJAQH8WAf/e/BA8ysXWf1xrxJKiNPP8oyEDHpeFxZQ LWgW/kgfDmh1Y/Tfjw0i5nnnImlXfEcX5nmL8H+HezxBxKMN2O33PftHAPYghHrI y0hSgZVmA2VOMy4Dtv0umT19RarennPVHrGDyCi2zmNF9+5v6b81CYWLEBNMYx9V kaVOBCEt0FRdDFug1FwNRHJ+gHQjbFCVCMRF2v/0AF5r9uDPzNtCo3JP6tnllcqX jSf6MKa3Kxw17c+Je+TuLwHgltvULt3KZBrweJqslKKbY24Qw/PSPPHczvL8ieI1 uknK9KTVl6OJLvaGyI6bpFFgFoPxTpF+JJkzUR1GnlLN5gUwuQ6NKw== =osod -----END PGP SIGNATURE-----

1 0

Business Loans For You
by loans＠xitau.de 17 Dec '03

17 Dec '03

Do you need to increase profits in your business? Do you need venture capital to get you there? Are you frustrated with your bank turning you down for the capital your business needs to grow? Be frustrated no more. Zion Worldwide can put you in touch with hundreds of offshore investors waiting to invest in a viable business just like yours. What Is An Offshore Investor? An offshore investor may be an offshore bank or a group of offshore lenders looking to invest in and to lend money to viable business enterprises both in the United States and elsewhere around the world. Why Not My Own Bank? U.S. federal banking law permits American banks to tie up a lot of their money in overhead expenses and advertising costs. Which means that American banks have less money to lend out to their customers (the ones who gave the banks their money in the first place!). Offshore banks, on the other hand, are required by offshore banking rules and regulations to lend more of their customer's money to, you guessed it, their customers. And groups of offshore lenders (often referred to as 'conglomerates'), are not necessarily restricted to the number or type of businesses that they can invest in, as long as these businesses are viable and show potential for future growth and profit. How Do I Take Advantage Of These Offshore Lending Opportunities? Zion Worldwide works with literally dozens and dozens of offshore banks and conglomerates across the world to put American businesses in touch with reputable offshore lenders. By submitting an offshore loan application to Zion Worldwide, your businesss automatically becomes eligible for the following types of offshore funding: Venture Capital Loans, Signature Loans, Equipment Leasing, Cash Grants, Self Liquidating Loans and a $25,000 Line of Offshore Credit, as well as offshore corporate credit cards. How Do I Apply And How Much Does It Cost? To apply simply write to: Zion Worldwide 5015 W. Sahara Ave., Suite 125, Las Vegas, NV, 89102. ..and ask for an offshore loan application. There is a non-refundable application fee of $200US payable to Zion Worldwide via money order, cashier's check, Visa or Mastercard. Why The $200 Fee? When you make application for offshore lending opportunities, Zion Worldwide literally sends your company's loan application to several major funding institutions around the globe. The $200US application fee assists our organization to cover the costs of shipping your loan application documents around the world. How Does Zion Worldwide Make Its Money? When your company's loan application arrives back to our office, Zion Worldwide receives a brokerage fee from our offshore lenders for finding them viable businesses to invest in. Can I Apply? Any viable business in the US or abroad may make application to Zion Worldwide in order to receive serious consideration from Zion's offshore lenders. Is It Hard To Apply? Absolutely not. Simply prepare to provide your company's past earnings as well as future earnings potential, as well as some documented business plan and, of course, some basic business details (e.g. your company's name, address, phone, fax etc.) and you're set. In fact, we want you to succeed in securing your loan, because when you succeed, we succeed. Why Is Zion Worldwide Located In Las Vegas? Nevada is America's last haven for judgment proof corporations (better than Delaware, better than Wyoming). Zion Worldwide strives to take full advantage of all of the incorporation benefits that the State of Nevada provides. What's The Catch? Sometimes interest rates on offshore loans are higher than interests rates on similar loans in the United States. However, apply for an offshore loan, then immediately turn around and expand your business with it, and of course, enjoy the increased profits your business generates, repay your offshore loan early, and the interest charged to you on your offshore loan will total no more than the interest on a loan you can (or can't) get in the US. AnyThing Else? Nope, except 'Apply Today'

1 0

Testing headers, ignore
by Paul Bradley 17 Dec '03

17 Dec '03

Test sent at 3:45pm 3/11/97 from c12 Paul Bradley Paul(a)fatmans.demon.co.uk Http://www.cryptography.home.ml.org "Don`t forget to mount a scratch monkey"

1 0

FUD Trivia -- Sex, Bells, 'a'nd... / [Fwd: Sampler: November 3] Sampler: November 3
by TruthMonger 17 Dec '03

17 Dec '03

1 0

Protocols for Insurance to Maintain Privacy
by John Kelsey 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- [ To: Cypherpunks ## Date: 11/01/97 ## Subject: Protocols for Insurance to Maintain Privacy ] >Date: Wed, 29 Oct 1997 09:24:39 -0700 >From: Tim May <tcmay(a)got.net> >Subject: Protocols for Insurance to Maintain Privacy >There are interesting protocols which can be used to skirt >statist laws about insurance. A la carte insurance, for >specific illnesses, is one of the best examples. Thus, a >heterosexual male who doesn't use IV needles can "opt out" >of coverage for AIDS-related treatments, thus transferring >the effective cost to those most worthy. I can see practical problems with this (like finding out that the fine print on page 248 of my insurance contract turns out not to cover dog bites that occur on Thursdays), but it's really just letting customers buy only what they want. >This has similarities to crypto protocols. And anonymity. To >wit, it is possible to arrange anonymous blood tests for >various conditions. So, Alice arranges a distributed set of >such tests, perhaps at multiple labs. When she finds she has >no preconditions or precursors for Diseases A, B, C, and D, >she opts out of being covered for these diseases. One problem with this is that, if it becomes widespread, nobody will ever buy insurance for these diseases unless they have it or probably will get it. This kind-of defeats the point of having insurance, which is to protect yourself from low probability high cost things happening. That is, before I've taken the test for genetic disease X, my best estimate of the probability that I will test positive is very low. Once I have taken it, I know the result. If I sign up for a-la-carte insurance for this disease, the insurance company effectively knows I must have tested positive for a predisposition to it, and so either won't give me insurance, or will give me insurance only at an extremely high rate (corresponding to a 1/10 chance of getting the disease, rather than a 1/1,000,000 chance). On the other hand, information isn't free--I have to spend some money for each of the hundreds of genetic tests available. There may be a profitable business in providing a battery of genetic tests for a large up-front fee, in a sort-of inverse-lottery scheme--if you get unlucky enough to have one or more of these disease precursors, we pay your insurance costs, or at least give you a big bundle of money to spend as you will. This is subject to various kinds of abuse (if you know you're predisposed to get some disease, you have a strong incentive to enter the ``lottery''), but it still might work. >--Tim May --John Kelsey, Counterpane Systems, kelsey(a)counterpane.com PGP 2.6 fingerprint = 4FE2 F421 100F BB0A 03D1 FE06 A435 7E36 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNF1ZdEHx57Ag8goBAQFZsQQA7NGzgc39WbyB8eACZN71wrBwOdapExNn fvn1aEFeHoLWZnHIcLHwzSuCiJ22I9kGK8Co88fDfjDebb+kzHj9oO4xpfMecHLr pjvKWfEDOnv5th6hxCmzKrA6OpuMqYgtvX9USRuO1oLckjX4mTc6jvEp6ZBD96vB uWvXhj1bPUM= =Vc/C -----END PGP SIGNATURE----- --John Kelsey, Counterpane Systems, kelsey(a)counterpane.com PGP 2.6 fingerprint = 4FE2 F421 100F BB0A 03D1 FE06 A435 7E36

2 1