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.
They have carefully evaded the point of what exactly those "scientists and engineers" are qualified in. Apparently not cryptography.
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.
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.
(It's also common for open source to ignore competition from commercial software, and for enterprisey products to ignore the consumer market, etc.)
To say that the whole thing is a waste of effort and money is a little strong-worded I think.
ECB mode AES? Check.
No authentication on encrypted data? Check.
RSA without blinding? Check.
Bad random number source? Check Check Check.
I lost patience trying to find where they're using Diffie-Hellman but you can bet that they're not checking parameters well, too.
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.
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.
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.
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.
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.
People are getting automated infringement notices from merely running Tribler on their machines. So even for THAT it's worse than useless.
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.
Anonymity using our dedicated Tor-like network
Search and download torrents without worries or censorship
Anonymous downloads with strong encryption
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.
Thanks for the post OP.
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.` 
edit: why, that's quite magical: http://i.imgur.com/YuXftG9.png
Pretty good advice at this point.
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.
I'm using the java.security and javax.crypto implementations, definitely not implementing algorithms on my own.
Then follow up with something like Handbook of Applied Cryptography.  It's a beast.
And to top it off with something recently modern, I'd go with Cryptography Engineering.  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.
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.
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.
Do not just go and learn the best current practices, because those aren't going to stand the tests of time.
Lesson learned (again): Don't do encryption if you don't know what you're doing.