// COMPLETE THREAD

"Anon" fake...

13 expanded posts ยท every known parent and child

NODE a45b1e7f"Anon" fake...
NODE 3dc570daRe: "Anon" fake...
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
NODE 15b7fd25"Anon" fake...
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
NODE e40c18b9Re: "Anon" fake...
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 :-)
NODE 6b98cdd6Re: "Anon" fake...
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.
NODE 8d13092aTuna fish spams a growing fact of life
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."
NODE 200aa467My light bulb goes on... (was:Re: Tuna fish...)
-----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-----
NODE d5f34251Re: My light bulb goes on... (was:Re: Tuna fish...)
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."
NODE e82668f2Re: My light bulb goes on... (was:Re: Tuna fish...)
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
NODE 783a6956My light bulb goes on... (was:Re: Tuna fish...)
> 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
NODE 5fd9232fRe: "Anon" fake...
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
NODE 0be83cdaRe: "Anon" fake...
"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
NODE c667f74bRe: "Anon" fake...
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.