From: gtoal@an-teallach.com (Graham Toal)
Date: Fri, 15 Apr 94 07:38:18 PDT
To: cypherpunks@toad.com
Subject: Re: New anon mailer idea?
Message-ID: <199404151437.PAA27581@an-teallach.com>
MIME-Version: 1.0
Content-Type: text/plain


	From: "bill.stewart@pleasantonca.ncr.com +1-510-484-6204" <wcs@anchor.ho.att.com>

	The obvious implementation is to add a Generate-Return-Address: header 
	so you can use it if you want it, but won't get one otherwise.

Yep, that's one way that fits in with the cypherpunk remailer syntax;
another way would be to have a separate address that you used to explicitly
start a conversation, eg reply-remailer@somewhere.edu

Hmmm... you could in fact make the Generate-Return-Address: header take
the actual return address you want to use, like a Reply-To: header.  That
would be nice.  (I'd been assuming that it would use the normal reply
address - Reply-To:, From:, envelope address; in that order depending on
which was given)

	The encryption definitely needs some sort of random padding,
	though CBC with a random IV plus length-padding at the end
	should probably suffice.

Exactly my thoughts.  Or make it a stream cypher with random IV.

	Public key has the advantage that the operator doesn't *need* a database.
	If you want to implement use-once addresses (or use-N-times),
	you could include a tag with the address (such as the IV),
	and reject future messages using that tag (e.g. save a hash of the tag).

I think you missed the point - with your scheme it's still technically
possible to decrypt the address years afterwards - you're relying on the
remailer to always stay secure; with a delete-the-key scheme you couldn't
even if you were hung upsidedown from the ceiling from your toenails by the
gestapo.  (Though you might want to...) - so a corrupted remailer would
limit damage to only live keys that arrived after it was corrupted and not
its entirely history of dead ones from the period beforehand.

	>  - What we would really like is for the recipient to hit the "reply" button
	>    and be able to send his mail back.  

	Matt Ghio's remailer+62647629379278@wherever.com syntax does this fine.

The problem is 99% of mailers don't support that syntax, and although
it can be added by clever sendmail hacks, it can't be added unless you
have root access, and the philosophy of cypherpunk remailers/keyservers/etc
is that they run on random accounts with no special privileges.  Hence
why putting the address in the body is more portable.  Also random
remailer names are likely to draw less attention in your system's
outgoing-mail logs that addresses that are obvious remailers.

	If desired, you could implement anonymous bit-bucket addresses
	this way as well, though they're somewhat more useful if your remailer
	generates encrypted outgoing messages.  Alternatively, you can *always*
	generate either a real or a bit-bucket return address, and leave it up to
	the sender to inform the recipient that there's a probably-working return path.

I don't like the idea of replying and no knowing if it'll get there -
in fact, I meant to say earlier, if a reply is sent on a key that has
expired I'd expect the remailer to bounce an error report back saying
that the key had expired.

G