4 ms·
Ultimately we need something that is a cross between Skype's old decentralized architecture and alt.anonymous.messages. We can now stream videos of a few gigab
by malandrew 13y ago
Ultimately we need something that is a cross between Skype's old decentralized architecture and alt.anonymous.messages.
We can now stream videos of a few gigabytes with a large enough swarm. That should be enough to create large shared mailboxen among several hundred random people that lasts about a month at a time, at the end of which your mail program would automatically mail all the people in your address book at their anonymous addresses informing them of the next large anonymous mailbox you'll be using with other people.
Everyday, your mailclient would download the entirety of all new encrypted messages for your peer group and would parse out your messages using your private key.
Let's say that every shared mailbox is capped at 10GB of total shared mailbox space. Every peer in the swarm using that mailbox replicates that mailbox. Once that mailbox hits 9GB of total messages, your client attaches to a new 10GB mailbox being created with a random set of N strangers. It then takes the address of that new mailbox and mails all your contacts a special kind of "update your address book" message with a new mailbox address and a new private key. Upon receiving that message, their client now knows to send any messages addressed to you to the new mailbox and use a new private key.
This approach makes it nearly impossible to perform social network analysis because your address essentially betweens a cross between that shared box and your private key that only you have.
There has been work done de-anonymizing alt.anonymous.messages [0], but a lot of the attacks all relied on the small number of participants on alt.anonymous.messages using that same shared mailbox over many many years. At scale with many more participants and automatic mailbox rotation, these types of attacks become far more difficult.
[0] http://ritter.vg/blog-deanonymizing_amm.html http://ritter.vg/blog-deanonymizing_amm.html
- hershel 13y agoWon't mailbox rotation enables attacking it by comparing users in different mailboxes - the users who stayed over some time in shared mailboxes , probably want to communicate with each other ? And few hundreds is a pretty small group if you want anonymity. And according to the presentation in the link you gave(very interesting work on the subject of anonymity) - if messages are posted correctly, using the right tools(mix networks, nymservers) and those tools are developed to high enough quality(which is not the case today) , and enough people are using the service , the anonymity achieved can be very high using standard mailboxes.
- deleted 13y ago[deleted]
- malandrew 13y agoI would imagine that any shared mailboxes should be capped to force mailbox rotation at the exact same time. Once a mailbox hits a predetermined limit, all the peers refuse to accept additional messages. Basically the exodus of users from a mailbox should happen all at the same time. Those users then randomly choose any of the other new mailboxen out there being formed. You would never be with the same cohort from one mailbox to the next. A few hundred randomly allocated and rotated monthly should help. I need to go back through that presentation again. Anyone thinking about anonymity should read it. It's brilliant. The other thing we need is a way to easily handle multiple keys so that if one key is comprimised then we only get up a small amount of data. Ideally we would want one key per contact, but this of course would be prohibitively expensive computationally because I'd have to compare every message in that 10GB against every key I have per person. However being able to have maybe a half dozen public keys randomly distributed among your contact list would help. A totalitarian government forcing key disclosure with the threat of jail time would have to have all your public keys to determine whether or not you have disclosed all the information you have received. This would do the same for shared mailboxes as Truecrypt did for deniability that additional partitions exist. You can even distribute your keys among the different bootable Truecrypt volumes you have. At the end of the day, public key disclosure shouldn't be a lookup but a give a key, get a key system. Basically, I would submit a new public key to you via some secure web interface which would deliver a one time message to you at the shared mailbox you're using. At some later date, you generate a new public key for communicating with me (or use one of your current keys in rotation) and send me a message that contains the address of the mailbox I'm currently using and that key which I should use until I revoke it or issue a new one. Ultimately we need a system that disguises how many people we are communicating with, partitions those people with multiple keys, that affords me plausible deniability since an attacker wouldn't know how many keys or mailboxes I'm using and where the level of security I am afforded is only bounded by the disk space, bandwidth and CPU time I'm willing to throw at the problem. This scales with paranoia. On top of that we need a system that provides us temporal security. If all my files and communications are partitioned cryptographically by date, I can aquiesce to a warrant that specifically details the dates in which they are interested instead of giving them everything I have. If they have a specific crime they are investigating (which they should have), then they should be able to state the specific date ranges that contain the evidence they are looking for. This prevents fishing for dirt.