[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

New anon mailer idea?



*** This message is not from the person in the headers above.
*** Reply to this message as normal, but be sure to include the
*** following three lines in the mail when you do:
*** Remailer-Reply-To: fdwgfjghfsdvkglhfslkjghfdkjhgkjfhgkfhg
*** 	ljdfhkjhgfkjhfgkvjhfklvgkfjhvbgjkfhgjkhfgfkjhgjkfhgjf
***	jkfdhkjfhgk;hfdgklhfdlgfldjkglkjfhg;hfgkjhfhgfghfkdhg
*** Your reply mail will be anonymised.

:From: Matthew J Ghio <[email protected]>

:> How about generating a secure hash and using that as an index
:> into a table?  If there's an address already there, use that -
:> otherwise, generate one.
:> 
:> Generate the hash from the incoming address, of course.  That way,
:> you  don't need to keep track of anon-id-to-real-id mappings, yet
:> guarantee that each user has one and only one anon address. Of
:> course, folks coming in from different hosts will have different
:> anon ID's.
:> 
:> Or have I missed some blindingly obvious technical point thaqt
:> would make this impossible?

:I don't see how this would prevent me from having to keep track of
:anon-id-to-real-id mappings.  It could work for sending mail, but I'd
:still have to have some way of keeping track of the real ids for the
:replies.

Excuse me butting in to a discussion I haven't really been following (I
don't have a lot of interest in remailers); I'm wondering if everyone
is missing some terribly obvious point here.

Without knowing too much about how the current anon/remail stuff works,
tell me what you think of this way of doing things (apologies if it's
what someone already does or has been discussed recently).

I want to mail fred@somesite anonymously.  I know fred@somesite's
public key.  I encrypt my message for fred, then send it to a
remailer address with instructions to pass it on to fred.  For a little
eavesdropping security, I include an anonymous pgp key of mine
in the mail to fred so that he can reply to me without the remailer
operators reading his mail.  You can choose your favourite syntax
for how I ask the remailer to send this mail to fred - I don't care
what it is.


The remailer then encrypts *my reply mail address* with the remailers own
key, and inserts this as a header in the mail which only it can read.
It attaches a little message to this header saying 'when you reply to
this message, be sure to include this opaque header I'm giving
you here...'

The recipient gets the mail, decodes it, reads it, and replies.
(Maybe encrypted with an anonymous public key I included in the
mail, maybe in cleartext - doesn't matter for the scheme) When
he replies, he included the small encrypted block that the remailer
gave him at the top of his message, as he was asked to do by the
remailer.

The reply goes to the anonymous remailer.  The anonymous remailer
decrypts the header block that it searches the mail for, and
extracts my email address from it again.  The remailer then passes
the mail back to me - this time including an encrypted block with
the fred@somesite's address in it.  (Or some other address if
fred replied from another account; or perhaps I mailed a mail
to news gateway - well, my encrypted address will still work
even if a dozen people reply to the news article by mailing
via the remailer, and now I *don't* know who the encrypted
sender is)

In this way, once a conversation has been established, replies
can keep going backwards and forwards without much fancy protocol
at all - all you ever do is remember not to delete the encrypted
block that the remailer keeps inserting at the top of your mail.

And with this scheme, the remailer does not need to remember the
addresses of either the initial poster or the recipient, and
hence can't divulge them if the machine is hacked.  So it gives
you a combination of the penet-style mailer with return address,
and the cypherpunk-style mailer of throw-away anonymity -- as
long as you trust the remailer operator not to cheat and log
stuff anyway.  Of course, you then extend the scheme by the
same mechanisms that the cpunk remailers already use - chaining
from one remailer to the next... if done properly, the return
addresses should chain too, transparently, and the whole scheme
will remain easy to use.

Clearly this scheme is succeptible to mass logging of comms links
followed by a bust to grab the remailer's secret key, but that's
about par for the current remailers anyway.  This scheme is no
worse, and possibly quite a bit better.

So, have I just stated the obvious or is this a new idea to anyone?

Regards

G
PS Note this scheme doesn't need Matthew's hack for "+" in
usernames, which not everyone wanting to run a remailer in
say a private account on netcom etc would be able to install...
PPS I thought for fun I'd put a header of the kind I'm
talking about on this mail.  Anyone replying should note
it really *will* go to me, and you *won't* be anonymized ;-)