nzook@fireant.ma.utexas.edu says:
Folks, we GOTTA do something about this...
The obvious and simple fix is to put code into the Majordomo implementation to prevent the subscription of an*@anon.penet.fi (note -- this wouldn't prevent subscriptions as na*@anon.penet.fi). I've pointed this out before -- unfortunately, the list maintainers don't have time to do it. Maybe someone could volunteer to do the change? You'd have to talk to Eric Hughes about how to do the work. Perry
I've pointed this out before -- unfortunately, the list maintainers don't have time to do it. Maybe someone could volunteer to do the change? You'd have to talk to Eric Hughes about how to do the work. Hugh Daniel (hugh@toad.com) is the one who maintains the mailing list software on toad.com. Hugh is very busy, so don't pester him if you don't have something constructive. For the record, and to prevent future misunderstandings, I don't have root on toad.com. Eric
Now that an??? is alleged to be off the list, I'll post this; I sent it to Hugh earlier, but it should be of use to anyone running a security-related majordomo: It should be simple enough to change RetMailAddr in majordomo.pl; right before it returns $ReplyTo, adding $ReplyTo =~ s/an(\d+)@anon.penet.fi/na\1@anon.penet.fi/; will switch an* addresses to na* ones... This lets an address subscribe, they just get automatically converted to na forms. (Alternatively, one can always drop in an abort in the ValidAddress function (if I remember that name right) to just abort on anything that matches penet.fi, but that would be rude, and merely escalate the problem...) _Mark_ ps. Has anyone added pgp support to majordomo? I might consider it... there are lots of issues -- but change the subject line if you want to talk about it on the list :-)
On Tue, 2 Aug 1994, Perry E. Metzger wrote:
nzook@fireant.ma.utexas.edu says:
Folks, we GOTTA do something about this...
The obvious and simple fix is to put code into the Majordomo implementation to prevent the subscription of an*@anon.penet.fi (note -- this wouldn't prevent subscriptions as na*@anon.penet.fi). I've pointed this out before -- unfortunately, the list maintainers don't have time to do it. Maybe someone could volunteer to do the change? You'd have to talk to Eric Hughes about how to do the work.
Perry
Perry (and other c'punks), I don't think the mechanism employed by the hacker is using "who" at all. Rather, it is someone who is subscribed to the list and has a program which looks at the author of each message to see if it is someone already in their database. If it is someone new, it automatically sends a message for that person into the anon service. If not, it simply ignores the message. There are LOTS of silent listeners on the list and it could be ANY of them. Stoping this is not going to be easy. I don't suppose Julf@penet.fi would be interested in recording the name of the site where all these requests are originating? Any other ideas? Lyman Finger lrh@crl.com for PGP 2.4 Public Key Block.
Lyman Hazelton says:
Perry (and other c'punks),
I don't think the mechanism employed by the hacker is using "who" at all.
The mechanism employed was obvious and simple -- someone subscribed an anXXX address to the list. Anyone looking at the subscription list can tell that, on their own. This technique has been used before. Perry
"Perry E. Metzger" says:
Lyman Hazelton says:
Perry (and other c'punks),
I don't think the mechanism employed by the hacker is using "who" at all.
The mechanism employed was obvious and simple -- someone subscribed an anXXX address to the list. Anyone looking at the subscription list can tell that, on their own. This technique has been used before.
BTW, this is not to say that other techniques aren't being employed by others right now using alt.test -- I'm just refering to what happened last week on this mailing list... Perry
On Tue, 2 Aug 1994, Lyman Hazelton wrote:
I don't think the mechanism employed by the hacker is using "who" at all. Rather, it is someone who is subscribed to the list and has a program which looks at the author of each message to see if it is someone already in their database. If it is someone new, it automatically sends a message for that person into the anon service. If not, it simply ignores the message. There are LOTS of silent listeners on the list and it could be ANY of them. Stoping this is not going to be easy. I don't Send out 9 barium messages, coded by the binary representation the number of the person sendig to, with 0 being no message.
You have them. Berzerk.
Lyman Hazelton wrote:
a message for that person into the anon service. If not, it simply ignores the message. There are LOTS of silent listeners on the list and it could be ANY of them. Stoping this is not going to be easy. I don't suppose Julf@penet.fi would be interested in recording the name of the site where all these requests are originating? Any other ideas?
Stopping attacks like this will not be easy: * the attacker is using alt.test (as I recall) to report results...this is precisely the "anonymous pool" we argue for, for untraceability. * if he's as smart as I suspect, he's also bouncing the messages to penet through Cypherpunks-type remailers first. This makes it harder (a little harder now, with our fragile remailers, *much* harder someday) for Julf to "record the name of the site where all these requests are originating." The fragility of the Net exposes it to spamming attacks. And I think Julf agrees that a rewrite of the code at his site is overdue....he's mentioned this here, and is seeking donations. (Personally, I think the "volunteer" aspect is at fault here: tens of thousands of users use it for "free," while the software can't be rewritten or maintained adequately. Why not a commercial service? And the same arguments apply, as always, for the Cypherpunks model of remailers.) --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."
-----BEGIN PGP SIGNED MESSAGE----- In list.cypherpunks, Tim strikes gold:
(Personally, I think the "volunteer" aspect is at fault here: tens of thousands of users use it for "free," while the software can't be rewritten or maintained adequately. Why not a commercial service? And the same arguments apply, as always, for the Cypherpunks model of remailers.)
Is this not the killer app that would get ecash off and running? A commercial service selling cyberspatial privacy and accepting anonymous ecash for the service sounds like a natural! - -- Roy M. Silvernail [ ] roy@sendai.cybrspc.mn.org PGP public key available by mail echo /get /pub/pubkey.asc | mail file-request@cybrspc.mn.org These are, of course, my opinions (and my machines) -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBLj7KmRvikii9febJAQELhQP+KhmOsjCGK14WxJtObmmzhhqZ3szhU7LE XgryCYddLuy7XJlj2ANcdSIu47OClyBO+eCl4vr/mUEorNxFkpb4MAQPxyrP3Ha3 gsl1MfLavlO2tZhUWKkPN2XGuInYoFbyYi0lljOD4LRuH/pGlxUtdRZnEp91vPXJ LathIAIzPBQ= =0SGR -----END PGP SIGNATURE-----
Roy M. Silvernail says:
In list.cypherpunks, Tim strikes gold:
(Personally, I think the "volunteer" aspect is at fault here: tens of thousands of users use it for "free," while the software can't be rewritten or maintained adequately. Why not a commercial service? And the same arguments apply, as always, for the Cypherpunks model of remailers.)
Is this not the killer app that would get ecash off and running? A commercial service selling cyberspatial privacy and accepting anonymous ecash for the service sounds like a natural!
The problem is not a need for a killer app -- there are dozens. The obstacle is regulatory problems, and finding a large and reputable sponsoring organization (like a big bank). Perry
Is this not the killer app that would get ecash off and running?
The problem is not a need for a killer app -- there are dozens. The obstacle is regulatory problems, and finding a large and reputable sponsoring organization (like a big bank). And these two issues are related. Bank regulations in this country are kept deliberately somewhat vague. The regulator's word is the deciding principle, not a detailed interpretation of statute. The lines are fuzzy, and because they are fuzzy, the banks don't press on them nearly as hard as when there's clear statutory language available to be interpreted in a court. The uncertainty in the regulatory environment _increases_ the hold the regulators have over the banks. And the regulators are known for being decidedly finicky. Their decisions are largely not subject to appeal (except for the flagrant stuff, which the regulators are smart enough not to do too often), and there's no protection against cross-linking issues. If a bank does something untoward in, say, mortgage banking, they may find, say, their interstate branching possibilities seem suddenly much dimmer. The Dept. of Treasury doesn't want untraceable transactions. Need I say more? Probably. It's very unlikely that a USA bank will be the one to deploy anonymous digital dollars first. It's much more likely that the first dollar digital cash will be issued overseas, possibly London. By the same token, the non-dollar regulation on banks in this country is not the same as the dollar regulation, so it's quite possible that the New York banks may be the first issuers of digital cash, in pounds sterling, say. There will be two stages in actually deploying digital cash. By digital cash, here, I mean a retail phenomenon, available anybody. The first will be to digitize money, and the second will be to anonymize it. Efforts are already well underway to make more-or-less secure digital funds transfers with reasonably low transaction fees (not transaction costs, which are much more than just fees). These efforts, as long as they retain some traceability, will almost certainly succeed first in the marketplace, because (and this is vital) the regulatory environment against anonymity is not compromised. Once, however, money has been digitized, one of the services available for purchase can be the anonymous transfer of funds. I expect that the first digitization of money won't be fully fungible. For example, if you allow me to take money out of your checking account by automatic debit, there is risk that the money won't be there when I ask for it. Therefore that kind of money won't be completely fungible, because money authorized from one person won't be completely identical with money from another. It may be a risk issue, it may be a timeliness issue, it may be a fee issue; I don't know, but it's unlikely to be perfect. Now, as the characteristic size of a business decreases, the relative costs of dealing with whatever imperfection there is will be greater. To wit, the small player will still have some problem getting paid, although certainly less than now. Digital cash solves many of these problems. The clearing is immediate and final (no transaction reversals). The number of entities to deal with is greatly reduced, hopefully to one. The need and risk and cost of accounts receivables is eliminated. It's anonymous. There will be services which will desire these advantages, enough to support a digital cash infrastructure. Eric
Roy Silvernail writes:
In list.cypherpunks, Tim strikes gold:
(Personally, I think the "volunteer" aspect is at fault here: tens of thousands of users use it for "free," while the software can't be rewritten or maintained adequately. Why not a commercial service? And the same arguments apply, as always, for the Cypherpunks model of remailers.)
Is this not the killer app that would get ecash off and running? A commercial service selling cyberspatial privacy and accepting anonymous ecash for the service sounds like a natural!
Thanks, Roy, but I've been arguing this for a -long_ time, as have others. The "digital postage" proposal (stamps, coupons, simple digital cash) fits right in. Current remailers are run in a haphazard way, with poorly-stated policies in some cases, with haphazard maintenance, and with no profit motive to push for higher performance, better reliability, and, critically, with a commitment to service and long-term viability that a real business would have. (To pick one example, without picking on particular people, it's real hard to take a remailer seriously when it goes up and down, when it bounces mail, or when a terse message is broadcast saying: "My remailer is going down for a while because I'm taking my laptop to Portugal for the summer." I'm not picking on these folks, who are running remailers as an experiment and as a free service, but this is part of the overall problem we face.) There are many issues about remailers that have been written about. Feature sets such as padding, types of encryption, reordering, etc. I've written long posts on this, and so have such folks as Hal Finney, Ray Cromwell, Matthew Ghio, Graham Toal, and others. (We get a lot of "Say, what if remailers waited a while before remailing?" comments, which sometimes get responded to, but which are often dismissed. Suffice it to say that a taxonomy of features can be developed, but casual analyses of just part of the situation tend not be helpful.) "Mom and Pop remailers" is my term for the for-profit remailer services which people could install in their homes, hook up to the Net, and operate for profit. Digital postage, at a rate they choose and others can then accept or not accept (and thus not use them). Yes, a good opportunity for an entrepreneurial Cypherpunk. Lots of good issues to consider. (I'll throw out one random idea, one of many: a bunch of remailer operators (henceforth, just "remailers") can organize themselves into a kind of "Remailer's Guild." Purely voluntary, as all aspects of remailers are. The 100 or so members, for instance, could agree to meet certain standards of confidentiality, and kick out anyone who violates this standard. For example. Spamming is reduced in a couple of ways. First, all messages are "paid for" by digital postage (set at different rates, or by the Guild, all self-arranged). Second, targetting of any single remailer by a malicious attacker can be solved by the Guild's arrangement to distribute traffic amongst themselves, especially before what is likely to be a "final" delivery. I have a clear idea of this scenario, and why it helps a lot to distribute risk, but this brief paragraph may not be sufficient to make the points clearly enough. If there's enough interest, I'll elaborate more carefully.) I hope this helps. But newcomers should understand that hundreds of posts have been made about these subjects. Perhaps the archive sites mentioned here have some of them. --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."
participants (8)
-
Berzerk -
hughes＠ah.com -
Lyman Hazelton -
Mark W. Eichin -
nzook＠math.utexas.edu -
Perry E. Metzger -
roy＠sendai.cybrspc.mn.org -
tcmay＠netcom.com