On 11 June 2013 13:42, Sean Cassidy <sean.a.cass...@gmail.com> wrote:
> On Tue, Jun 11, 2013 at 10:10 AM, Griffin Boyce <griffinbo...@gmail.com> 
> wrote:
>> It would be a fairly simple task to review all of the chat information and
>> correlate "call and response" for all of the conversations.
> I disagree for several reasons.
> First is that if the load on the network is high enough, conversations
> can hide in the noise. This is helped by dummy message generation
> either by clients or servers (preferably clients to protect against
> attackers that can monitor every node).
> Second is that this protocol is not necessarily one-to-one. It
> naturally supports one-to-many, many-to-one, and many-to-many
> messages. As these are not distinguished at the message layer, but
> rather at the application layer, it would take some more sophisticated
> analysis to determine the nature of the conversation.
> Third is that prefix selection logic is entirely up to the client.
> They can choose prefixes that vary with an encrypted pattern, or some
> variant of that idea, to obfuscate where they are sending their
> messages.

I haven't looked at your project much (sorry, I've added it to my list
though ;) )  - but Griffin is right to be paranoid first.  Depending
on the metadata available*, it is often possible to correlate messages
with some good amount of probability, even when it seems like a flood
of random messages.

I like the idea of shared inboxes, for all their faults, and will be
talking about faults and these types of correlation attacks at Defcon
this summer, targeting perhaps the largest shared inbox-based
anonymity project deployed:


*It's amusing that the focus of this (and my) analysis completely
discards looking at actual content, and focuses entirely on metadata.
Metadata, Metadata, Metadata. ;)
Too many emails? Unsubscribe, change to digest, or change password by emailing 
moderator at compa...@stanford.edu or changing your settings at 

Reply via email to