On Jan 5, Hal commented on my suggestions for ARA using a Miron Cuperman remailer. > I'd also like to suggest that the message- body to > be encrypted require heading and trailing > delimiters such as: > > -----BEGIN MESSAGE BODY----- > -----END MESSAGE BODY----- > > Note delimiters would not be part of message body > and would not be encrypted. These anonymous addresses do need a distinction between the "message address" (or "envelope") and the message body. The anonymous address gets decrypted at each step, and the message body gets encrypted at each step using the scheme above. But Eric Hughes pointed out that we already have such a distinction in the RFC822 message headers vs body. We should use that existing structure rather than try to create our own. That means that anonymous addresses should be designed to fit into mail headers. Unfortunately many mail agents make this difficult or inconvenient right now, but perhaps that is an area where we could make some improvements. In this model, we would not need message body delimiters, since mail already has its message body delimited distinct from its headers. I think "many mail agents" at least the one at this location, make it downright impossible to put an ARA into the header. Especially a chained ARA, which is part address and part body (to all except the last remailer in the chain). I think we are better off writing tools which will work now on the worst common denominator of mailers, rather than insisting that the world change so our solutions can be more elegant. Note that the user of an ARA is likely to be less computer & e-mail literate than the person he is responding to. It's easy to specify, to reply, mail to the [first remailer address]. Put this encrypted ARA block first in your message body, followed by your reply message enclosed in -----BEGIN MESSAGE BODY----- -----END MESSAGE BODY----- Only the text between these two delimiter lines will be received by the original sender, so your anonymity will be protected too. Note that this elegantly takes care of discarding the automatic sig of the responder, if any. Some here, like Richard Childers, don't want to protect users who might not understand that they need to suppress their automatic sig to maintain their anonymity with a remailer. People who run remailers have to be pretty gutsy anyway. They may get sued by disgruntled recipients of abusive or threatening anon msgs. It seems to me they don't also need to risk being sued by disgruntled message senders (or responders) who are embarassed (or worse) by inadvertantly revealing their identity in what they intended as an anonymous message. Note that your average civil jury is not going to be terribly computer-literate. Even a suit which loses is going to cost a lot to defend against. As to Hal's other suggestion: If we do process the message body with encryption at each stage, I do have an idea which could be useful. If the body which is being encrypted is already in the format of an ASCII-encoded message using the standard RFC822 encryption used in PGP, RIPEM and PEM, then rather than just encrypting it it could be de-ASCII'd, then encrypted, then re-ASCII'd. This would keep it from increasing in size by a factor of 4/3 at each encryption step. Sound's like a good idea, but it's not going to save anywhere near 1/3 (4/3 - 1), at least with PGP, since (recall) PGP (at least by default) compresses before it encrypts. -- edgar@spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca
participants (1)
-
edgar@spectrx.Saigon.COM