Vuvuzela - anonymous messaging that scales to millions of users

Nov 11 11:56 [raw]

Vuvuzela - anonymous messaging that scales to millions of users Metadata absolutely tells you everything about somebody's life — Stewart Baker, former General Counsel of the NSA We kill people based on metadata — Michael Hayden, former Director of the NSA Vuvuzela Vuvuzela is a messaging system that protects the privacy of message contents and message metadata. Users communicating through Vuvuzela do not reveal who they are talking to, even in the presence of powerful nation-state adversaries. Our SOSP 2015 paper explains the system, its threat model, performance, limitations, and more. Our SOSP 2015 slides give a more graphical overview of the system. Vuvuzela is the first system that provides strong metadata privacy while scaling to millions of users. Previous systems that hide metadata using Tor (such as Pond) are prone to traffic analysis attacks. Systems that encrypt metadata using techniques like DC-nets and PIR don't scale beyond thousands of users. Vuvuzela uses efficient cryptography (NaCl) to hide as much metadata as possible and adds noise to metadata that can't be encrypted efficiently. This approach provides less privacy than encrypting all of the metadata, but it enables Vuvuzela to support millions of users. Nonetheless, Vuvuzela adds enough noise to thwart adversaries like the NSA and guarantees differential privacy for users' metadata.

Nov 11 14:21 [raw]

Install the Vuvuzela client The instructions are hard. Granny Smith doesn't know how to do it.

Nov 11 14:21 [raw]

Register your email address using the form on the right. Are you sure you wouldn't like to know what color underwear I'm wearing as well?

Nov 12 01:39 [raw]

> Are you sure you wouldn't like to know what color underwear I'm wearing as well? do tell

Nov 12 01:41 [raw]

> We kill people based on metadata — Michael Hayden, former Director of the NSA gee, that's comforting

Nov 12 16:07 [raw]

They are white, with a yellow stain at the front, and a brown stain at the back.

Nov 17 14:28 [raw]

> Register your email address ... even worse: Username registration is temporarily unavailable. looks like NSA has occupied vuvuzela's single point of failure: vuvuzela's name service aka alpenhorn. too bad, they didnt 'simply' extend XMPP or ricochet looks like NSA will only tolerate 'weak anon networks' that allow for traffic analysis ... cos 'proof by metadata' is enough to kill targets. quote from Metadata absolutely tells you everything about somebody's life — Stewart Baker, former General Counsel of the NSA We kill people based on metadata — Michael Hayden, former Director of the NSA quote from 2 Related work A common way to bootstrap private messaging is to as- sume that users have exchanged keys or secrets out-of-band. For example, the Ricochet [13] private messaging system requires a user to know the other person’s Ricochet ID (a public key) to start a conversation. The Pond [29] private messaging system uses a protocol called PANDA [2] to establish relationships between users that have previously shared a secret. In contrast, Alpenhorn allows two users to start a conversation without know- ing each other’s public keys or having a shared secret. Alpenhorn can be used to bootstrap PANDA (see §8.5). Both Ricochet and Pond use Tor’s hidden services [20]. Alpenhorn’s privacy guarantees are stronger than those of Tor’s hidden services in two ways. First, hidden services do not protect against traffic analysis. This is because Tor has many ways for an adversary to infer information based on traffic patterns. Alpenhorn uses techniques from Vuvuzela [42] to defeat traffic analysis (achieving differential privacy). Second, hidden services have a weaker adversary model for protecting metadata: e.g., an adver- sary that compromises the rendezvous point of a hidden service learns when that user is receiving calls. In contrast, Alpenhorn provides metadata privacy under an anytrust assumption (any N-1 out of N servers can be compromised).

Nov 17 17:53 [raw]

> looks like NSA will only tolerate 'weak anon networks' In case you haven't noticed, NSA doesn't make the rules. NSA doesn't even enforce the rules. NSA spies and that's it. It is your big companies that are making the Internet insecure. Google, the certificate authorities, the cryptography gatekeepers of academia with their fear porn and refusal to allow discussion of new kinds of crypto. NSA is flattered that you think so highly of them.

Nov 17 19:05 [raw]

Traffic analysis may be useful in every IM. If someone send huge text in BM then every ISP, every police know who use BM and who send this huge text. If you want to be more anonymous you should create second layer in BM and use only small messages. Watch your sniffer and tor packets with size: 1514 (1500) and 597 (583)

Nov 17 20:03 [raw]

And it doesn't help that you can count the number of BM users on the fingers of one hand!

Nov 18 12:32 [raw]

False. In good anonimity system three people can chat anonymously.

Nov 18 12:38 [raw]

Has it been proven that BM is securely anonymous?

Nov 18 12:42 [raw]

No. If you send small message in BM then your traffic will be the same like tor in rest.

Nov 18 13:35 [raw]

I have told the BM devs that all messages must be broken up into uniform, standard packet size, and each packet sent as an individual message, to be re-constructed by recipient. The odd packet should be padded to bring it up to standard size. BM protocol as it is should be scrapped. It is not anonymous and the only security feature that works is using tor, which is also suspect since law enforcement routinely unmasks tor users. Now I don't care about law enforcement busting pedophiles and drug dealers. More power to them. Hang 'em all, let God sort 'em out. The problem is if law enforcement is unmasking criminals on tor, then nation-state agencies with much larger budgets are likely unmasking political and religious dissidents. When we see the personal character of some prominent tor developers that also makes me shudder. They have the hallmarks of CIA cutouts: moral profligacy, pointless contentions, and lots of ngo and government dollars propping them up. Most ngos are front groups for organs of state. Ergo if one is getting ngo funding, beware. I could personally create a protocol to do this with guarantees that it would not be susceptible to traffic analysis. But who would pay me? I have to pay bills and I can't go to work and code free software for freeloaders at the same time. Nobody is willing to pay for a quality product, then they whine about substandard, buggy, free software.

Nov 18 13:46 [raw]

I am counting them on the knuckles of my middle finger. See?

Nov 18 13:50 [raw]

This does not increase anonymity. If all message packets are not exactly the same size to the bit then traffic analysis is possible.

Nov 18 13:50 [raw]

Quite the opposite at this stage. If you use secret addresses and secret chans, and a symmetric cipher with PGP signing to pre-encrypt your messages, then your communication is secure, but not necessarily anonymous. Step 1. Compose your message in a text editor. Step 2. Encrypt it with a secret passphrase known only to you and recipient. Step 3. Sign it with PGP key. Step 4. Cut and paste ciphertext into bitmessage and send. This can be done over a secret chan, or between private addresses. Recipient decrypts and verifies signature.

Nov 18 13:50 [raw]

Which nerd idol told you this? If there are only 3 users you only have 3 suspects. I know most cops aren't geniuses, but one need not be a genius to shake down 3 potential perps.

Nov 18 14:57 [raw]

> I could personally create a protocol to do this with guarantees that it would not be susceptible to traffic analysis. why not fork vuvuzela? also mixminion concepts could be useful its all there, but its all 'not popular' aka sabotaged aka not public > BM devs ... tor developers ... CIA ... unmasking political and religious dissidents the consensus seems to be: crypt and obfuscate as much as you want, as long as you make your system weak enough for timing attacks aka traffic correlation attacks, aka we kill targets based only on metadata writing code against that standard makes you a dissident > If there are only 3 users you only have 3 suspects. I know most cops aren't geniuses, but one need not be a genius to shake down 3 potential perps. yes ... hiding in a 'crowd' of three people is not anon. just consider, how many 'civilians' are sacrificed in war even if 'they' must kill 1000 people, to kill one target, this is still better than risking one alive target remember, criminals dont follow laws. agents are merely white criminals. > In good anonimity system three people can chat anonymously. sounds like the dining cryptographers problem Dining cryptographers problem From Wikipedia, the free encyclopedia In cryptography, the dining cryptographers problem studies how to perform a secure multi-party computation of the boolean-OR function. David Chaum first proposed this problem in the early 1980s and used it as an illustrative example to show that it was possible to send anonymous messages with unconditional sender and recipient untraceability. Anonymous communication networks based on this problem are often referred to as DC-nets (where DC stands for "dining cryptographers"). Description Three cryptographers gather around a table for dinner. The waiter informs them that the meal has been paid for by someone, who could be one of the cryptographers or the National Security Agency (NSA). The cryptographers respect each other's right to make an anonymous payment, but want to find out whether the NSA paid. So they decide to execute a two-stage protocol. In the first stage, every two cryptographers establish a shared one-bit secret, say by tossing a coin behind a menu so that only two cryptographers see the outcome in turn for each two cryptographers. ... In the second stage, each cryptographer publicly announces a bit, which is: if they didn't pay for the meal, the exclusive OR (XOR) of the two shared bits they hold with their two neighbours, if they did pay for the meal, the opposite of that XOR. ... The three public announcements combined reveal the answer to their question. One simply computes the XOR of the three bits announced. If the result is 0, it implies that none of the cryptographers paid (so the NSA must have paid the bill). Otherwise, one of the cryptographers paid, but their identity remains unknown to the other cryptographers. David Chaum coined the term dining cryptographers network, or DC-net, for this protocol. see also: compartmentalization, need to know Compartmentalization (information security) From Wikipedia, the free encyclopedia Compartmentalization, in information security, whether public or private, is the limiting of access to information to persons or other entities on a need-to-know basis to perform certain tasks. It originated in the handling of classified information in military and intelligence applications. It dates back to antiquity, and was successfully used to keep the secret of Greek fire.[1] The basis for compartmentalization is the idea that, if fewer people know the details of a mission or task, the risk or likelihood that such information will be compromised or fall into the hands of the opposition is decreased. Hence, varying levels of clearance within organizations exist. Yet, even if someone has the highest clearance, certain "compartmentalized" information, identified by codewords referring to particular types of secret information, may still be restricted to certain operators, even with a lower overall security clearance. Information marked this way is said to be codeword–classified. One famous example of this was the Ultra secret, where documents were marked "Top Secret Ultra": "Top Secret" marked its security level, and the "Ultra" keyword further restricted its readership to only those cleared to read "Ultra" documents.[2] Compartmentalization is now also used in commercial security engineering as a technique to protect information such as medical records. Example An example of compartmentalization was the Manhattan Project. Personnel at Oak Ridge constructed and operated centrifuges to isolate uranium-235 from naturally occurring uranium, but most did not know exactly what they were doing. Those that knew did not know why they were doing it. Parts of the weapon were separately designed by teams who did not know how the parts interacted. See also Information sensitivity Principle of least privilege Read into Sensitive Compartmented Information

Nov 18 22:20 [raw]

> why not fork vuvuzela? MIT is deep state agency

Nov 19 00:43 [raw]

> MIT is deep state agency thats too simple sounds like you are too lazy to analyze and improve if not, lets spend some hours on reading 'another master' via quote ... David Lazar I'm a PhD student in the PDOS group at MIT CSAIL, advised by Nickolai Zeldovich and Frans Kaashoek. My research focuses on security and privacy in distributed systems. Previously, I worked with the FSL group on formal semantics of programming languages at UIUC. Publications Karaoke: Distributed Private Messaging Immune to Passive Traffic Analysis (OSDI 2018) What's a little leakage between friends? (WPES 2018, to appear) Alpenhorn: Bootstrapping Secure Communication Without Leaking Metadata (OSDI 2016) Riffle: Efficient Communication System with Strong Anonymity (PETS 2016) Vuvuzela: Scalable Private Messaging Resistant to Traffic Analysis (SOSP 2015) Circuit Fingerprinting Attacks: Passive Deanonymization of Tor Hidden Services (USENIX Security 2015) Mjölnir: The Magical Web Application Hammer (APSys 2015) Jitk: A Trustworthy In-Kernel Interpreter Infrastructure (OSDI 2014) Why does cryptographic software fail? A case study and open problems (APSys 2014) Executing Formal Semantics with the K Tool (FM 2012) at first sight, the weakspot of vuvuzela seems to be the pre-sharing of secrets as in, exchanging public keys, or user names without some form of central authority --> alpenhorn bitmessage solves this part with public channels where at least one party must publish its pubkey in vuvuzela, the 'dead drop ID' is hashed from alice x bob x round-number where alice x bob is the 'channel ID' and round-number is a constantly-changing random seed broadcasted by the 'entry server' to all parties also, there seems no way to enforce 'at least one honest relay' sure, you can 'run your own relay', but how can you tell it is not compromised too? recursive mindfuck process ongoing ... almost seems like scalability and privacy are mutually exclusive ... almost : P

Nov 19 10:01 [raw]

Probably you have never seen tor traffic in sniffer.

Nov 19 11:09 [raw]

But who would not be more anonymous and who send this is unmasking criminals on the other person's packets with size, and lots of ngo and who would not be re constructed padded susceptible to defeat do not be more anonymous useful in contrast, Alpenhorn can's hidden services have a protocol to do not be scrapped: more anonymous and the same time; political and Register your sniffer and Register your sniffer and religious dissidents; Michael Hayden, former General Counsel of the personal character of CIA cutouts: if one is getting ngo and code free software for freeloaders at the only security feature that also suspect since law enforcement routinely unmasks tor developers that all, messages must be more anonymous and each I have a public keys or Ricochet and Tor, which is unmasking criminals on tor code free software for organs of tor, then they have exchanged keys a protocol to know ing each packet size.

Nov 19 11:31 [raw]

If all packets are not the same size, and randomized in time and order, then traffic analysis can be done. A mix net, fluff net etc. is no good if messages vary in size. Bitmessage does not hide the most useful metadata. And the TTL system is extra metadata that spooks gobble up and analyze. The message size is the most useful metadata. "We kill people based on metadata." {former NSA chief}

Nov 19 11:56 [raw]

I wrote that we should use small packets in BM. After that BM traffic will be the same like in tor in rest. We need IM or something similar (maybe second layer in BM) with packets with the same size, the same delays, the same connection speed.

[chan] bitmessage

Subject Last Count
Is Bitmessage censored? Dec 12 12:01 34
Bug Report Dec 12 07:10 1
Bitmessage Noisebot Updated Dec 11 14:01 13
Bitmessage noisebot sends randomly-timed noise messages via the PyBitmessage API. Dec 11 11:40 15
Abandoning Bitmessage Chans Dec 10 12:05 19
test help Dec 10 10:20 3
chanerator v0.0.1 Dec 9 10:41 1
OMEMO jabber/XMPP chat using Gajim IM Dec 9 09:05 4
OMEMO only 1000 people use XMPP Dec 9 03:09 1
GB2RS News - Sunday 9th December 2018 Dec 9 00:02 1
censorship Dec 8 17:30 2
Be warned! GOD is watching YOU (even on BM) Dec 6 11:16 2
UK Column News - 4th December 2018 Dec 5 22:41 1
UK Column News - 3rd December 2018 Dec 5 22:31 2
Tips for securing Bitmessage Dec 3 08:24 1
Hello Dec 3 08:07 1
What does Bitmessage really have to offer? Dec 3 06:09 15
UK Column News - 05 Decmber 2018 Dec 2 03:16 1
UK Column News - 04 December 2018 Dec 2 03:12 1
UK Column News - 02 December 2018 Dec 2 03:07 1
Bitmessage Network Health Report Dec 2 01:03 12
jo Dec 1 00:18 4
bug? send != receive Nov 30 12:52 1
Quick and Easy Chicken Madras Nov 23 16:42 1
BM Nov 23 16:21 7
It's 'Anything can happen' Friday! Nov 23 16:10 1
need an editor ? Nov 21 13:33 10
gibs ne Chance, Namecoin mit pyBM ans Laufen zu kriegen ? Nov 21 13:00 1
Vuvuzela - anonymous messaging that scales to millions of users Nov 19 11:56 19
How do I benchmark bitmessage PoW Nov 15 22:13 3
Support request -- GPUs (Intel(R) HD Graphics IvyBridge M GT1) did not calculate correctly Nov 15 17:04 2
Spam... Nov 15 17:02 4