Re: Beware of anon.penet.fi message!

-----BEGIN PGP SIGNED MESSAGE-----

This is a longer response to the warning posted by Xavier.

> Beware of the message about the security bug in the
> anon.penet.fi software!

Indeed.

> If you do as requested, and send your true email address to
> an5877@anon.penet.fi then he will see both your true email
> address and your anonymous address (if you have one - if you
> don't, you will be assigned one and he will see that).  Any
> future use you make of this anonymous server (say, to post
> anonymously) will appear under that same anonymous address - and
> this person will know your true email address that goes with
> it.

You got me.  

I meant only slight malice here:  I had intended to "expose" a few
email/anon associations to highlight the problem.  The problem became
apparent to me when I sent pseudonymous mail to a prominent person on
this list; his reply exposed his pseudonymous id at anon.penet.fi,
surely without his knowledge.

> an5877's message appears to be a trick, designed to collect
> anonymous/real address pairs.  Johan Helsingius should take
> action against this trickster.  Since he is learning other
> people's real addresses, perhaps it would be appropriate for his
> own real address to be revealed.

Now that would be a _very_ serious "bug" in the anon.penet.fi remailer
(or, more accurately, in its administration); I am confident Johan
Helsingius will reject this suggestion.

> But, this does point out that these systems which automatically
> assign anonymous addrsses have several security flaws.  Johan
> has already had to introduce a "password" feature to make it
> more difficult to send fakemail that appears to be from a
> particular email address through the server, thus revealing the
> corresponding anonymous address when it is delivered.

I think that merely masks the real problem.

> an5877's trick is a variant on one discussed in
> news.admin.policy where it is pointed out that you can mail to
> someone via anon.penet.fi and ask for information; when the
> return mail comes back it will be from that person's anonymous
> address.  So again you can pair up real and anonymous
> addresses.

I missed that discussion, or I wouldn't have wasted your (our) time.

> These are serious problems.  We need some discussion of how to
> avoid these simple tricks for defeating the anonymity while
> still having an easy-to-use system.

Any ideas?  For starters, I think the default behavior of anon.penet.fi
is badly broken.  But a more serious problem with anon.penet.fi and the
other remailers I am aware of is the necessity that we pseudonymous
clients have to rely on the integrity of their administrators to keep
our pseudonyms private.  In the face of social pressure, such as
Xavier's, that may be asking a lot.

> ::Xavier::

DEADBEAT

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQBFAgUBK4lr4/FZTpBW/B35AQGqeAF/UBefmNprQacueYazdvhAKMF4nA+2vl44
/+FMACnWjd7yaoG99VeyhO/S6vptT1UB
=yZRb
-----END PGP SIGNATURE-----
-------------------------------------------------------------------------
To find out more about the anon service, send mail to help@anon.penet.fi.
Due to the double-blind system, any replies to this message will be anonymized,
and an anonymous id will be allocated automatically. You have been warned.
Please report any problems, inappropriate use etc. to admin@anon.penet.fi.
*IMPORTANT server security update*, mail to update@anon.penet.fi for details.

> I meant only slight malice here:  I had intended to "expose" a few
> email/anon associations to highlight the problem.  The problem became
> apparent to me when I sent pseudonymous mail to a prominent person on
> this list; his reply exposed his pseudonymous id at anon.penet.fi,
> surely without his knowledge.

I think this would be fixed by the "X-Anon-Anonymize: no" (or whatever)
hack. But for reasons I have outlined in the earlier round of
discussions, it can't be the default. Comments? 

> > an5877's message appears to be a trick, designed to collect
> > anonymous/real address pairs.  Johan Helsingius should take
> > action against this trickster.  Since he is learning other
> > people's real addresses, perhaps it would be appropriate for his
> > own real address to be revealed.
> 
> Now that would be a _very_ serious "bug" in the anon.penet.fi remailer
> (or, more accurately, in its administration); I am confident Johan
> Helsingius will reject this suggestion.

Definitely. I might block someone from using the server, but never (ok,
"never say never") expose somebody.

> > But, this does point out that these systems which automatically
> > assign anonymous addrsses have several security flaws.  Johan
> > has already had to introduce a "password" feature to make it
> > more difficult to send fakemail that appears to be from a
> > particular email address through the server, thus revealing the
> > corresponding anonymous address when it is delivered.
> 
> I think that merely masks the real problem.

It fixes *one* problem. I really appreciate suggestions for other
solutions.

> > These are serious problems.  We need some discussion of how to
> > avoid these simple tricks for defeating the anonymity while
> > still having an easy-to-use system.
> 
> Any ideas?  For starters, I think the default behavior of anon.penet.fi
> is badly broken.

There has been a lot of discussion about this, and I'm afraid it's too
late to change the *default* behavior now...

> But a more serious problem with anon.penet.fi and the
> other remailers I am aware of is the necessity that we pseudonymous
> clients have to rely on the integrity of their administrators to keep
> our pseudonyms private.  In the face of social pressure, such as
> Xavier's, that may be asking a lot.

True. And that's why PGP-based stuff & remailer chains is the way to go
for "hard" anonymity. But for posting to general newsgroups, we also
need a system with working return paths. This doesn't seem possible with
current remailer chain systems.

	Julf (admin@anon.penet.fi)

P.S. In case I forgot to announce it, as you could see from the message
I'm replying to, PGP stuff doesn't get stripped at anon.penet.fi
anymore.....

Currently to mail to person 1234 at penet, you send mail to 

	anon1234@penet.fi

This mail goes out anonymously from the sender, either using an
existing mail address or creating one.  But if one were able to reach
person 1234 also with the email address, say,

	name1234@penet.fi

the behavior could be _not_ to make this posting anonymous.

To wit, the 1234 indicates that you are replying to a pseudonymous
recipient, and the anon/name pair indicate whether the sender is
anonymous.  Thus no change in default behavior, and no new header
lines.

Eric

> Currently to mail to person 1234 at penet, you send mail to 
> 
> 	anon1234@penet.fi
> 
> This mail goes out anonymously from the sender, either using an
> existing mail address or creating one.  But if one were able to reach
> person 1234 also with the email address, say,
> 
> 	name1234@penet.fi
> 
> the behavior could be _not_ to make this posting anonymous.
> 
> To wit, the 1234 indicates that you are replying to a pseudonymous
> recipient, and the anon/name pair indicate whether the sender is
> anonymous.  Thus no change in default behavior, and no new header
> lines.

A great idea, Eric! Thanks!

Oh, a minor correction, it`s an1234, not anon1234.
So in the name of symmetry the non-anonymous path should be na1234.
Now we only have to fight about what the From: line in anonymous
messages ought to say, an1234 or na1234?

	Julf

Re: an1234 vs. na1234

Julf writes:
>Now we only have to fight about what the From: line in anonymous
>messages ought to say, an1234 or na1234?

You can determine the From: line by looking at the destination.

If the destination is to another alias, then you use "an1234", since
the reply should appear to be coming from another alias.  Using the
"an1234" address triggers the aliasing mechanism.  

On the other hand, if the destination is to a non-alias mailbox, then
use the "na1234" form.  In this way the alias mechanism is not invoked
upon reply.

For messages with more than one addressee, split all the alias
destinations into one message, and all the non-alias destinations into
another.  Set the From: line accordingly in each message.  This avoids
the attack of using a two-recipient message to invoke an incorrect
alias behavior.

For newsgroup postings, where no particular addressee is listed, and
for mailing lists, I would suggest using "na1234", but this probably
is a change in the default behavior for newsgroups.  You would like
newsgroups and mailing lists to act the same, and that means either
keeping a list of mailing list entry points (ick), or using the
"na1234" form.

Eric