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

Re: New anon mailer idea?



Hal writes:
>  - You'd want this feature to be optional.  Some people might not want
>    their anonymity limited by having their return address recorded, even
>    in encrypted form.

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.
The encryption definitely needs some sort of random padding,
though CBC with a random IV plus length-padding at the end
should probably suffice.

>  - The use of a symmetric cypher is a very nice way of getting the use-once
>    capability, along with the "burn after reading" effect of a remailer
>    chain which destroys itself as it goes.  But it could be a considerable
>    burden on the remailer operator to maintain the database.  One possibility
>    would be to fix a maximum time limit on how long the return addresses are
>    kept "alive" and require some real money to keep them longer.

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).
You could also implement time-limits by including an expiration date.

Perhaps something S-Key like might be applicable, if you want to stick
to private-key methods?

>  - 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 [email protected] syntax does this fine.
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.

		Bill