December 2003 - cypherpunks-legacy

Place for WWW info/ stuff
by Jaeson.M.Engle＠josaiah.sewanee.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I have a server (WWW and ftp) that I would like to use for anything anyone needs a place for. Drop me a line, or visit what's on my server (see below). The part of the server that I will be putting cypherpunk related material is password controled, and cannot be accessed unless you have am account and password (assuming of course someone else doesn't break in and figure someone's out that is... but I don't see how they could.) This is just FYI for all and anyone! Cheers, - -J -----BEGIN PGP SIGNATURE----- Version: 2.6ui iQCVAgUBLyAj5UiLvmPjc4XdAQEJsAP+Pd7A/I01zZUaXUi7vhIbk3XHijrgAhjZ 1ZqIVuiOIfddnS8w+hJ1bKrxZFoY9YRzNLx0rliBckEn+HVYOl4+qQQjZ3TqjhDw FULRRD6DGS85ZLZ/rwKrlyrSPY6YywgzgyzlZcUa/UtQ9Ll66NA4R6c7VWQB+4K7 qBuOUaOWvV0= =XXIw -----END PGP SIGNATURE----- aka: (-: Jaeson M. Engle || jme(a)josaiah.sewanee.edu :-) (-: www server: http://josaiah.sewanee.edu/ :-) (-: It's January 29th! IT'S TIME!!! Ask me for details!:-) (-: Finger 'jme(a)josaiah.sewanee.edu' for my Public :-) PGP block.

1 0

Little ebanks -- a modest proposal.
by davidm＠iconz.co.nz 17 Dec '03

17 Dec '03

[Executive Summary -- The author proposes a system of stamps for remailers as a way of starting up an ecash system. The stamps would be sold to the public as stamps, but be convertible by remailer operators into real money.] Hal, Many thanks for your comments. I'll try to make this less legalistically impenetrable. Despite the difficulties, I think anon corps are possible - and legal. What I was trying to stress is that they are expensive and inefficient: so you have to be really sure you want anonymity if you are going to use one. The hurdles to ecash seem more formidable. The problem with moving off shore and ignoring the SEC, for instance, is that your scheme loses some credibility. Since the value of ecash is (in the short term, at least) going to be based on the possibility of converting it into real cash (just as the value of real cash is based on the possibility of converting it into real things), a structure that operates outside the law makes that value doubtful. A large-scale rollout of ecash for the average Netscape user (and the people that service them) is going to need all the legitimacy it can muster. Perhaps, though, we can start small, and allow the forces of nature (greed, envy and, with a bit of luck, sloth) to take their course and scale a small scheme into a thriving e-economy. What I have in mind is a service that provides estamps (you knew there had to be an 'e' in there somewhere, didn't you) for use with remailers. Jo Anonymous buys stamps, sticks them on her messages, and the anon-remailers collect them. The remailer ops then get to cash the stamps in for actual money, so they can pay their ISPs and lawyers. At the heart of the scheme is a genuine (micro) ebank [a uebank?]. But, to avoid problems with offering securities to the public (and the SEC hassles etc), the ebank only sells estamps (little bits of ecash) to estamp- vendors. The estamp-vendors sell the stamps (with a mark-up?) to the public. [Perhaps using this new Netscape/Mastercard tie-in.] Because the estamp- vendors are only selling stamps (you can tell by the beautiful stamp-like gif-icons the vendor's Web page uses...) the SEC doesn't become involved. [I'm relying on the fact that the numbers involved are really small, and that the estamps *are* being sold for the purposes of postage. Perhaps the ebank and the vendor should be based off shore...] This scheme breaks the credibility issue into two -- a large number of people (anonymous remailer users) have to be convinced of something relatively trivial (that the remialer will accept the stamps); a small number of people (anonymous remailer operators) have to be convinced of something relatively important (that the stamps are exchangeable for cash). If the remailer operators are sufficiently involved in the scheme, this should work. One type of scalability comes when EITHER A. Someone sets up as a Data Haven token vendor (the tokens being bought from the ebank as slightly larger bits of ecash), and data haven operators start to accept the Tokens, in the knowledge they can swap them for real money; OR B. Data Haven operators start to accept estamps for their services, because they can swap them for cash; OR both. [The first scenario obviously disguises the appearance of ecash as a medium of exchange for a bit longer.] Another type of scalability comes when other people start uebanks, which then issue their own estamps/tokens/ecash to estamp/token vendors. If the new uebanks are as (provably) secure as the original(s), the uebanks could agree to clear each others' ecash and settle up at the end of the day (or some global equivalent - eg 12am GMT) using some kind of netting system. As long as everyone played nice at the beginning (all the remailer operators declared their estamp income etc ;-) the uebanks could go legit: and by backing their submissions to regulators with a proven record of service (no need to stress that the remailers were *anonymous*), by wearing Al Gore t-shirts and garbling about the I-way and electronic town halls, and by not letting Tim May and his contract killers near the place, it might just work. On the other hand, if the system is working well enough, there may be no need to go legit. (Although if I was an ebank operator I would be wary about entering into netting arrangements with an ebank the SEC etc could close down). [But is netting needed with online clearing? Perhaps this would only be useful across currencies...] With the ebanks in appropriate jurisdictions, operating in grey rather than obviously black areas (it is not so much that this stuff is being offered to the public as that the public is going out to *find* this stuff), with a proven track record in ponying up the cash, and with the approval of really cool people who get on the cover of Wired, Robin Public may not *need* any more assurance to par- ticipate in the e-economy. What R.P. *will* need is products. Most of the attempts at net-commerce I've seen concentrate on offering things that can be delivered to people, either physically (so that the Compuserve Electronic Mall is basically a mail order catalogue) or electronically (hence the rather sketchy descriptions of anonymous markets, usually falling back on the idea that, because this is the Information Age, consulting is the root of all value...), to be consumed now (this tin of coffee, that movie-on-demand, the other set of nanotech plans). But of course a lot of people (not, unfortunately, myself :-) have significant amounts of property that they do not consume right away. The possibility of anonymous investment (through eg anon corps) offers huge scope for the development of the e-economy. [I'll mention one statistic -- according to tax haven experts (Ginsberg, Spitz), in 1989 50% of all money processed internationally goes through tax havens.] After all, a capitalist economy (even an anarcho-capitalist economy) is built by capitalists, not wage slaves. More later (unless you plead real hard...) Cheers, David

1 0

Re: The Remailer Crisis
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

Tim urges recently that we need to do something about the "remailer crisis." I remember Sameer once mentioning that he could set up remailer-in-a-box accounts for possibly anonymous 'sponsors' who'd be the legal owners therefore indemnifying Sameer (the tolerant sysadmin) of responsibility. I know he allows 'remail-to-yourself' blind-server accounts for $10 / meg or something. That's probably a bit expensive for a sponsor of a public remailer (any stats on average remailer traffic?). I never did here any more from sameer or anyone else about remailers-in-boxed-accounts. I for one would be willing to 'sponsor' a remailer account on any system with a small fee - I can't run my own as my private site looks at the world through PPP. I suggest that 'sponsored' remailers are a better way of making remailers economically viable for people like Sameer, who are the real, if not nominal, administrators. Though I hardly use remailers, those who do would probably make better (and more easily executed) use of their money if they sponsor remailer accounts on Cypherpunk ISPs like c2, rather than pay a (truenamed, legally vulnerable) operator for any single remailer. Sameer's blind-server code can come in use to make any link between the sponsor and her sponsored account very hard to detect. The advantages of sponsoring remailer-site operators to create remailing accounts, rather than pay an individual remailer operator, are many: 1. innocent until proven guilty - presumably sponsors do use remailers a lot; but not necessarily. So the payment transaction can be via truename, rather than via some complicated anonymous means, and still leave the sponsor unimplicated 2. legal - an operator of a single remailer is vulnerable - technically, if not root, and legally otherwise. an administrator of a Cypherpunk ISP is not, and does not have the legal right to monitor a customer's traffic, and with blind-servers even detailed logging don't lead back to the owner of an account, the sponsor, from any _specific_ remailer (though a pool of sponsors exist for a pool of remailer account) 3. technical - it's not possible to ban a single remailer, as they may be _many_ on a site. If the site is much more than just remailers, it's not really possible to ban the entire site. 4. traffic analysis - more remailers addresses will make traffic analysis harder, and chaining more fun - you could chain through multiple accounts on a single site with little loss in reliability (though you'll still want to go through more sites) 5. remailer explosion - more reliable remailers (due to the '-in-a-box', more users, wider distribution Comments? ----------------------------------------------------------------------------- Rishab Aiyer Ghosh "In between the breaths is rishab(a)dxm.ernet.in the space where we live" rishab(a)arbornet.org - Lawrence Durrell Voice/Fax/Data +91 11 6853410 Voicemail +91 11 3760335 H 34C Saket, New Delhi 110017, INDIA

2 1

Netherlands crypto ban?
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

What's the update on the move to ban private crypto in Holland? Last I remember there were trial balloons, but nothing happened. ----------------------------------------------------------------------------- Rishab Aiyer Ghosh "In between the breaths is rishab(a)dxm.ernet.in the space where we live" rishab(a)arbornet.org - Lawrence Durrell Voice/Fax/Data +91 11 6853410 Voicemail +91 11 3760335 H 34C Saket, New Delhi 110017, INDIA

1 0

Re: IRS to keep unreviewable secret dossiers on US citizens
by pstemari＠erinet.com 17 Dec '03

17 Dec '03

At 12:44 PM 1/20/95 CST, xpat(a)vm1.spcs.umn.edu wrote: >Excerpts from : St Paul Pioneer Press, Jan 29, 1995 > >"IRS plans to collect more data on individuals to nab tax cheats" [...] Here's the text from the recent EPIC annoucement on this--it covers the exemption the IRS is claiming from the FOIA in a bit more detail (sorry if people have already seen this): ======================================================================= [6] IRS Initiates Massive New Database ======================================================================= On December 20, the Internal Revenue Service announced in the Federal Register that it was planning a new database to monitor compliance of taxpayers in a project entitled Compliance 2000. The database would contain information on all individuals in the U.S. who conduct certain financial transactions and would be segmented by different criteria: Any individual who has business and/or financial activities. These may be grouped by industry, occupation, or financial transactions, included in commercial databases, or in information provided by state and local licensing agencies. The new database will combine private and public sector databases in a single searchable entity. A number of federal financial databases from the IRS will be enhanced with state, local and commercial sources. The Federal Register notice describes the non-tax databases: Examples of other information would include data from commercial databases, any state's Department of Motor Vehicles (DMV), credit bureaus, state and local real estate records, commercial publications, newspapers, airplane and pilot information, U.S. Coast Guard vessel registration information, any state's Department of Natural Resources information, as well as other state and local records. In addition, Federal government databases may also be accessed, such as, federal employment files, federal licensing data, etc. Finally, even though the proposed system would use frequently inaccurate "commercial databases" such as direct marketing records, taxpayers would not be able to review their records to ensure that they are accurate and up to date: "This system is exempt from the access and contest provisions of the Privacy Act." EPIC is filing comments asking the IRS to reconsider its use of commercial databases and to ensure that there are greater safeguards on the collection and use of personal information. A copy of the Federal Register notice is available at cpsr.org /cpsr/privacy/epic/IRS_compliance_2000_notice_txt Comments on the proposed system must be received by January 19, 1995, and sent to Office of Disclosure, Internal Revenue Service, 1111 Conn. Ave, NW, Washington, DC 20224. EPIC's Comments are available at cpsr.org /cpsr/privacy/epic/epic_irs_compliance_2000_comments.txt --Paul J. Ste. Marie pstemari(a)well.sf.ca.us, pstemari(a)erinet.com

2 1

Spam Busters!
by Nathan Zook 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Yeah, the numbers should be higher. This was just a hypothetical! nzook(a)bga.com said: > There is little, if anything, we can do to stop a chained, PGP'ed mail > bomb, "This is mail bomb number XXX. Boom!" It is therefore in our best > interest to not encourage children to send such messages in such a way. I > believe Homer's message was erroneous for this reason. People, please! Before critisizing a method, look at the threat model! I plainly stated that my method was not intended to deal with real trouble. tcmay: "The From: line is notoriously misleading". But it still gives enough that we need remailers in the first place, right? The "From:" was a token. It wasn't meant as a literal. For id'ing postmaster, all you need is the xx.xx.xx.xx, right? jalicqui "Unless your remailer was the terminal remailer for a significant number.." But in a serious spam/mailbomb attack, someone would _have_ to get a bunch, right? With the changing session keys, and a chain, the best we could hope for would be to stop it on its way out. (or use for padding ;-) Incidently, a per/customer volume limit would also control the binaries. Since we have little hope of id'ing the true originator, we might have to limit a site. (bad) OTOH, if someone tried to send binaries, only to find that they couldn't get more than 1M out an hour, they would probably give up & go somewhere else. We might also hit the chained pgp bomber this way, as the messages would likely be fairly large? XXX But this all misses a point that I would like to stress. We are in what the military refers to as "low-intensity combat". Right now, we don't have a continuous stream of spam-bombs floating through our systems. (Well, we did, but jp shut down :-(( ) Right now, we (other than PRZ) don't have serious legal troubles. Right now, our remailers are too weak to be a significant problem to the TLAs (any more than a forged From:). The way to win a low-intensity battle is to avoid escalating unless you are sure you can win. Eventually, we will have to standardize packets. Eventually, we will have to employ very sophisticated techniques to deal with spam-bomb. But maybe we don't do that today. Maybe we do just enough to catch a bunch of the most juvenile. Then the next bunch is smarter. Then we catch them. We keep going. You see, I doubt that we can take on a spammer that knows the net as well as anyone here. But I don't doubt that word can get out that the remailers nail spammers. Of course, we risk becoming the latest challenge to the juvenile, but I think that this is far less likely than it appears at first because we are, after all, "really cool". My suggestion is to avoid, for as long as possible, letting on to _anyone_ just how sophisticated our systems are, just how much can be done, until we are sure we can win the unavoidable battles. XXX This also strongly points to per-line blocking of remailers. Since the necessary steps to catch a sUPer bomber appear to be impossible/ impractical, we must offer annon-blocking for those poor souls that request it. Perhaps annon-block for a month at a time. This is part of that PR that we need to watch. To put it another way, if our services make it easy(er) for someone to engage in an activity that we oppose, and that can hurt (subjective) someone else, we are facing a moral responsiblity for our actions. We should attempt to fulfill that responsibility. I believe that the phone company even allows people to change numbers for free if they are receiving harassing calls. And we want to be better though of than the phone company, right? XXX BTW, do you have to be a remailer operator to be on the list? If not, I'ld like to know how to subscribe... Finger or request keyserver for PGP 2.6.2 (tm) key. PGP<->Mail/News installation incomplete. Factors for modulous are not proven primes. Key may be far weaker than expected. Encode at your own risk. Key ID: 14712B4D 1994/12/26 Nathan H. Zook <nzook(a)bga.com> Key fingerprint = 44 B3 D8 66 3D 55 1E 2E F8 92 22 A6 33 8C DE 24 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBLyBfUHmgMs8UcStNAQE7Ygf/Wg5+hKErgpqi+4J7jOAw97AitUnYn+z+ QJqAw4ar6hQEY/taC6ru5S8YjKYHwmXdR7n7YjSFjEy8aYwXSr4SaALICNhQsyrU jcSuaMY0oUN2obYV6TxYtdVWaQVF9XBqW/8AlIcs+ZF4Yi7gqUdgf4aApuapW14e drVi6PgV5ccg8a+wGBCdJhDy5AK0BJRtxUxtLDeb+MkaTOfk/ylLfBdbFV1iK7Ek qDmpAZdd+FpwKoqBTm+jbCa/kemwFN5touLeLijRWjEuoqFK0x/YYRYsAjJUNqu/ Qt6YWqvat8t7UYlTauVsQ/9XJNxADxmWlrKaaQTxmsHrobq0h4s+RA== =ykck -----END PGP SIGNATURE-----

1 0

Why emoney? Why not a web of debt?
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

[summary -- digital silk road along a web of debt-trust] Umm... money is not anything mystical -- it is just a convienient way to trade and settle debts. It was invented to solve the hassels of trading a pound of butter, for a box of eggs, that for a tightly woven basket, and finaly that for the gun you wanted in the first place. Yuch! accounting!! But electronic computers are good at checking out these kinds of chains automatically. Suppose there were a web of debt-trust. Each person would indicate the other people who's iou's they will accept (and the amount they would be willing to take). Thus I might take (up to $10 of) Jo's, who might take Carol's who might take Terry's, etc. To buy something from me online, you will need to produce an IOU from Jo, Carol or Terry. I would hand it to Jo for verification. Jo would accept it or reject it (perhaps after talking to some other folks online). If it were a CarolIOU, or a TerryIOU I would insist Jo trade it for a JoIOU. All the details could be hidden behind a nice little GUI. Jo and I would continuously balance the books between us by trading JoIOUs for NoybIOU's. After a while one of us might well end up with enough extra IOUs that we want to get paid. Perhaps the other would perform services directly, or pay FRN's or gold, or whatever. If one of my friends wasn't able run an online IOU server, I could probably trade things with my friend for IOU's. Not that I'm running a bank or any thing. With out every one being on line though I don't see an easy way to prevent double spending. Is there a offline multiple exchange token system invented yet? Noyb

2 1

Re: Why emoney? Why not a web of debt?
by jrochkin＠cs.oberlin.edu 17 Dec '03

17 Dec '03

At 6:54 PM 01/20/95, anonymous-remailer(a)shell.portal.com wrote: > But electronic computers are good at checking out these kinds of >chains automatically. Suppose there were a web of debt-trust. Each >person would indicate the other people who's iou's they will accept >(and the amount they would be willing to take). Thus I might take (up >to $10 of) Jo's, who might take Carol's who might take Terry's, etc. > > To buy something from me online, you will need to produce an IOU >from Jo, Carol or Terry. I would hand it to Jo for verification. Jo >would accept it or reject it (perhaps after talking to some other >folks online). If it were a CarolIOU, or a TerryIOU I would insist Jo >trade it for a JoIOU. All the details could be hidden behind a nice >little GUI. Certainly, that's what money is after all. Pretty much. But how are you going to transfer these IOUs electronically in a way that is relatively fraud-proof? Digital money. Ecash. When we say "ecash", we're talking about what Chaum was writing about in whatever paper, what Schneier describes protocols for in AC. Maybe the ecash is redeemable in US dollars, or maybe it's redeemable for 10 units of service from Jon Smith, but an ecash protocol is what you are going to use to transfer and issue those digital certificates of value, whatever the value represents. And of course, if you want to use these certificates of value anonymously, which is what is required to pay for an anon remailer, there are some slightly more stringent requirements. The right kind of ecash protocol can still handle it. But Carol probably shouldn't be paying for a remailer in CarolBucks (or CarolIOUs, whatever), at least not unless Carol is such a big spender that CarolBucks are in wide circulation and used by lots of people other then Carol. Which I guess is possible in your system. A pseudo-anarchist non-state-supported debt system would work fine, but you still need a mechanism to transfer your certificates of value, whether they stand for ten U.S. dollars, or 10 hours that Jon Smith will work mowing your lawn. And another way to look at it is that you are just proposing an ecash system where every person issues their own ecash, instead of just a few central banks doing it. There are advantages and disadvantages to that sort of thing, and it might be something interesting to think about, but you ultimately aren't going to be able to do it over a computer network without ecash. Ecash is the way you represent value certificates in digital form, pretty much.

4 3

Purshottam
by John Young 17 Dec '03

17 Dec '03

>----- Forwarded message (Andrew Purshottam <andy(a)eon.netcom.com>) -----< Dear Mr. Purshottam, Mail to <andy(a)eon.netcom.com> boings.

1 0

Remailers-in-a-box
by Greg Broiles 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Tim May wrote: > I am waiting for such services to be actually, formally, solidly > announced, not just casual remarks that it might be possible. And of > course the software should be "ready to wear," port-a-potty, so that > the remailer account owner does nothing more than pay for the account. In this model, who deals with mailbombs/spams/requests for address blocks? It is this sort of administrivia (plus the threat of liability) that makes running a remailer troublesome, not a lack of someone's $20/month. I think it's disingenuous to say that "X pays the bills for the network link; X purchased the hardware and keeps it running; the box is in X's house/office; X is the person who reads complaint mail and responds (or fails to); but because Y sends X $20/month, the remailer (and attendant liability for its mis/use) belongs to Y." I realize that there's a certain formal logic to it, but I don't think that anyone - not courts, and not the world-in-general - is going to pay attention to that formalism when it's clear that a machine essentially under the control of X is being used for 'antisocial' means. I'm seriously considering offering this sort of remailer-in-a-box thing, but there's a certain amount of hassle associated with running a remailer. It can be shifted to different parties, but it must be paid for one way or another. I guess it'd be possible to treat remailers as disposable - when one had pissed off enough people, it could be abandoned - but this lack of long-term reliability seems poor. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLyBjVX3YhjZY3fMNAQEI3QP/YdqBbhn5k4Q+NtD3zoJCG7qIfGaQqogH AFFmItuU46rFQHHSxPl+p4fNmX+32yEva04ORq28NWPKggXiXhwN+LQDshWomSU8 gXkysIPdGeogSDxP6+JxXatE81TpuCjOtbGH3KlmCNaRbB0685zBVB7Oj1O/D5it zqM9JuV8yAE= =EQY5 -----END PGP SIGNATURE-----

5 6

Re: Why emoney? Why not a web of debt?
by davidm＠iconz.co.nz 17 Dec '03

17 Dec '03

>At 6:54 PM 01/20/95, anonymous-remailer(a)shell.portal.com wrote: >> But electronic computers are good at checking out these kinds of >>chains automatically. Suppose there were a web of debt-trust. Each >>person would indicate the other people who's iou's they will accept >>(and the amount they would be willing to take). > >Certainly, that's what money is after all. Pretty much. But how are you >going to transfer these IOUs electronically in a way that is relatively >fraud-proof? Digital money. Ecash. [...] > And another way to look at it is that you are just proposing an >ecash system where every person issues their own ecash, instead of just a >few central banks doing it. The question of how to value ecash issued by different entities of varied credit-worthiness is an interesting one. I had been thinking along the lines of one or more centralised (but independent) credit rating agencies (a la Standard and Poors or Moodys) that one would subscribe to. Then you would value the various edollars in terms of their credit rating -- so you might sell something for $4 of CyberCash (NA) BV ecash, or $5 of FliBiNite NL ecash and so on. But of course, since ecash is worth only what you can get for it, the web of trust model, since it reflects what people will give for it, seems to reflect that underlying value much better. The best way to underpin the value of ecash is for the issuer to (credibly) undertake to convert it into real money. This gets around the problem of no one on the net making enough things you want: the old 'you can't eat cyberspace' saw. McDonalds may not accept ecash, but if a simple trip to the relevant ebank's Web page can put the price of a Big Mac in your real-money account, that is only a timing problem. [Of course, you have to come out from behind the anonymous ecash shield to do that, but that is a problem of being a real person. If you want to keep your wealth anonymous, don't buy a flash car and the latest Monet to go on sale -- invest it in an anonymous corporation.] An ebank along these lines could be set up reasonably cheaply (apart from the technical hurdles ;-), and could easily scale up as needed, and migrate to safer (taxhaven/banking secrecy) jurisdictions when turnover etc warranted it. David

2 1

Send Me The Stuff
by Master-X 17 Dec '03

17 Dec '03

Please e-mail me with the stuff.

1 0

Re: Netherlands crypto ban?
by Rich Salz 17 Dec '03

17 Dec '03

In my opinion, The Netherlands will not adopt a crypto policy on their own, the'll do it if the EC proposes such a "thing". Several months ago at a security SIG meeting at OSF, a sr tech guy from Shell gave a presentation and I went and spoke with him afterwards. (Not being oblique, I just forget his name.) Shell needs public key because they want to use email for legal contracts. They've been waiting for standards to come around, but have given up. They're currently planning on using NIST's DSS, if they can fix a few things: - Add concepts of time and location (it can be important to prove that this was signed last month outside of the U.S.) - Add re-signing with only minor increase in size If there are licensing issues, "just buy them off." They don't like RSA because of the US licensing issues -- it's too hard to prove you only have to pay for a small portion of your use, for example. They like DSS because it explicitly does not support privacy, which is problematic in France, especially. He's reluctantly inventing this setup because the vendors haven't given him a world-wide public key story yet. (DCE 1.2 has/had some plans, and he wanted to push our licensees to support it, at least.) Interestingly, things have inverted and the EC (sorry, EU) is looking for Shell to set a standard. Several other large companies (Philips, etc) are also going to follow whatever Shell does. He thinks it'll be de-facto standard in 18-24 months. FYI. /r$

2 1

RE: Remailers-in-a-box
by Johnathan Corgan 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >I guess it'd be possible to treat remailers as disposable - when one >had pissed off enough people, it could be abandoned - but this lack >of long-term reliability seems poor. Someone had posted a protocol scheme that would allow new remailers to advertise their existence on a newsgroup, which would cause any number of auto pinging "reputation" services to begin monitoring this new remailer automatically. Once reliability, etc., was established, the reputation services would "add" this node to the remailernet. Similar actions would take place if a remailer just "went away". Quality of service, features, etc., would be part of the advertisement, and would result in a form of competition between remailers. Similarly, reputation services would have differing criteria for "blessing" a site, which would result in a form of competition between the _reputation servers_ for a good reputation. The key to this whole scheme is in the automation of the process. Done correctly, it would result in a self-organizing, self-healing ecology of remailers, that would naturally gravitate toward providing the features and services in most demand. Yeah, sure. Looks good on paper, anyway. Lots of real-life hassles to work out, but it _probably_ could be made to work. == Johnathan Corgan "Violence is the last refuge of the incompetent." jcorgan(a)scruznet.com -Isaac Asimov -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLyB9001Diok8GKihAQEZAAP+MU2qaWZahpOgsdoyk7XuHvAnMbNGgalw zJqLNz4H8knRINEZsDsTR7pIMbnhMWxlRfDtgXXNCE8KXvdCA3FkVyG4MItFn5vF fQZxw9rg87m/B9YwEOEah9N4RhNXs2RHsB8dVinMkncw9REklWbGkydcxf0EvKkc Y6JgzEkX54w= =Tu9L -----END PGP SIGNATURE-----

1 0

Hakim Bey URL, etc.
by dmandl＠panix.com 17 Dec '03

17 Dec '03

The URL for the Hakim Bey web site (someone might have already posted this) is: http://www.uio.no:80/~mwatz/bey/ Except from the Hakim Bey interview in "Axcess" magazine (conducted last summer): "I have to admit I felt a certain intense interest, perhaps even amounting to a potential enthusiasm, when this tech was first being discussed," Bey told me. I'd read William Gibson like the rest of us, and I certainly understood his dystopian point, but nevertheless, when Tim Leary and people like that began to get enthusiastic, I had to investigate on that level. I haven't seen much evidence that what Uncle Tim thought was going to happen is really happening. Once again, any technology could be democratic if it were distributed, you know what I mean? It's a simple Marxist thing about means of production. There's nothing inherently authoritarian--at least at first glance--to any technology, although one could argue about how technology then shapes the society that has already shaped the technology in a kind of feedback loop that can move towards greater and greater authoritarianism or lack of autonomy. The potential for what, back in the 50's and 60's, people were calling electronic democracy, is obviously still there as a potential structure. You can see certain elements of it in the Net, but when you're talking about the high tech involved in virtual reality you're really talking about something that is not accesible to most people. And I think it probably never will be. There's never going to be any cheap VR kit that's going to allow a dock worker in Manila to get on some kind of cyberspace Internet, much less a dock worker in Atlanta--or me, for example." Bey was equally gloomy about the future of the Internet. "My impression is that 90 per cent of what goes out over it is completely unrelated to any kind of freedom interests, autonomy proposals or projects, or struggles for genuine non-hierarchical, non-authoritarian group dynamic. Most of it is just chit-chat--banal chit-chat that could just as easily be carried out over an old-fashioned party line phone." Unabashed in my online addiction, I couldn't help but ask if he saw _any_ way to realize the internet as a T.A.Z. "I'm led to believe, through conversations with people who are much more techie and active than I am, that cypher--unbreakable code--is the key. So the cypherpunks are the people to keep an eye on at this moment. They tend to be the ones who are most active around freedom of speech issues...whether legal or extra-legal. Even so, Bey felt that the powers that be will never allow the "Information Superhighway" to develop unchecked. "I think Clipper was a declaration of war on the Net. The fact that the egg is on their face, because within ten minutes some hacker figured out how to beat the Clipper, is an indication of--oh, let's call it an area of chaos. Within areas of chaos, either horrible destruction and disease and death occur. Or, if you're flowing the right way, and if all hearts are beating in unison to a certain degree, then that area of chaos can become the T.A.Z. Now I've said over and over again that there's no such thing as a T.A.Z. that's only on the Net, and I maintain that that's true. In order to have autonomy, you have to have physicality. Autonomy is not something that can only exist in the imagination or in the world of images. I think that it involves the entirety, the whole axial being, and that is rooted in the earth and concerns physicality, materiality, the body--mortality, if you like--as contrasted to the spurious immortality of cyberspace. But I still maintain that, at least in theory, the Net could be an adjunct to the T.A.Z., could be a tool or a weapon, even, if you want to look at it that way, for the construction of the T.A.Z." -- Dave Mandl dmandl(a)panix.com

1 0

Re: The Remailer Crisis
by Jaeson.M.Engle＠josaiah.sewanee.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Okay. Here's my 2-bits. I run on the MacOS, but how hard could it be to port this code? If anyone is willing to do this (I assume it's not written in Pascal, which is my only language of any consequence), I will run it. It will be available from now until I graduate in '98 during the school months. If anyone wants to try this from scratch, we could try it in Pascal. I would be very willing to do the developing as well as host a discussion list for anyone who jumps in. I will take no responce to mean that all options are not going to be pursued, and that this discussion is just that, a discussion. - -Kyraden -----BEGIN PGP SIGNATURE----- Version: 2.6ui iQCVAgUBLyCKEEiLvmPjc4XdAQEGtAP/TqjIlPgmVWto4Gklrhj8F1LCyyb0urfD QGkGlFODmAuv8jyLHzXUHI8xjaNQHD/fSI7xtsuOODPfDMxuoPGJ6Myfx7OjZ7Ff nVagNeV6N3f1pVW8BLRaoP5gibnZZWq/c2tTuDbXF1wm3h594iP6leugT3Q+3112 NtBTMH6YPVE= =GX7K -----END PGP SIGNATURE----- aka: (-: Jaeson M. Engle || jme(a)josaiah.sewanee.edu :-) (-: www server: http://josaiah.sewanee.edu/ :-) (-: It's January 29th! IT'S TIME!!! Ask me for details!:-) (-: Finger 'jme(a)josaiah.sewanee.edu' for my Public :-) PGP block.

2 1

"Smart Roads" for toll collection and traffic logging
by northrop＠netcom.com 17 Dec '03

17 Dec '03

Here in Seattle there is a proposal to turn a couple of traffic chokepoints into toll roads. Because a toll plaza would back things up even worse, I'm guessing they'll look to an automated system that will let you pay without leaving your car. This is established tech -- a nifty article about it showed up in _Electronic Design_ last month. The downside is that it'll not be designed with privacy in mind at all, and will eventually have this pesky database of who went by the toll booth and when. We all know that old databases never die, they just get put on tape and stuffed in a box, to wait for someone with a curious streak to come by. This is a well-established problem with naiive designs of automated toll plazas, and I am looking for examples of things that could be done with this database by someone with ill intent, or could be done with the toll system itself if it got to be more widespread. - Obviously, if your car is talking to the road all the time, speeding tickets are a gimme. - You might be targeted for "further investigation" if you happen to drive by the wrong part of town. Gotta step up the heat on that war on drugs, ya know. I can come up with all sorts of ways to detect people from committing crimes (and don't really need those examples -- folks might think I *want* a Big Brother Highway!), but I'm curious what peoples' fears are about what this could mean to innocent folks, Joe Sixpack and his pals. There is a meeting in a few days where public comment on the toll road idea is being solicited, and I want to have some really compelling horror stories with which to capture peoples' imaginations about what a Big Brother Highway could mean. I want to scare people, but I want to scare 'em with something believable. If there's an archive that mentions anything like this, please point it out in private mail. I'll summarize what I get to the list, and also make that document available on the web, if anything interesting comes up. Thanks! Scott -- Scott Northrop (206)559-9878 northrop(a)netcom.com, northrop(a)mccaw.com Those who use arms well cultivate the Way and keep the rules. Thus they can govern in such a way as to prevail over the corrupt. -- Sun Tzu, The Art of War, Book IV

2 1

Re: The Remailer Crisis
by Jaeson.M.Engle＠josaiah.sewanee.edu 17 Dec '03

17 Dec '03

>But is your Mac on the Internet on a more or less continuous basis? A >remailer that only works when the owner happens to log on to collect >his mail is not terribly useful (though not useless, as others have >also noted....just a "very unpredictable lag time" remailer, sort of >the "surface mail" of e-mail). Yes, my machine has a 56k direct line in, 24 hrs. a day, 7 days a week (during school months!;-)) The server you just mailed to is on this machine. >It happens that the Net is mainly built up of Unix boxes, hence the >focus here on Unix. OS/2, Windows, and Mac boxes will be used >increasinly for constant connection applications, so the idea has >merit, long term. I understand this, and am trying my best to cope. I am currently in the process of developing a name server for the Mac, because the Mac has alot against it when it comes to being a real eintity on the 'Net. >(Another nit: the Mac, which is what I also use, currently lacks >preemptive multitasking. Thus, if one's Mac is playing a multimedia >CD-ROM when new mail comes in, it likely won't get remailed until the >first app quits or is manually switched out. (Yeah, a few things like >print drivers can run in background, and maybe the new TIA emulators >can trick the OS into processing SLIP or PPP mail in the background, >but who knows?) The consensus is that the Mac is powerful, but it >ain't cut out yet to be a Unix box.) I agree that the Mac lacks some of the more powerful Unix features, namely preemtive multitasking, but I also believe that, at least with the newer Macs, CPU time-sharing is more efficient than it used to be. Know of Chuck Shotton's MacHTTP WWW server for the Mac? An excelent piece of software that gives literally on demand, and at least with my copy, it is always in the background. Really about the only thing that cuts out CPU timesharing is multimedia, mostly 3D grahpis games and highly intense graphics software, neither of which I use (much!;-)) >The language is a lesser deal. Remember that Eric Hughes knocked out >the first remailer in Perl in a few days, and MacPerl exists for the >Mac. Going to Pascal would probably be more trouble than it's worth. I thought that it was in Perl. I have tried pulling Unix Perl scripts and running them under MacPerl, but it doesn't quite do it. In fact, it usually doesn't do anything but spew errors back at you. >But the most important feature to have is a solid, reliable connection >to the Net. A computer that gets taken to classes, is not connected to >the Net, etc., is not very useful as a remailer. As I noted, I have a constant 56k line in/ out. And mine never moves... it's a bit large... mine is a Quadra 660av (ugh). >(The key is not that a remailer can sometimes remail, but that it can >be counted on to be part of chain without the mail getting "dropped on >the floor.") > >--Tim May As far as I can tell, and maybe you have other knowedge on this, my situation should work, assuming I can run the software. What do you think? Should the remailer Perl script run under MacPerl? aka: (-: Jaeson M. Engle || jme(a)josaiah.sewanee.edu :-) (-: www server: http://josaiah.sewanee.edu/ :-) (-: It's February 3rd! IT'S TIME!!! Ask me for details!:-) (-: Finger 'jme(a)josaiah.sewanee.edu' for my Public :-) PGP block.

3 2

Re: Why emoney? Why not a web of debt?
by Anonymous 17 Dec '03

17 Dec '03

> Date: Fri, 20 Jan 1995 19:36:34 -0500 > From: jrochkin(a)cs.oberlin.edu (Jonathan Rochkind) > > Certainly, that's what money is after all. Pretty much. But how are you > going to transfer these IOUs electronically in a way that is relatively > fraud-proof? [...] By only trading with trusted partners. Read on... > And of course, if you want to use these certificates of value anonymously, > which is what is required to pay for an anon remailer, there are some > slightly more stringent requirements. The right kind of ecash protocol can > still handle it. But Carol probably shouldn't be paying for a remailer in > CarolBucks (or CarolIOUs, whatever), at least not unless Carol is such a > big spender that CarolBucks are in wide circulation and used by lots of > people other then Carol. Which I guess is possible in your system. If the remailer operator trusts Carol, then Carol and the Op can exchange Op-IOU's for money, or Carol-IOU's for Op-IOU's. (This is the base case of the induction for you math geeks.) Carol can use the Op-IOU's directly with the Op or 'sell' them to people who want to do business with the Op. If the remailer operator doesn't trust Carol, but there is a chain of trust from Carol to the remailer operator, then Carol can get IOUs from someone which the remailer operator does trust. Call them Jo-IOUs. To do this Carol asks Pat who asks ... who asks Jo for an IOU worth $32. Carol gives Pat a Carol-IOU worth $32(+transaction fee is Pat is a greedy sole) in exchange for which Pat gives Carol the Jo-IOU worth $32 (which Carol got from Pat (which Pat got from some place only Pat knows for sure)). IOU swaps will probably be done under the cover of encryption. Swaps can also be done with a nice ecash system like Chaum and Brandt(sp?) have proposed. But I am not sure it is required. Anonymity can come also from the chain of IOU swaps, in the same way remailers produce anonymity -- each person neglects to tell any others for whom they carry out IOU swaps. Sure Pat knows Carol wants a Jo IOU, but Pat doesn't know why. Jo could figure out that Jo's IOU went out to W.Smith, and came back from V.Jones but can't make any conclusion about weather W. and V. are trading partners or not. It would take a conspiracy of each person along the swap path to expose the real trade. Alternatively the buyer or seller can out the transaction. (But suppose they only know each other via some anonymous email pool...) And privacy (from other than your trading partners) comes from using encryption during each IOU swap. But if you don't trust your trading partners enough to keep quiet about who you are, by all means use an untraceable ecash system. (There are other advantages to using blind signatures anyway.) > A pseudo-anarchist non-state-supported debt system would work fine, but you > still need a mechanism to transfer your certificates of value, whether they Well... TackyTokens, and a little bit (ha!) of client code (start with Sameer's?) ought to do the trick. (So perhaps the original message's subject ought to have been "Why Ebanks? Why not a web of debt-trust?" since it is the central bank I am avoiding here. Not tacky tokens.) But it isn't really necesary. Read on... > [...] There are advantages and disadvantages to that > sort of thing, and it might be something interesting to think about, but One problem with getting an ecash system off the ground is making the tokens worth moeny. The advantage of a distributed web-of- debt/trust model is that I only need to trade IOUs for US$ with a few trusted friends. I don't need to go to any kind of central bank. No central bank means no central point to be attacked with guns, hacks, or taxes. No central bank means no credit card numbers, money orders, or green backs mailed away to strangers. Another cool thing, and the reason you don't need Chaumian digital cash, is that the only people you can steal from (or who can steal from you) are your trusted friends! If I pass a bogus token in exchange for a real IOU, then I just ripped off my friend. The only place two non-friends interface is at the final buyer-seller interface. If the seller refuses to honor the token, the buyer can ask the friend who gave it to them for a refund, who can ask for a refund from ... until the token gets back to the thief. The thief can either steal from their friend by refusing the refund, or infact honor the bogus token, and eat the loss (if any). One bad thing is anyone can deny service to people by passing bogus tokens, and then refunding them. Lukily the friends of the blocker will notice that when getting tokens through that person, the number of refunds is higher than average. In that case, the blocker can be removed from lists of their friends, and cut out of the economy. Denial of service can be prevented another way too -- but it does require Chaumian blind signatures. Instead of trading a Carol-IOU for any old Jo-IOU, Carol might demand a Jo-IOU which is a signature on a particular (blinded) secret number. Just as if Carol were doing a TackyToken protocol exchange directly with Jo. If Carol gets a thing from Pat which isn't signed by Jo, Carol complains to Pat. If Carol gets a thing which un-blinded isn't a signature by Jo of Carol's secret number, Carol again complains to Pat. Symbolically: instead of a <-> b, then b <-> c, then ... y <-> z; do a -> via b -> via c ... via y -> z signs -> via y ... via b -> to a. The disadvantage is that Pr0duct Cypher's Tacky Token code would need to be hacked a bit more. And then there is the nasty old issue of algorithm patents. Noyb

1 0

Re: The Remailer Crisis
by usura＠vox.xs4all.nl 17 Dec '03

17 Dec '03

jalicqui(a)prairienet.org (Jeff Licquia) writes: : Would it be better if you didn't have to dedicate your box to Linux, but : just ran it every so often when you weren't playing with Codewright? If you : had some store-and-forward mail system (like UUCP or Fido), you wouldn't : need to say goodbye to DOS/Windows. Patrick Oonk <kafka(a)xs4all.nl> has written a remailer for Waffle, (wich is an UUCP system), I use that for vox.xs4ll.nl . Is works under DOS. Regards, Alex de Joode usura(a)replay.com http://xs4all.nl/~usura

2 1

Re: Netherlands crypto ban?
by Alex de Joode 17 Dec '03

17 Dec '03

In article <gate.HRP0yc1w165w(a)dxm.ernet.in> you stated: : What's the update on the move to ban private crypto in Holland? : Last I remember there were trial balloons, but nothing happened. The proposed ban came from the former fundamentalist christian led department of justice. Since the elections the political landscape has been changed, the christian democratic party has been removed, we now have Liberals (something like Republicans in the US :) ), Socialists and Social Democrats in power. Law Enforcement has come under public scrutiny, since special police teams used unlawful tactics to get criminal organizations out of their business. They broke into Warehouses to see if narcotics were depostid there (without a warrant), they made up reports and lied in court. The new head of the justice department, already has dropped some policies that were in place, and she just announced that due to the rise in competence of the LEA the rights a suspect has also have to be raised in order to compensate it. She swiftly killed of any opposition the LEA had against that proposal. In my opinion, The Netherlands will not adopt a crypto policy on their own, the'll do it if the EC proposes such a "thing". -- Alex de Joode usura(a)replay.com Hate mail appreciated, http://www.xs4all.nl/~usura weekly contest for best death threat.

1 0

Re: Remailers-in-a-box
by Alex de Joode 17 Dec '03

17 Dec '03

: I guess it'd be possible to treat remailers as disposable - when one : had pissed off enough people, it could be abandoned - but this lack : of long-term reliability seems poor. The enrty point of a remailer could be "fixed", the exit point is where the heat is on. - The entry point of a remailer is entry(a)remail.org, - entry(a)remail.org has a forward file to: batch(a)remail.org - batch(a)remail.org does the actual remailing, since remail.org has installed some sort of MX'ing all messages that leave batch(a)remail.org will advertise themself as nobody(a)expendable.org . - If you "loose" expendable.org, you simple set up a new account with MX'ing, the remailer-users will only notice the change in exit-header, the enrty-point of that remailer is still entry(a)remail.org Ofcource you can make this as complicated as you like. :) Regards, -- Alex de Joode usura(a)replay.com Hate mail appreciated, http://www.xs4all.nl/~usura weekly contest for best death threat.

2 1

jpunix.com and MX'ing
by John A. Perry 17 Dec '03

17 Dec '03

PGP message

1 0

Remailer Crisis - Part II
by joelm＠eskimo.com 17 Dec '03

17 Dec '03

The "remailer-in-a-box" solution seems to be on its way to solving the ebbing number of remailers problem. The next step is to think of remailers in a supply and demand context. From a "maximizing your resources" standpoint, it doesn't make sense to have one hundred remailers available (aside from the chaining implications), if the usage/demand needs are met by twenty. It's important to create an infrastructure for a large scale remailer network, but the next step is to actually drive demand (obvious benefits of increasing privacy levels, blunting traffic analysis, creating a large enough population that will vocally protest if attempts to restrict remailers are made, etc.). I see two ways of doing this. The first step is education. Net users, especially the new ones, need to be educated about the use and benefits/limitations of remailers. Web pages are a good start. The information needs to be easy to understand yet compelling. Users need to be shown why remailers are important and be encouraged to at least try using them once ("want some candy little boy/girl"). The second step is access. With the advent of commercial Internet providers, the defacto Net access points are becoming GUI PCs and Macs. It is critical that tools be built for these platforms that make using remailers a transparent and simple task. (I don't want to belittle GUI users, I'm using Windows as I write this, but most would rather click a few buttons and use a list box rather than remember the :: syntax for embedding remailer commands in their e-mail.) This was part of my motivation for writing Private Idaho for Windows Eudora. I see good GUI premailers or integrated e-mail scripts as a critical element of remailer success. Joel McNamara joelm(a)eskimo.com - finger for PGP key

1 0

Supreme Court on Anonymous Bills
by Nathan Zook 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- $.02 (fiat) on Talley v California (recently posted here) It is important to note that this court is expected to significantly reverse some of the landmark cases from the Warren era. We should, therefore, to look to the dissent at least as much as to the court. There can be little question that any attacks on remailers and civilian strong crypto will face challenges on the basis of Free Speech and Equal Protection. The question is: can the state show compelling interest? I believe that it can. Anonymous agents, by their very nature, are immune from state restraint. Since our entire legal system centers around state restraint, I believe that Free Speech and Equal Protection will fall to the four horsemen. When we consider the decision, we note that one of the main reasons for voiding the ordinance on its face was that there were other remedies to the problems that the ordinance claimed to address. No such other remedies will exist in our case, that being part of the point of our systems. Considering the dissent, we see even more room, with the question of Equal Protection might not be extended on the basis that only electronic communications were hampered. There is the general question of political speech. Unfortunately, there is little anonymous _US_ political speech. Furthermore, sedition is a crime, and if the Founding Fathers printed the same things against our government that they did against England (they could do more), they would face a number of criminal charges. I believe, therefore, that both the court and the dissent bode poorly for anonymous encrypted mail. But these are not the only arguments we have. We have the questions of Enforcablity, Distinguishability, Privacy, and the Right to Bear Arms. One may argue with some force that it may be impossible to determine if a person is sending and receiving information (and requests for information) directly, or if they are acting as an anonymizing agent. One may argue with great force this difficulty, combined with the nature of the InterNet, would make general enforcement impossible--leading to the same type of failure as the Prohibition. One may argue forcably that the tools necessary to allow anymous encrypted traffic are the tools necessary to preserve the barest elements of privacy. Finally, since strong crypto has been ITAR limited, one may argue that the tools required are militia-type weapons, and as such, protected Arms. Finger or request keyserver for PGP 2.6.2 (tm) key. PGP<->Mail/News installation incomplete. Factors for modulous are not proven primes. Key may be far weaker than expected. Encode at your own risk. Key ID: 14712B4D 1994/12/26 Nathan H. Zook <nzook(a)bga.com> Key fingerprint = 44 B3 D8 66 3D 55 1E 2E F8 92 22 A6 33 8C DE 24 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBLyFKXnmgMs8UcStNAQFU+Af/SwmEoH2g/jZ1CtIRWevWkDQRl6Nnz1xe j8yyMtvrz86cshfD6hBYjCZ+wcihmCXM7NxuHdrbaXihTuCRspJdTheD9xUAr4sk qhqXlj4PqRVThg5FioD5/miuyLO6osJ02DfckpaWk0uJf6OBC9BIiOCzXnDVFaIh dXNfEq4pjkJPFxSR2UU7ru4EUrAKRT5keV2cZ8QjMeeQ5YksveTIO6GeStzJjAJr GQKSzdGF0qoauKsexHvaMDlbARhUEPx7vqufRWUsejkwDW73STZFBoFabcLpaJRs 9KwsSzdYFWlxtDlCpUIRFRAuxRlKCedOpEKRIYfIZy2bWSqqDbCz5A== =sxi2 -----END PGP SIGNATURE-----

2 1