N reasons why the spooks love Tribler | Hacker News Reader

N reasons why the spooks love Tribler

lists.torproject.org

223 points_wmd59 comments

Tribler has a very long history of making high profile claims and never being able to follow through with actually usable software, so I'm not really surprised by this.

The entire project is a combination of TU Delft publicity stunt and EU subsidies sinkhole. In 10 years of screwing around with bittorrent it hasn't produced anything that could compete with the side projects of individual hackers.

It's a disgraceful waste of community money.

The code may be fixable (though I doubt they even care), the project however isn't.

Any idea how something like this happens? They got at least 22 million euros in funding and seemed to be managed by academics but somehow completely missed the mark?

It's regrettably common for academic work to be compared only against other academic work so something can be considered novel or state-of-the-art even if it's worse than shipping products or open source. It seems possible that Tribler is the leading academic P2P system and thus deserving of more grants, which keep it in the lead.

(It's also common for open source to ignore competition from commercial software, and for enterprisey products to ignore the consumer market, etc.)

Keep in mind that the majority of the 22M EUR has been spent in the past on various P2P aspects (e.g., semantic overlay for search, modifying BitTorrent for live streams, modifying BitTorrent for Video on Demand). The anonymity/privacy aspect is quite new for Tribler (< 1 year).

"Work on Tribler has been supported by multiple Internet research European grants. In total we received 3,538,609 Euro in funding for our open source security research. Roughly 10 to 15 scientists and engineers work on it full-time." http://www.tribler.org/about.html

we are not an anti-spook project and never claimed to be. Our aim is to give an option where there is none. We will make our warning more elaborate and will work differently with bloggers/journalists in the future.

An "option" for what? Tribler seems completely useless in the light of this article. People are even getting automated infringement notices from the MPAA! What's the use case for Tribler?

Roughly 10 to 15 scientists and engineers work on it full-time.

They have carefully evaded the point of what exactly those "scientists and engineers" are qualified in. Apparently not cryptography.

These do look like serious problems, but it seems to me that all or at least most of them can be fixed. (Are there any "deal breakers"?) What they need is cryptography experts to do more than comment publicly (which is commendable, I am not criticizing), but also contribute some fixes. It is open source after all.

To say that the whole thing is a waste of effort and money is a little strong-worded I think.

The fact that such serious mistakes were committed in the first place makes it highly unlikely that they'll properly fix the system.

1. As somebody interested in P2P, I've been following Tribler for a while. Note that this is, first and foremost, a research project. It's basically a playground / lab for research and thesis work, and that's how it should be viewed. While the people who work on it (I even talked to a couple many years ago) do wish for it to be generally usable, they are academics, and so publishable material is their primary goal. That it is decently usable by the general populace at all is in itself unusual as far as most research projects go.

2. The researchers (at least as of a few years ago) were more interested in distributed systems and P2P, so the flawed crypto is not surprising to me.

3. The only reason it is getting so much scrutiny is because of recent claims that it makes "stopping bittorrent impossible". My guess is, this originated from typical university PR. What happened instead is that these claims seemed to address a long-standing need of people the world over who wish to download copyright material without being held accountable for it. This generated vastly more publicity and enthusiasm amongst circles that probably didn't know how many grains of salt university PR is supposed to be taken with. Which, naturally, resulted in a proportional amount of scrutiny, and hence, TFA.

4. As noted elsewhere, the adversary here isn't "spooks" but rather the MPAA, RIAA and the like. As such, they are probably more vulnerable to hacking-related laws and probably less motivated to exploit these flaws.

5. I haven't seen any "side projects of individual hackers" that are anywhere as close to functional as Tribler is, but then again, I haven't been looking. I'd certainly be interested in seeing some.

FWIW, funding for Tribler has significantly dried up, probably also due to this.

When I read about this sequence of severe fundamental security screw-ups in Tribler, it really scares me that Pouwelse has recently started to position himself as a cyber security expert.

I don't think that TU Delft considers Tribler a publicity stunt, but that they see it as a serious initiative, even though it probably does more harm than good to both its users and the university. Outside the academic papers and review comment process, there often isn't much of a feedback channel back into academia and giving the mass of academic conferences, it is only a matter of persistence to get something (bad) accepted.

Everything that could go wrong has gone wrong.

ECB mode AES? Check.

No authentication on encrypted data? Check.

RSA without blinding? Check.

Bad random number source? Check Check Check.

ECB mode

I think this is the worst part, as anyone who has even the slightest bit of knowledge about how to use block ciphers (even if it's just reading Wikipedia articles - http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#... ) would know ECB is seriously weak.

I believe the random number generation failures are much worse. ECB allows detection of duplicate blocks and block shuffling/copy-paste, while poor random number generation allows you to blindly recover entire keys and use them to decrypt or encrypt whatever you want.

ECB with chosen-plaintext also allows you to decrypt whatever you want.

Details?

It's one of our crypto challenges, and the conceptual basis for the BEAST attack.

I believe I read a little too much into "decrypt anything."

What were you thinking they meant? (Just curious.)

Guess and check (beast, as I understand it) requires some prior knowledge of the data format. I was imagining something that worked against entirely random data.

Yes. You can do simple things to data to make the basic byte-at-a-time attack hard to conduct. But a comparable amount of effort takes you to strong authenticated encryption. Virtually all systems that use ECB and have attacker-influenced plaintext are susceptible to the attack we're talking about.

Not exactly chosen-plaintext; pedantically speaking it's blockwise-adaptive chosen plaintext. The distinction is important because provable resistance to regular chosen plaintext attacks (i.e., IND-CPA) is part of what kept broken modes around for so long---they're 'provably secure'!

Being able to detect duplicate blocks is usually game-over for an encrypted transport. ECB is fatally broken in real applications.

Would that be the "broken by design" mode that NSA snuck in there?

No. ECB mode is simply how ciphers work. It's the black box that every better mode is built on.

Set aside "RSA without blinding"; this is RSA without padding.

I lost patience trying to find where they're using Diffie-Hellman but you can bet that they're not checking parameters well, too.

Instead of all these crypto expert complaining about how bad it is why doesn't any of them fix it and make a pull request or fork the project if it is at such a dismal state?

Maybe the reason so many coders are bad at crypto is because the crypto community is mostly spooks and the rest are unwilling take the time to explain and teach what they know.

Instead they spend hours writing and analyzing other peoples work just so they can gloat on how bad it is.

Solid writeup. My takeaway:

The protocol and library designers

1. Appear to have not read any recent crypto literature or done even the first few sets of the Matasano crypto challenges.

2. Implemented crypto and random number generation with complete disregard for best practices, which include "don't implement crypto yourself" and directly spell out things like which algorithms to use and how to get random numbers.

I got this impression too. After hearing about it (again) on HN I joined #tribler a few days ago and asked a few questions about some of their crypto choices.

whirm (who seems like a really nice guy) was pretty upfront that he wasn't a cryptographer.

The tribler webpage mentions a reputation system of sorts so I asked whirm how tribler deals with sybil attacks and his response was "I think it was dimitra who was working on that kind of stuff". I thought that was an unusual response.

I hope they take this feedback as an opportunity to redesign their system from scratch. Building a censorship free publishing system is a noble pursuit.

The whole unspoken point of the Tribler project, as I see it, is to provide an anonymous enough way to seed and leech BitTorrent to keep MAFIAA befuddled until something better comes along.

Thus, the cryptography was probably never as much in focus as in projects like Tor or Freenet which are basically designed to handle situations of life and death. If it provides a good enough plausible deniability that you can't know what's happening and what you're routing to whom while your IP address is sharing blocks of a certain movie, it's probably good enough.

While the project does aim to solve a real-world problem I would much prefer anything that's simpler than Tor or Tribler.

For example, let's say I'm seeding a blob of data, and you then download three different blobs (including mine) and xor them together and happen to get a video film as a result, nobody can plausibly claim that I, or any single one of the seeders, was actually sharing that video film. I know about the "Color of your" side of bits but xor makes things really intangible. The above scheme would work even if the blob that I was seeding only contained purely random data straight from /dev/urandom -- data that I simply chose to share publicly in order to let others use it to mix and match with their blobs in order to communicate privately.

If you're willing to sacrifice download speeds for anonymity then you would be similarly willing to sacrifice the use of bandwidth, and the above scheme is just 3x the bandwidth. And instead of creating a new online protocol, you could just keep using the regular BitTorrent in the first place; only the way you would use it would change.

Thank you for defending our work.

The media space is where society thinks; online videos need anonymous access.

Our attack model is indeed an adversary of moderate sophistication, also our architecture is design to evolve the coming years to support _offline_ sync. Really different from Tor.Sadly we did not use more disclaimers on our website, the one on anomymity.html is too little.

Our strong point is scalability, 340million Bittorrent users moving to Tor would utterly break things. With Tribler it possibly might not break, it evolved for 10 years with unbounded scalability as the key constraint and test requirement. Anyways, we will do no publicity in 2015. Only if we solve the incentive to relay problem before the Tor people do. They worked on designs for 3 years. We have deployed prototypes for 7 years.

The Tribler homepage boasts:

  Anonymity using our dedicated Tor-like network
  Search and download torrents without worries or censorship

  Anonymous downloads with strong encryption

The disclaimer is only if you click through to details on anonymity. To pretend that you just didn't put enough disclaimers on is disingenuous. Your site is actively encouraging users to use the software and not worry.

Can you comment on how y'all managed to ship such massive mistakes? And after 10 years? Even a quick read through "Practical Cryptography" would cover those errors.

> to provide an anonymous enough way to seed and leech BitTorrent to keep MAFIAA befuddled until something better comes along.

People are getting automated infringement notices from merely running Tribler on their machines. So even for THAT it's worse than useless.

http://www.reddit.com/r/tribler/comments/2pyxmk/received_two...

Dammit. I downloaded this and was excited to make it my primary tool, but thanks for this. I know next to nothing about cryptography and experts weighing in help people like my avoid getting dupped.

Thanks for the post OP.

The question is, is it less secure than current offerings (Transmission, uTorrent, qbittorrent…)?

It gives a false sense of security at best. The crypto is broken at a basic level, trivially allowing things like key recovery, denial of service, block copy-pasting...

However, about BitTorrent crypto: `In an interview in 2007, Cohen stated "The so-called ‘encryption’ of BitTorrent traffic isn’t really encryption, it’s obfuscation. It provides no anonymity whatsoever, and only temporarily evades traffic shaping.` [1]

[1] https://en.wikipedia.org/wiki/BitTorrent_protocol_encryption...

It creates a number of attack surfaces that will surely be exploited. The absence of RELAY_EARLY is a good example.

Has anyone compared Tribler and OneSwarm recently?

Would a mod care to explain why this this link was demoted? I anticipated the title correction (in this case, counter-PR to security snake oil IMHO is warranted), but I cannot fathom any reason an uncontroversial story like this with few comments would otherwise be demoted.

http://i.imgur.com/1gWWJB5.png

edit: why, that's quite magical: http://i.imgur.com/YuXftG9.png

> For users, "don't". Cursory analysis found enough fundamental flaws, and secure protocol design/implementation errors that I would be reluctant to consider this secure, even if the known issues were fixed. It may be worth revisiting in several years when the designers obtain more experience, and a thorough third party audit of the improved code and design has been done.

Pretty good advice at this point.

Related MSc thesis: "Anonymous Internet: Anonymizing peer-to-peer traffic using applied cryptography" - http://repository.tudelft.nl/view/ir/uuid%3Ace3bd867-6540-42...

It's worth bearing in mind their adversary is not "spooks", but rather the MPAA. Is the anonymity good enough to prevent the user getting nasty letters from their ISP?

No, it's not. The anonymous downloading doesn't really work either. It's day 3 of trying to download a 50MB test file right now.

Good comments about the details of the protocol. But I'm wondering why nobody found anything to comment about it on higher level than the crypto? We all know(?) that Tor and multihop data passing isn't efficient way to implement 'anonymity' for distributed file sharing.

For that particular reason I was personally amazed that they did select Tor as example. Tor wastes a lot of bandwidth as well as allows easy traffic correllation attacks in the cases where that's generally feasible. I really loved Freenet and GNUnet designs, because those use really efficient caching, partitioning, routing compared to Tor. At least in theory anonymous downloads could be even faster than when using non-anonymous downloads, due to improved efficiency of the network resource utilization due to distribution and caching. When Tor is used as base, all these benefits are lost and in addition there will be huge bandwidth overhead causing about 600% slowdown.

Does anyone agree with me? I was almost sure that someone would immediately comment this aspect, but as far as I can see, nobody has noticed these facts(?) yet.

What's a good resource to learn about crypto?

I'm using the java.security and javax.crypto implementations, definitely not implementing algorithms on my own.

http://cryptopals.com/

Often i see recommendations for NaCl(and maybe curveCP) as simple robust way to do crypt by non experts.

For a good kickstart on the topic, Applied Cryptography. (Yes yes yes, I know, much of the technical recommendations are outdated.) It's still a damn good primer on the field itself.

Then follow up with something like Handbook of Applied Cryptography. [0] It's a beast.

And to top it off with something recently modern, I'd go with Cryptography Engineering. [1] After understanding the material from the earlier readings, this book is a suitably humbling experience. There are many subtle error paths and attack vectors in applied cryptography, and this book brings a few of them on, one by one.

0: http://cacr.uwaterloo.ca/hac/ 1: https://www.schneier.com/book-ce.html

Tptacek said it's a bad idea to read Applied Cryptography. "Take that book Applied Cryptography that's on your bookshelf and burn it. Do that as a commitment to really learning crypto. But absolutely don't read it. If you don't read it, you have nothing to unlearn, so you're much better off." Source: http://wiki.securityweekly.com/wiki/index.php/Episode292 time index 22:10, but the whole podcast is good.

Instead, he recommends Cryptography Engineering: http://www.amazon.com/Cryptography-Engineering-Principles-Pr...

Another way to get a primer on crypto is to do the Matasano crypto challenges: http://cryptopals.com/

The solutions aren't (yet?) published, but don't let that stop you. It will be fairly obvious when you've come up with a solution that solves the challenge. It's also an excellent way to get you really thinking about all of the problems with crypto. And it will hopefully scare you from ever implementing your own crypto scheme, which is always a good thing.

Make sure to do all the challenges though. They get exponentially more difficult, but the best ones are near the end.

This came up often enough that I wrote a blog post about it:

http://sockpuppet.org/blog/2013/07/22/applied-practical-cryp...

> Instead, [tptacek] recommends Cryptography Engineering*

So do I, by the way - CE is a modern book and it shows just how hard it really is to build a secure protocol. But it assumes a certain baseline background.

AC is old. I do not dispute that. But as to why certain types of constructs are used, it's still a properly readable book.

And quite true, the threat models in AC do not account for active attackers who are flipping bits to do real-time differential cryptanalysis. When the book was written, "data at rest" was the most common problem.

If there is an equally readable, modern book which explains the whys of the constructs, I'd love to know. CE is a great book once you understand the basics - but IMO it's not really fit for a first pass.

Imho the best way to learn some crypto is learn the fundamental building blocks and then go and study already broken protocols and implementations. That should be enough to scare you in to the "assume everything I do is wrong and broken until proven otherwise" mindset (which could be a healthy mindset for programming in general imho)

Do not just go and learn the best current practices, because those aren't going to stand the tests of time.

The next iteration of Stanford's Coursera Cryptography 1 course starts on Jan 5: https://www.coursera.org/course/crypto

Another example of most universities not being able to release quality software that goes over the "basic algorithm" stage :(

AES in ECB mode? Oh for fuck's sake. I'm not a crypto nerd by any stretch of the imagination and even I know ECB is bad.

why on earth didn't they title this article "The Trouble With Tribler"????

Autsj.

Lesson learned (again): Don't do encryption if you don't know what you're doing.

Welp, looks like it's time to rebase on I2P.

Reply on news.ycombinator.com