1993-01-09 - Delimiting text body in ARA

Header Data

From: edgar@spectrx.Saigon.COM (Edgar W. Swank)
To: Cypherpunks <cypherpunks@toad.com>
Message Hash: 9ee604c6ef3d0f4ecbc59848a36d252eb62fa609e584186a14b7a4e659cf01d1
Message ID: <P1T4wB8w165w@spectrx.saigon.com>
Reply To: N/A
UTC Datetime: 1993-01-09 23:00:34 UTC
Raw Date: Sat, 9 Jan 93 15:00:34 PST

Raw message

From: edgar@spectrx.Saigon.COM (Edgar W. Swank)
Date: Sat, 9 Jan 93 15:00:34 PST
To: Cypherpunks          <cypherpunks@toad.com>
Subject: Delimiting text body in ARA
Message-ID: <P1T4wB8w165w@spectrx.saigon.com>
MIME-Version: 1.0
Content-Type: text/plain


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






Thread