Metadata anonymization through time delayed email messaging.
We know that with or without data content analysis of actual email messages, lots of information can be inferred through various forms of metadata collection. Given this reality the question becomes, what can be done? 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. If a program could be coded in a way which could delay the actual transmission of data in such a manner that the original time of creation was adequately masked, it could hamper nefarious metadata collection of time-stamping and possibly geo-locating of user information. For example: A person walks into a computer café at 10am and sets an email to send at around 4am the following morning (via cloud or machine). The data gets sent at 4am when the building is empty. No CCTV photos/cameras are able to document who sent the message because the computer café is unoccupied at 4am. The software is designed in such a fashion that it is nearly impossible to unmask the original time when the message was instructed to send, thus hiding the metadata associated with time-stamping, and thus hiding the true identity of the computer user at the café at 10am the previous day. Any and all feed back regarding this idea is welcome.
Great idea, however I think the user should still have the possibility to choose a timely delivery if the context requires it, right? I have always had questions about obfuscating e-mail metadata too. For instance, would it be possible to implement "burner" accounts (like ChatSecure [1] did)? The concept of a burner account is that you can quickly create a new
clean account with no identifying or memorable details, and have that account only exist on your device [...]
That way people would be "shuffling" their e-mail accounts and that would make it harder to infer social links via email metadata. This may be a very stupid question, but hey, I'm curious. [1] http://chrisballinger.info/apps/chatsecure/ On Tue, Aug 27, 2013 at 12:22 PM, Jeff Scofield <jscofiel@gmail.com> wrote:
We know that with or without data content analysis of actual email messages, lots of information can be inferred through various forms of metadata collection. Given this reality the question becomes, what can be done?
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.
If a program could be coded in a way which could delay the actual transmission of data in such a manner that the original time of creation was adequately masked, it could hamper nefarious metadata collection of time-stamping and possibly geo-locating of user information.
For example:
A person walks into a computer café at 10am and sets an email to send at around 4am the following morning (via cloud or machine). The data gets sent at 4am when the building is empty. No CCTV photos/cameras are able to document who sent the message because the computer café is unoccupied at 4am. The software is designed in such a fashion that it is nearly impossible to unmask the original time when the message was instructed to send, thus hiding the metadata associated with time-stamping, and thus hiding the true identity of the computer user at the café at 10am the previous day.
Any and all feed back regarding this idea is welcome.
-- Tuan Nghia DUONG Élève-ingénieur en Informatique et Réseaux ESISAR, Valence
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?
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 <danimoth@cryptolab.net> 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?
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 <jscofiel@gmail.com> 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 <danimoth@cryptolab.net> 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?
Lance's message size is quite interesting for its parallel to size of files used for stego and other hiding means. For example a large CAD drawing of nuclear warhead can be graphically shrunk to the size of a period and that period placed at the end of note or under a line in a drawing of a Michael Graves teapot. The giveaway is the file size. Fragmenting the warhead drawing for placement in many banal drawings would help, and that is being done with a variety of cloaking tools. To hide the file and its size, the compressed CAD drawing or CAD-reduced encrypted volume on easy cracking of AES or burgling AEC labs, like the old microdot, can be transmitted in barrel of oil, a bottle of perfume, a condom of cocaine or false fingernail. 3D printing of a compressed CAD files has possibilities. As do compressed audio files embedded in DVD labels.
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.
danimoth <danimoth@cryptolab.net> writes:
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?
Thank you danimoth for making that connection. [Will they never learn?] -- -- StealthMonger <StealthMonger@nym.mixmin.net> Long, random latency is part of the price of Internet anonymity. anonget: Is this anonymous browsing, or what? http://groups.google.ws/group/alt.privacy.anon-server/msg/073f34abb668df33?dmode=source&output=gplain stealthmail: Hide whether you're doing email, or when, or with whom. mailto:stealthsuite@nym.mixmin.net?subject=send%20index.html Key: mailto:stealthsuite@nym.mixmin.net?subject=send%20stealthmonger-key
Jeff Scofield <jscofiel@gmail.com> wrote:
A person walks into a computer café at 10am and sets an email to send at around 4am the following morning (via cloud or machine). The data gets sent at 4am when the building is empty. ...
Any and all feed back regarding this idea is welcome.
if you control the end-user sending machine & it runs some sort of Unix, this is trivial; the required command is just: at 04:00 mail whoever@example.net < message_file Writing a script to do this using a random time would not be hard. Of course this does not encrypt the file, though it could send a file that was already encrypted. Nor does it provide any sort of protection against someone who can snoop on the sending machine (nothing I know of does!), so it does not work in your Internet cafe example. Better to modify the mail server to introduce a random delay. This also does not look hard. Avoiding time stamps in the Received: lines in the headers would also be necessary, but that looks straightforward as well. To block tracking, you also want to avoid putting the client machine's IP address in the headers. Easily done, but it makes it harder to deal with spammers.
participants (8)
-
danimoth -
Jeff Scofield -
John Young -
Lance Cottrell -
Nghia Duong -
Sandy Harris -
StealthMonger -
Tom Ritter