On 27 August 2013 12:15, Lance Cottrell <loki@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.