December 2003 - cypherpunks-legacy

Re: for-pay remailers and FV (Was Re: Remailer Abuse)
by Nathaniel Borenstein 17 Dec '03

17 Dec '03

Excerpts from fv: 6-Jan-95 for-pay remailers and FV (W.. jrochkin(a)cs.oberlin.edu (4416*) > Hmm. Maybe I don't completely understand how this is going to work, but > won't _every_ remailer in the chain need to know your FV billing account? > How would the rest of them charge via FV without knowing your billing > account? What Russell was suggesting (I think), was that only the first > would bill via FV directly, so only the first would need to know your > billing account, and then he'd settle up with the others at the end of the > month. (A particular variation of that scheme is what you mentioned later > in your message, and I'll get to that). The latter is what I was proposing. Only the first one would charge via FV, but the other ones would form a "closed system" that you could only get into by going through one that charged. > But assuming that every remailer along the chain _was_ charging via FV, I > fail to see how only the last one would need your billing account; seems to > me they all would, and thus any one could collude with FV to violate your > anonimity. That's not my assumption. I think you may have misread my mail -- I *agree* with you on this point. Sorry if I was unclear! > The > remailer operators still have to have an organization and remain in close > contact, which I am uncomfortable with because it seems to make collusion > more likely. As I said, it all depends on your level of paranoia.... I tend to think that in such an organization, where the primary "product" is privacy, each member would tend to watch all the other members like hawks, eager to publicize any instance of the other guy not being sufficiently zealous in protecting privacy. (Of course, I'm assuming that people like *you* will be running these services, i.e. people even more paranoid about privacy than me.) > And it's still dificult to intermix for-pay and free remailers > within your chain, or even just for-pay remailers from several different > consortiums. I think this is wrong. In my model, each consortium model has two, a for-pay and a for-free. Anyone can send to a for-pay, but only a consortium remailer can send to a for-free. Not that complicated, really. > [The > consortium, as far as I can tell, would also find it rather dificult to > charge more for a longer chain, I can't think of any way for them to charge > anything excpet a uniform amount regardless of length of chain, unless you > give the first remailer a way to tell the length of your chain, which is > undesirable. I'm not sure if this is a problem.] To my mind, that's not a bug, it's a feature. The consortium is charging you a set fee for privacy, and you get to decide how many hops are required to have a level of privacy you trust. > And this level of paranoia would be perfectly well surved by a Julf/penet > style remailer, which _would_ work well with an FV-payment system, as I > agreed before. The cypherpunks chained remailernet system as a whole is > overkill for your paranoia needs, but appearantly not for the needs of > those who use it over Julf's. It appears to me, that an FV-style payment > scheme can't be added to the cypherpunks chained remailer system without > dropping it's security to the level of Julf's. Which might be good enough > for you, but not good enough for me, or presumably for anyone else that > uses cypherpunks remailers. This is true of the scheme that I said I would be satisfied with (one remailer + FV), but not true, I think, of the "overkill" scheme, which was the consortium. > [Do you understand how cypherpunks remailers work, and the difference > between them and a julf/penet style remailer? Do you understand how > encryption is used in a cypherpunks-style remailer chain to make it so each > individual remailer only knows the next remailer along the chain, and not > the entire rest of the chain?] Well, I *think* I do, though I may be suffering from a bit of dilletantism here -- I'm certainly no expert in cryptography, but I think I understand the concepts involved. We haven't even gotten into the effect of encryption yet -- so far, we've just been talking, I thought, about untraceability. But as far as I can see, there's no reason that the consortium pay-only-at-entry scheme couldn't work with encrypted remailers. Am I confused? Couldn't you use the same cryptographic chain as is currently used, where all the inner entries in the chain are free crypto-remailers open only to other consortium remailers, but in which the outer encrypted message had the FV payment attached, which gained it entry to the remailer pool? > Try to bring up objections to a digicash-style system that are applicable > to remailers. I agree that they are different technologies that fill > different requirements, but it seems to me that the particular requirements > of a remailer system are only met by a digicash/magic money style > technology. Again, I think you mis-read me. I haven't (nor do I care to) spent a lot of time thinking about how to do remailers at all, let alone with digicash. What I was referring to was the basic objections that come from using a digital cash scheme in the first place. > I think an electronic cash system that will work with remailers, must > satisfy these things: > 1) You need to be able to enclose the "signifyer" of the transaction inside > encryption. Whether the "signifyer" is the cash itself, or an agreement to > make a transaction together with a billing number, or whatever, you need to > be able to enclose it in a PGP (or other arbitrary PKE protocol) encrypted > block. > 2) The "signifyer" of the transaction (which again might theoretically be > the cash itself, or some kind of billing number) alone shouldn't be enough > to reveal the identity of the anonymous user. I agree that FV doesn't meet the above requirements, but I don't see why they're necessary for remailers. In the consortium scheme I'd proposed, the only thing that could ever be proven about you would be that you had used a remailer. Now, if the message was not encrypted, your anonymity could be broken by collusion of FV and the "entry" remailer. But if the cypherpunks style cryptographic chain was used, i.e. if the contents (including an inner envelope that said who you really sent it to) were encrypted, nothing more would ever be derivable without the collusion of everyone in the chain, and even then it would only be derivable if certain records were kept. All I'm claiming is that it's do-able using the FV payment system. I'm not going to do it myself because I don't personally feel that this level of untraceability is EVER legitimately necessary..... -- Nathaniel

6 6

Re: floating point crypto?
by rah＠shipwright.com 17 Dec '03

17 Dec '03

At 6:51 PM 1/5/95, Timothy C. May wrote: >Robert H. has asked that we reply in e-mail to him, to avoid >"cluttering the list more than I already have...," but the logic of >this is faulty. The few lines of a response such as this one, or even >of several such responses, are as nothing compared to dozens or more >people sifting their own archives so they can each independently send >Robert what they find. Hence my public reply. Got that right. No one can be more chagrined than I about this, because I've seen it happen. I remember Way Back in Ancient History (1985) when someone who couldn't remember the name of the movie posted the plot to "Slient Running" to net.sf(?), and asked for e-mail answers, so it "wouldn't clog the newsgroup". He was begging for mercy as little as 4 hours later... How soon they forget. I'm lucky it didn't happen to me. Thanks Tim, for saving my bacon. Nonetheless, I *am* thankful to Jim Gillogly, who sent me a great bunch of stuff about what the pentium.whistleblower, Dr. Nicely, was working on. Jim said he got it out of WWW, and maybe he'll post the URL here and that will be that. Nicely was working with finding multiple primes: Prime twins, prime triplets, etc. I will now proceed to post the relevant bits of Jim's and Tim's stuff to the newsgroup I got "called" in. Thanks to everyone who sent me comments, pointers, etc. >Not to sound strident, but if folks would keep copies of articles and >spend some time organizing them in data bases or in other searchable >forms, this would help the list. In my opinion, having personal access >to past posts is several orders of magnitude more important than >having MIDI-MIME JPEG-II TeX players that can display "Cypherpunks R >Us" in the correct font and with the "R" reversed according to spec. Indeed. Having limited space on my poor PowerBook, I have kept mostly the "excrable e$" types of files, to wit: anything mentioning money, finance, economics, and whatever crypto is specific to those areas. Since I started hanging out here this spring, I've accumulated about 10 megs of stuff between this list and www-buyinfo. I just archived everything from November backwards into Stuffit-compressed Eudora mailboxes. If you want those, I've got 'em. I did search the files I have after the "great squeeze", but to no avail. Unfortunately, I did not think I would have to keep anything to do with WIntel and their potential tribulations. I am, after all a Certified Macintosh Bigot. Thanks again, everyone. Cheers, Bob Hettinga ----------------- Robert Hettinga (rah(a)shipwright.com) "There is no difference between someone Shipwright Development Corporation who eats too little and sees Heaven and 44 Farquhar Street someone who drinks too much and sees Boston, MA 02331 USA snakes." -- Bertrand Russell (617) 323-7923

2 1

Re: Remailer Abuse
by Dr. D.C. Williams 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Jonathan replied: > One thing to keep in mind, though, is that it's really the _last_ remailer > in the chain that's taking the most heat, and it would be nice if they got > payed. Unfortunately, this creates the closest association between specific traffic and paying customers. > There's also an issue of some remailers refusing to be last in the > chain, so they dont' expose themselves so much. So the remailers which > _did_ agree to be last in the chain would obviously get used for this > purpose, while the others wouldn't, but they wouldn't get any more money > for it. What's to prevent mail from remailer A sent to remailer B from being sent right back to A for delivery? That's a part of the mixing required for true randomness. I don't know if this is being done now (by Chain or premail), and I'd like to know why. There might well be a good reason I'm not aware of. In order to join the mesh, remailers would be required to accept and ultimately deliver mail to ensure equality among them. I believe that a class of "prime" remailers would arise; these would be the preferred remailers, and their input and output would largely be balanced. This assumes, of course, that "second-class" remailers (those which profit equally but don't deliver as the last unit in the chain) aren't allowed in on a equal basis. Prime operators deserve, and would receive, compensation. > They might even get less, since most people probably don't use the > same remailer twice in a chain, so the ones agreeing to be last are hardly > ever going to be first. That seems undesirable. See above. What's the difference between A-->B-->C-->B and A-->B-->C-->D ? If someone is logging messages and routing, it's less secure, but then so is the entire remailer system. Prime remailer operators are those who don't log. Maybe message size would tip off snoopers. This can be overcome with minor tweaking to existing remailer code by tacking on or or eliminating padding to messages. But logging still makes the whole system extremely vulnerable. > remailers, since that poses even more exposure to heat, and it would be > nice if ops were conpensated for. Agreed. But since the payment "on the way out" (i.e.; a store) is much less desirable (and would probably work to reduce traffic), payment "on the way in" (i.e.; the subway) seems like the preferred alternative. =D.C. Williams <dcwill(a)ee.unr.edu> - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLw3RLCoZzwIn1bdtAQHpYgF/brIk7ssBTsR+26TqW6MifGwz+lymbXlc cYWFzNCJcrbRTgy7zHgPisvk/roHW0Nv =XJAq -----END PGP SIGNATURE-----

1 0

Re: sniff passwords on PC (DOS)
by pstemari＠erinet.com 17 Dec '03

17 Dec '03

At 01:00 AM 1/6/95 CST, m00012(a)KANGA.STCLOUD.MSUS.EDU wrote: > ... It does not work after starting windows. Not sure, but it seems obvious >that MS windows installs it's own keyboard interrupt. ... True, but it's fairly simple to write a program that loads itselfs in win.ini and also hooks the keyboard messages from Windows. --Paul J. Ste. Marie pstemari(a)well.sf.ca.us, pstemari(a)erinet.com

3 2

The Carol Anne Controversy
by bshantz＠spry.com 17 Dec '03

17 Dec '03

C'Punks, Well, folks, this has certainly been an exciting SPAM/FLAME war we've been watching. I've personally enjoyed skipping a good portion of the text of the messages and just watching the headers continue to grow in size as more and more people have been added to the CC list. Although, I must admit that I enjoyed the Winternet Sysadmin's Rebuttal. Between this and Matt's article about being an international arms courier (Great Article Matt!!!) I've discovered my own answer to the Soap Operas I miss while I'm at work every day. Think I'll go make some popcorn and sit back to watch the fireworks some more. -- Brad

2 1

Re: Remailer Abuse
by pstemari＠erinet.com 17 Dec '03

17 Dec '03

At 03:44 PM 1/6/95 -0500, Jonathan Rochkind wrote: > ... Why? Why wouldn't the FV remailers use settlements? At the end of >>the month, everyone settles accounts in re who gets what fraction of >>what. No logs are needed other than counters. > > ... 1) The initial remailer has no way of knowing how many subsequent links >there are in the chain, and so doesn't know if I've paid him enough to >reimburse everyone else. I can easily cheat. He also doesn't know _who_ >the subsequent chains are. He can deduct one "stamp" from the amount, and >forward the rest on to the next remailer, and trust them to do the same, >but if I'm cheating there won't be enough to make it to the end of the >chain. Both of these facts (initial op doens't know how long the chain >will be, or who will be on it) are essential to the security I get from >using anon remailers, so even if they could be "fixed", it would be bad to. No, basically the idea is that each stamp covers an average number of remailer hops. The remailer ops get together, with counts of their ins and outs to each other, and split some fraction of the stamp prices accordingly. They can even determine the average number of hops given the in/out counts. Fairly simple, actually. --Paul J. Ste. Marie pstemari(a)well.sf.ca.us, pstemari(a)erinet.com

1 0

Re: Can someone verify this conjecture for me?
by Hal 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- From: nelson(a)crynwr.com (Russell Nelson) > > I'd like to make sure I understand how a digital mix works. I've read > Chaum's paper on it, but hey, there's a reason why I don't have a Phd > in spite of having all the coursework done. > > It seems like it solves two separate problems: 1) foiling traffic > analysis, and 2) foiling a cheater remailer. The problems are > separate, really, because if you really, really trust the remailer (as > many people do Julf), then 2) isn't a problem. All you need to do is > solve 1. Or, you can solve 1) by using a single remailer. A > necessary but not sufficient step to foil traffic analysis is to strip > headers. My take on the paper is that he first presents the "mix", or remailer, as a method of foiling traffic analysis. Then he extends this to the "cascade", or chain of remailers, which does not improve traffic analysis resistence but as you say provides some immunity against a bad operator. > If you trust any one remailer, then you needn't bother using any other > ones (assuming that remailer has enough traffic, delay, mixing, etc to > foil traffic analysis). There's no real difference between using a > set (N>1) of trusted remailers and using only one, because you can > consider the set of remailers to be a single remailer from the point > of view of traffic analysis. There are other differences which may be relevant in practice. One is bandwidth. With a Chaumian cascade of N remailers you get N times the bandwidth used, as well as increased latency through the remailer network. One thing that is not often appreciated in Chaum's paper is that at least in his first description of the cascade, the assumption is that all users use the same sequence of remailers in the same order. We OTOH usually assume a different model, where the different possible paths are chosen with some distribution and randomness. I posted an analysis of some of the impacts of this difference a few months ago. Hal -----BEGIN PGP SIGNATURE----- Version: 2.6 iQBVAwUBLw4ZXhnMLJtOy9MBAQGjtwIA7tlEMnKPqUAVqAMSmK6EE6eaOlzhqeLL hsHXhNJajyZQjF6osybGSYJ00UBhRkbAxUOtjY4MNf6oMrb9fKRxGg== =A3oZ -----END PGP SIGNATURE-----

1 0

Peter D. Lewis
by L. Todd Masco 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Culled from a columbia newsgroup: >WIRED magazine now has a "Peter Lewis Prize for Bad Internet >Reporting". Check out: http://www.hotwired.com/Signal/Flux/ where >they announce the prize each week. Also read the story how Reuters >muffed up the Microsoft/Catholic Church reporting. You know it's bad when WIRED accuses you of bad reporting. - -- Todd Masco | "life without caution/ the only worth living / love for a man/ cactus(a)hks.net | love for a woman/ love for the facts/ protectless" - A Rich Cactus' Homepage - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLw3l5yoZzwIn1bdtAQHYmwGAmV97gzR8Tcl4b5iWMtRSbxUGKGFjEErS CNbc4fIyVrRnpUg55T8PSB9RktUn/I5K =OK63 -----END PGP SIGNATURE-----

3 2

procnail
by Nesta Stubbs 17 Dec '03

17 Dec '03

in response to the recent barrage of nonsensical bullshit here, I was wondering if anyone knew the archive site or procmail, the mail filtering program? I think this is a good time to school everyone in the basics of Killfiles. I have never wanted to killfile a person before, this is a big step for me. 8) i want to know everything http://www.mcs.com/~nesta/home.html i want to be everywhere Nesta's Home Page i want to fuck everyone in the world & i want to do something that matters /-/ a s t e zine

3 2

Re: Peter D. Lewis
by L. Todd Masco 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Tim sez: > I think Kelly is a person of high integrity. It's hard to demand much > more than this. I simply can't think much of a magazine that has cover stories deriving entirely from kiddie-kracker squabbles. Kelly may have plenty of integrity but that's not the word that the magazine "Wired" usually brings to mind. It's not the profit motive or the ads that get me: running a business, I know you can't be picky about who you take money from. It's the lack of meaningful content that annoys me. As with Lewis, frequenly when they're discussing something I know something about their stories are fraught with inaccuracies and rumours. My personal favorite is when they list reporters among the "experts" on their technology-watch light bites. Their entire approach is to cast Like "Seventeen," "Wired" should prepend "don't you wish you were" to its title. - -- Todd Masco | "life without caution/ the only worth living / love for a man/ cactus(a)hks.net | love for a woman/ love for the facts/ protectless" - A Rich Cactus' Homepage - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLw4tbioZzwIn1bdtAQEM7gF9EZE2qciEPOqQTYjwiqDF9vakwzSS3DSh ZJy1S0gTP7kNSTDnm/8UuoVOxehFhJ+X =g0sd -----END PGP SIGNATURE-----

2 1