BitTorrent Bleep, my analysis
Post date: Jul 31, 2014 1:54:20 PM
First of all, they start by lying: "Bleep offers the freedom to communicate without the risk of metadata being exposed." Yet they say it's using direct connection? - Massive fail.
First you should define, what metadata is and then tell where it doesn't leak it to. Ok, it doesn't leak it to "central server", but it does leak it to anyone monitoring the Internet connection.
AFAIK: if you form direct connetion between Alice and Bob, you're leaking metadata and clearly revealing connection as well as communication times, amount of communicated, called communication pattern. If that's not metadata leak, I don't know what is. RetroShare (Wikipedia) has quite similar network design and even bit better features earlier. But with same limitations, it doesn't hide communication patterns and doesn't stop metadata leak. Tox (Wikipedia) is an open source Skype replacement, with very similar design. DHT for distributed contact and network management and direct connections between peers. Yet, this doesn't make messanger secure, any more than using PGP with email.
Depending how the contact lookup DHT based lookup & locate system is designed, it might also leak and reveal contacts you're looking for indirectly.
"Journalists communicating with sources without exposing their identity or their content." - They're lying again. If you have direct connection between A & B, you're for sure leaking the information.
"Businesses keeping communications confidential, safe from leaks, and safe from industrial espionage". Define confidential and leak? Is it leak that Corp A is communicating actively with B? I would say it's a leak. So they're lying again.
Actually this was easy analysis to do, because I've been planning similar system for a long time. I just haven't had time to do it. This is because I didn't really like Bitmessage design. I would have replaced flood replicated message repository with DHT implementation. But then there's again question, how to stop the metadata leak. The best solution I can come up with is constant pseudo random communication pattern with DHT network. If done correctly using this method system can completely hide if you're communicating at all and with whom you're communicating, when and how much. That would be the perfect solution. With a few changes, system could be bit less secure, but more practical. In that case something similar to Tor Onion routing could be used. Or simply publishing to many DHT nodes using pseudo random pattern and the message recipient would then fetch the message using pseudo random pattern. But as far as I know, these methods will make the network susceptible to long term statistical traffic analysis.
Yet, as we remember, Tor doesn't try to protect you against that either.
Btw. RetroShare has offered similar networking features for a long time. It doesn't currently provide voice / video calls, but technically it's network is very similar. As well as it allows relaying messages (technical term) to untrusted peers via trust network. But as said, it doesn't even try to hide connection between A & B. Does it matter? I don't know. Is it bad if I call Osamas mom weekly and ask for traditional food recipes? Doesn't initially might sound so bad after all, but I'm quite sure it would make me a suspect in the intelligence domain.
More reading? Signals intelligence / Traffic analysis and Traffic analysis.