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. 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. 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. -Lance -- Lance Cottrell loki@obscura.com On Aug 27, 2013, at 7:05 AM, Jeff Scofield wrote:

Possibly, I will defer to the more technically learnt.

I'm not a nym server expert but from my laymen perspective the Pynchon Gate design looks good. It might be totally redundant and unnecessary but if metadata analysis is the concern, wouldn't such a setup be even more secure by coding something so that the time between sending a message and receiving a reply which in theory could leak information about the nym holder, be sent at a random date in a given time-frame (unbeknownst to the metadata leeches) . i.e. In 6-12 hours from the moment I click "send" or say in 12-20 days etc.

The email message could be coded to send at random like an online roulette table ball, within a given time window: verses say reloading every 24hours. This would in theory give out incorrect message 'sent' time-stamps, or would this be unnecessary because traffic from the user to the email distributors is already being controlled by the user, which queries into intervals anyway? Is that not metadata that can be tracked?

- J

On Wed, Aug 28, 2013 at 12:22 AM, danimoth wrote: On 27/08/13 at 10:22pm, Jeff Scofield wrote: [cut]

...

One strategy might be to consider the adoption of a time delayed email system. The reason why the use of such a mechanism to allow someone the ability to write an email, and then have it sent off at a specified (or randomly generated unspecified) date is useful for multiple reasons. [cut]

Are we trying to reinvent anonymous remailers and nym servers?

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