Metadata anonymization through time delayed email messaging.

[Tom Ritter]

On 27 August 2013 12:15, Lance Cottrell <loki at obscura.com> wrote:
> This is a really subtle issue. Much has been written about how to optimize
> mixing pools.
> 6-12 hours is a really long delay for many purposes. If not everyone is
> doing so, long delay messages might turn out to be of particular interest.
>
> It also seems like a bad idea to put the message holding function at the
> sender's end. That makes it easier to try to identify who might have been
> storing messages for later delivery.

I don't know - if I'm performing physical or network surveillance of a
target, and I see a Mix message leave - that tells me something very
definite about the timing.  Obviously you wouldn't want to store the
message in plaintext, but if you encrypted it to the first hop, along
with the address, and a time to send (and tried your hardest to lie
about the timestamps on the filesystem); you can increase the
difficulty of learning something definite.  And I think that holds
even if the attacker does a physical intrusion and looks at the
filesystem. (It reminds me Rivest's FlipIp game - the attacker is
allowed to do a physical intrusion and read the filesystem, but
everyone learns that they have and thus distrusts that node.)  Of
course it only holds if there are multiple possible senders, delaying
an email from my home when I live alone doesn't help me.  But if there
are multiple possible senders, it feels like tacking on a
lesser-quality mix node at the beginning.

Another argument to it's utility is there is no easy way to disguise
the fact that you are sending a mix message.  Right now the only ways
I can think of hiding that fact would be to use mix bridges (some
entry remailer node that isn't published, akin to Tor's bridges) with
a protocol that looks as identical to SSL in a webbrowser as you can;
or to send them out over Tor.

> This might be a very simple and interesting service to provide at the end of
> remailer chains. Exit remailers might have an additional command which would
> instruct them to hold the message for a given period or until a given time
> before final delivery.

I think the user-configurable time is the idea behind Alpha Mixing,
although I hope it's implemented better than in Type 1 Remailers.

> With Mixmaster I spent a lot of time thinking about message size. If you can
> recognize a message from its size as it enters and leaves a node, then all
> the delay and mixing is effectively thwarted.

Absolutely.  And on the sender end, I can't think of good ways to
obfuscate large messages.  The splitting technique of Mixmaster has
always felt like a bit of a hack (no offense), because someone doing
end to end correlation should be able to link those fairly easily.
For receiving large files, I think a client/server architecture where
you can choose to delete the message on the server, or download chunk
by laborious chunk over time would be advantageous[0].

-tom

[0] This might, might, even be an argument of added complexity by
splitting files, before compressing and encrypting them, so you can
download chunks 1-4 and (potentially) get a portion of the file in a
readable albeit incomplete format.