1994-07-29 - Re: Remailer ideas (Was: Re: Latency vs. Reordering)

Header Data

From: Hal <hfinney@shell.portal.com>
To: cypherpunks@toad.com
Message Hash: 27f5615101334e1d958101f62f3f3b35db9c809072161e87d3ab11a372ff3f0b
Message ID: <199407290350.UAA09763@jobe.shell.portal.com>
Reply To: <9407281831.AB19187@ralph.sybgate.sybase.com>
UTC Datetime: 1994-07-29 03:50:33 UTC
Raw Date: Thu, 28 Jul 94 20:50:33 PDT

Raw message

From: Hal <hfinney@shell.portal.com>
Date: Thu, 28 Jul 94 20:50:33 PDT
To: cypherpunks@toad.com
Subject: Re: Remailer ideas (Was: Re: Latency vs. Reordering)
In-Reply-To: <9407281831.AB19187@ralph.sybgate.sybase.com>
Message-ID: <199407290350.UAA09763@jobe.shell.portal.com>
MIME-Version: 1.0
Content-Type: text/plain


jamiel@sybase.com (Jamie Lawrence) writes:

>I was thinking some about remailers and means to create more
>effective ones. I think the idea of padding messages has been
>kicked around (has anyone implemented it?), but what about random
>compression? Some messages are compressed, others are padded, some
>are left alone, perhaps shooting for a median message size
>(everything coming from this mailer tries to be 9k, or as close as
>possible). Of course, this requires a standard so that other
>remailers downstream can make the message readable.

The real problem to be solved is this: given a set of input messages,
and a set of output messages which represent decryptions of the input
ones (along with perhaps a bit of extra processing), make it impossible
to tell which output messages go with which input ones.  Clearly, if the
messages are of widely disparate sizes, and output messages are similar
size to input messages, that won't do.  That is where the idea of padding,
and of standardized messages sizes, comes from.

Hal





Thread