December 2003 - cypherpunks-legacy

Re: The Remailer Crisis
by jalicqui＠prairienet.org 17 Dec '03

17 Dec '03

James wrote: >Now this is OK if one wishes to run linux, and have a >remailer as one hobby in addition to the main use of the >box, but it is still a bit much to pay for a dedicated >remailer. > >Now I just do not like linux. Sure it is a great >operating system but it will not run codewright > >(Vi causes mental degeneration. Even though I detest, >loath, and hate vi, vi takes up so much brainspace that >I find myself issueing vi commands in editors that I >use much more, and vastly prefer to vi. Vi is evil.) > >Therefore there is no way in the world I am going to >waste a full internet connection and a PC on linux. 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. I envision a setup right now where you could (if you wanted) type "remailer" at the DOS prompt to bring the remailer up. The screen would show a monitor-type program, with a menu option to "R)eboot" to DOS again (or you could just hit Ctrl-Alt-Del). Oh, and I'd probably package a much nicer editor than vi with it. Believe it or not, the state of Unix editors has progressed beyond vi (and even emacs). But that's assuming you'd need to pull up an editor at all...

3 2

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

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: 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: 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: 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

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: The Remailer Crisis
by jrochkin＠cs.oberlin.edu 17 Dec '03

17 Dec '03

At 11:14 PM 01/20/95, Rhys Kyraden wrote: >-----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 you are talking about remailer code, rather, I think. The mac doesn't have a built in mail system, like unix systems generally do, which you kind of need. First you've got to get a hold of a mail system for the MacOS, ideally not POPMail like Eudora, but actual receiving mail directly to your mac, and then you've got to modify it to do remailing. And that modification isn't going to be nearly as easy as in the world of unix with it's .forward files and /etc configuration files that let you pretty much direct output wherever you want. Basically, the amount of code you are going to have to be writing from scratch is going to outweigh any "porting" you are able to do with salvagable code. On the other hand, you could base a remailer on Eudora. Which means that people would right to your normal mail account with mail-to-be-remailed, and by means of some header lines distinguish the mail to be remailed. Eudora can filter mail according to header lines. And Eudora is applescriptable, and can call an external applescript (or actual binary executable program, if it does apple events. Which isn't trivial), and tell it new mail has arrived to be dealt with. Theoretically the external program could even check the body of the message for a :: Request Remailing-To: So they wouldn't need to put anything special in the header, like they don't need to with current remailers, even ones that run out of people's normal shell accounts. Theoretically, you could do that. But it would be rather unreliable, and slow. And if there was a lot of remailer traffic, it would get in the way of your normal email. I'm not sure it's worth putting in the amount of effort neccesary for what you are going to get. On the other hand, the amount of effort neccesary would be much much less then writing remailer code which worked with a mac mail system instead of POP mail, as discussed above. I dunno.

1 0