Comment by synctext | Hacker News Reader

Comment by synctext | Hacker News Reader

Parent Full thread

Please consider this a security review by a tenured P2P professor:

The whitepaper describes a simple and focused system relying on partitioning in an attempt to preserve scalability.

Bitmessage has many architectural similarities to Usenet and also offers no valid response to spam. Using a proof-of-work system to combat spam is proposed, but to-date science has not yet seen a working approach anywhere. Details are missing on this vital element plus defenses against the Sybil attack are missing from this design.

Mechanisms such as the "averageProofOfWorkNonceTrialsPerByte" in this system only slow down attacks and do not stop them. Check the impossibility proof by Harvard to see that systems like Bitmessage which react to any message cannot build an effective Sybil defense: http://dash.harvard.edu/handle/1/4907301 So this is known as a hard unsolved problem. Further diving into the scalability issue is this project thread on their forum: https://bitmessage.org/forum/index.php?PHPSESSID=8cl6qeafitk... It would be great if the partitioning concept and algorithms could be explained in detail. It's again a hard problem, even group size estimation in a hostile environment is already non-trivial. So how group consensus is formed to do a break-up is difficult and prone to attacks. This design is not incentive compatible. TOR has over 50% Bittorrent traffic, it's difficult to stop users from using(abusing?) TOR like that. Systems like Bittorrent and Bitcoin have some incentives, but Bitmessage with broadcasts and proof-of-work might even have a negative incentive for participation. I have seen no mechanism to prevent it's users broadcasting Blueray rips. This would bring down the system, one cluster at a time. Please check this work, it shows how to bring this type of P2P networks down: www.christian-rossow.de/publications/p2pwned-ieee2013.pdf‎

Publicity like "Bitmessage Sends Secure, Encrypted, P2P Instant Messages" might be nice. It creates a false sense of safety. If you want to protect against NSA snooping, you're up against a real army of crypto experts with decades of experience each.

Nice to see that this project has such an active Github community, 480 closed issues and 1159 commits. But, in my opinion it's back to the drawing boards... Sorry.

Disclaimer: working for 8 years on Tribler, a streaming Bittorrent client.

I appreciate the write up, it's why I popped into the thread.

That said, at least these folks are trying to protect against the NSA. What do you purpose we all do? Lay down and accept that they watch everything we do? Fuck that. Let's continue to build tools as a community. They may have a lot of people, but our community is bigger. So, fuck them.

People should continue to experiment, and try new things until we come up with various way to protect against the god damn NSA.

Indeed, we should not roll over and declare privacy an illusion.

A lot of people are experimenting with designs that will never work. It's just wasting programming resources, while projects like Tor starve for volunteers. My research team is currently merging Tor and Bittorrent (http://forum.tribler.org/viewtopic.php?f=2&t=5128&p=8585#p85...).

Clear designs (and lots of them) are more important then experimental code I believe.

Doesn't I2P fit better, considering the design requirements? Tor would require very significant changes to scale better for high volume traffic, but I2P already handles it reasonably well.

I wonder why I2P is getting so small amount of love. I've read somewhere that for some reason it's popular only in Russia. It has two working email systems, working Bittorrent and much more. Maybe it lacks a native (C or C++) implementation?

I2P is slow, it has no incentive system like T4T.

Try installing it, search for files and watch download speeds. Onion routing and tunnels cost bandwidth. The crowd that is used to Bittorrent speeds (in combo with VPN safety) is not interested in 2 Kbit/sec speeds. Plus the user interface is hard to understand without having attended crypto courses.

@synctext: you can't have traffic anonymity without routing. And I2P is mainly slow because the shared bandwidth is low.

Also, it isn't a hard as you claim. It is mainly a matter of setup.

My understanding of tribler is that it is going to use onion style routing and use some internal cryptocurrency to incentivize users to provide bandwidth. They hope that with proper incentives people will provide enough bandwidth to enable speeds that are high enough to stream high def video anonymously. They hope to prevent spam by enabling anonymous wiki editing of torrent channels and voting of torrent quality.

It hasn't been studied as extensively as Tor.

Which is why we need to get it studied more.

Sure, but that's still the reason it isn't as widely used. And because research resources in the anonymous-networking field are so limited the marginalization of I2P tends to be self-reinforcing.

Experimental code increased the understanding of these complex systems across a greater population of developers.

If we are going to come out on top, then we need to play the long game. In that case, experimental code has a lot of value.

Although I agree with your premise that clear designs are essential, I'd say that it's important nonetheless to implement them. Having an implementation is a marker of whether the design does/does not work. A whitepaper can theoretically show this, but an application is always (in my experience) more effective.

For example, when Satoshi first published the whitepaper for Bitcoin, there was talk on the crypto mailing list that it wouldn't scale due to its gossip-based protocol. Satoshi's design showed it did, and laid the foundations for future cryptocurrencies (Namecoin, Peercoin).

P.S. I've been following your work with Tribler, excellent stuff!

What do you think of Bote mail in I2P, which uses DHT for relaying mail? It is set to hold mail in the DHT for 100 days or until fetched by the recipient. It also uses public keys as addresses (ECDSA and NTRU are the options), and all mail is encrypted. I2P provides traffic anonymization, and Bote mail supports letting mails be relayed with random delays to further anonymize the sender by removing time correlation.

https://www.i2p2.de and http://i2pbote.i2p.us (remove .us if you have I2P installed).

I would love to see someone give i2p-bote a good analysis. I tried using it a couple of times but wasn't able to ever receive messages successfully. They are advertixing some pretty awesome features though; no content or metadata leakage; it is secure against a global passive adeversary if you use delays between relay hops; parties don't have to be online at the same time to communicate.

I've never had problems with receiving messages with it. Had I2P been running for at least 20 minutes or so to be able to establish enough connections? Bote can tell you how many Bote nodes it is connected to.

Bitmessage's POW concept is not only proposed but implemented and being used in practice.

my2c: The common meme in the bitmessage community is that the POW helps mitigate flooding, but it's not quite there for spam prevention

Reply on news.ycombinator.com