Tribler: Bittorrent client with integrated Tor-like anonymity - gHacks Tech News

Tribler: Bittorrent client with integrated Tor-like anonymity

Update: Tribler security not as good as claimed. Read this for a first basic analysis.

Bittorrent has not one but two Achilles' heels: torrent indexing services and a lack of anonymity. While it is possible to overcome the latter through the use of virtual private networks or proxies, there is no viable alternative available yet for indexing services.

Tribler, which I reviewed back in September 2014, attempts to change that. It is developed by researchers at Delft University of Technology who wanted to create a system that is anonymous and impossible to shut down at the same time.

Tribler integrates torrent indexing and anonymity in the client directly which means that it does not rely on third-party services or websites for that.

While it is still possible to use these services to download or stream torrent files using the client, the idea is to move slowly but steadily away from requiring torrent indexing websites at all.

tribler

The second big feature of Tribler, anonymity, landed in the most recent version. It uses a system similar to what the Tor network offers but uses its own network which is not compatible with Tor.

Detailed information about the implementation are available on Github. If you break it down to its core, it is routing requests through several user systems automatically. Instead of downloading files directly from the seeder, they are downloaded and redirected by other users first.

This means in turn that every user of the Tribler network is a node that is being used to transfer data to other users which in turn may impact the overall download speed and your ability to seed files.

The packets received this way are encrypted with the exception of the header which consists only of an identifier used to determine where to send the packet to.

Tribler ships with search options built in that you can use to find torrents directly in the client. It is also supporting channels, collections of torrents offered by other users, which users can vote for to improve their visibility in search.

When you download a torrent file using the service you get to select the number of hops for that download. These hops, from zero to five, determine the number of computers that the encrypted packets are sent through on their way from the seeder to your computer.

The more hops you select the better the anonymity but the lower the speed.

tribler anonymity

It is interesting to note that you can specify the hops for all files you download regardless of whether you found them using the service's own search or through other services. Since you can load torrent files into Tribler, it works for them equally well.

Closing Words

The idea behind Tribler makes sense but it is too early to tell if it will take off. The security and anonymity of the service needs to be vetted by third-parties first, and on top of that, it needs to be distributed to a wider user base as it is one limiting factor when it comes to downloads.

Summary
software image
Author Rating
1star1star1star1stargray
5 based on 2 votes
Software Name
Tribler
Operating System
Windows
Landing Page




  • We need your help

    Advertising revenue is falling fast across the Internet, and independently-run sites like Ghacks are hit hardest by it. The advertising model in its current form is coming to an end, and we have to find other ways to continue operating this site.

    We are committed to keeping our content free and independent, which means no paywalls, no sponsored posts, no annoying ad formats (video ads) or subscription fees.

    If you like our content, and would like to help, please consider making a contribution:

    Comments

    1. Pd said on December 19, 2014 at 11:28 am
      Reply

      If the anonymous component is dependant on the Tribler network, that just sets up the Tribler company as an easy single point of focus target doesn’t it?

      1. Doc said on December 21, 2014 at 6:48 am
        Reply

        No, because once the client is out in the wild, the Tribler network isn’t run by Tribler any more…it’s run entirely by the nodes themselves.

    2. fokka said on December 19, 2014 at 11:37 am
      Reply

      tried it out yesterday, not very convincing yet. the 50mb testfile didn’t load, i couldn’t find much content and the stuff i found didn’t want to start downloading.

      let’s see how this changes in the future.

      1. joe said on December 19, 2014 at 2:45 pm
        Reply

        Same for me.

    3. Paul(us) said on December 19, 2014 at 12:48 pm
      Reply

      So it works likes Emule (who also has anonymity features) (-morphXt is the version I like)

    4. Dwight Stegall said on December 19, 2014 at 3:24 pm
      Reply

      Wonderful program if you don’t mind that virus AVG found in it. Yes, I downloaded it from their site, not a third-party. :(

    5. Smog said on December 19, 2014 at 11:33 pm
      Reply

      So, its not possible to download of any public tracker.? And if its possible, as everybody is a node, everyone can be a “exit-node” and get into trouble?

      1. Martin Brinkmann said on December 20, 2014 at 7:22 am
        Reply

        You can download from any public tracker. The only node that the seeder sees is the first node. If you happen to be it, you could be in trouble.

    6. kurtextrem said on December 20, 2014 at 3:01 pm
      Reply

      Is it only me or does the installation take forever?

      1. Martin Brinkmann said on December 20, 2014 at 3:27 pm
        Reply

        Did not take long at all on my system.

    7. Gonzo said on December 21, 2014 at 10:28 pm
      Reply

      Tribler is not what it claims. It’s all hype:

      https://lists.torproject.org/pipermail/tor-dev/2014-December/007999.html

    8. smaragdus said on December 23, 2014 at 12:05 am
      Reply

      As a regular torrent client Tribler is undesirable- awful interface, heavy, slow, unhandy. In fact after I updated from version 6.3.5 to 6.4.0 (the update procedure was a slow torture) I noticed that the former one worked far better than the latter since Swift has been replaced by TFTP for torrent collecting.

      About the anonymous part- despite of its flaws it shows some promise.

    9. paul(us) said on December 23, 2014 at 5:08 pm
      Reply

      Today I read this about Tribler when I was trying to get it working (No download speed)

      Recently a decentralized onion-routing based Bittorrent client known as
      Tribler has made rounds through the clickbait garbage^w^wtech
      journalism sites. Since protocol design is a research interest of
      mine, I did some casual analysis based off the documentation and
      publicly available source code.

      Disclaimer: Analysis was casual and not massively in-depth though I
      believe it to be correct. Known issues are highlighted as such, though
      there is a decent amount of new material. References to how Tor
      approaches certain design problems are provided as appropriate.

      TLDR: Do not use this if your threat model includes active attackers,
      adversaries versed in cryptography, those with lots of money, or if you
      wish to be anonymous.

      Material covered:

      * The protocol documentation located at
      https://github.com/Tribler/tribler/wiki/Anonymous-Downloading-and-Streaming-specifications

      * The source code of the “devel” branch
      https://github.com/Tribler/tribler/tree/devel/Tribler
      as of commit a98db38f60550dd304d1e329e16a41a683666c15

      Protocol flaws:

      * There is no built in safeguard against creating circuits of
      arbitrary lengths. The subset of the Tor protocol the Tribler
      designers implemented is lacking a RELAY_EARLY type construct.

      Active adversaries can exploit this flaw to create substantial load
      on the Tribler network, and mount certain kinds of attacks.

      See:
      * Proposal 110 ” Avoiding infinite length circuits”
      (https://gitweb.torproject.org/torspec.git/tree/proposals/110-avoid-infinite-circuits.txt)
      * Evans, S., Dingledine, R., Grothoff, C. “A Practical Congestion
      Attack on Tor Using Long Paths”
      (http://grothoff.org/christian/tor.pdf)

      * The symmetric encryption is ECB-AES128, without authentication.

      The former is a documented flaw in the specification and is claimed
      that it is “for testing”, with what looks like a skeletal attempt
      to use OFB-AES128 present in the code.

      ECB should not go on the wire ever and is only useful as a building
      block for other modes. Even as a “for testing” this is rather
      sloppy, and is something that should have been addressed way before
      real users start using the protocol.

      The skeletal OFB-AES128 implementation included in dead code is not
      any better as it reuses a hard coded initialization vector for every
      single encryption operation. IV reuse within a given key across
      encryption operations breaks the confidentiality of the mode.

      The lack of authentication is flat out inexcusable for reasons that
      should be obvious.

      It is worth noting that this is one of the kludgier bits of the Tor
      wire protocol currently (see the ‘digest’ and ‘recognized’ fields in
      each RELAY cell, and proposals/ideas/xxx-new-crypto-sketch.txt), so
      improvements over “what Tor does” are possible and recommended.

      Implementation flaws:

      (As an aside, it’s somewhat difficult to sort through which parts of
      the cryptography code are actually used and which are not.)

      * When gmpy is not present, Diffie-Hellman keys are generated with
      python’s random.randint(). This is issue #874, and it should be
      evident why this is incorrect, and utterly terrible.

      The fact that developer comments regarding this bug note that this
      fallback is present only because gmpy did not work on Android
      should raise massive red flags in light of the next issue.

      * When gmpy *is* installed, Diffie-Hellman keys are generated with
      gmpy’s “rand()”.

      while dh_secret >= DIFFIE_HELLMAN_MODULUS or dh_secret < 2:
      dh_secret = rand("next", DIFFIE_HELLMAN_MODULUS)

      As far as I can tell, gmpy's rand() is either unseeded or is seeded
      via the following idiom that is scattered throughout the code (I
      suspect it is the latter, due to the Paillier cryptosystem code
      being cross referenced from other modules, but it's hard to tell):

      # The definition of StrongRandom changes depending on the file.
      # But every file that uses the construct illustrated here pulls it
      # in from optional_crypto, which looks like:
      # try:
      # raise ImportError()
      # # Dead code, this would be slightly less horrific, maybe.
      # from Crypto.Random.random import StrongRandom
      # except ImportError:
      # # … Words can not describe how sad I am.
      # from random import Random as StrongRandom
      from optional_crypto import StrongRandom
      from sys import maxint

      rand('init', 128)
      rand('seed', StrongRandom().randint(0, maxint))

      The unseeded case results in a LCG of the form:

      x = 1 // Yes, a hard coded seed.
      x = (29CF535 * x + 1) % (2^32)

      It should be obvious as to why this is totally broken.

      The seeded case results in a LCG of the form:

      x = (48A74F367FA7B5C8ACBB36901308FA85 * x + 1) % (2^128)

      This is fatally broken and insecure on several fronts.

      a) "StrongRandom" is Mersenne Twister seeded once via
      os.urandom(). What little "StrongRandom" actually resembles
      something that is "Strong" and "Random" is due to the Python
      developers, though in practice it is neither.

      b) The GMP LCG is seeded with 32/64 bits of "entropy", where
      "entropy" is Mersenne Twister output.

      c) GMP's LCG is used for key generation.

      * How not to do Diffie-Hellman:

      key = pow(dh_received, dh_secret, DIFFIE_HELLMAN_MODULUS)

      This is relatively minor since recovering the secret key is trivial
      via PRNG attacks, so the fact that the modular exponentiation is not
      constant time matters less.

      * How not to do RSA:

      def rsa_encrypt(key, element):
      assert isinstance(element, (long, int)), type(element)
      _element = mpz(element)
      return long(pow(_element, key.e, key.n))

      def rsa_decrypt(key, cipher):
      assert isinstance(cipher, long), type(cipher)
      _cipher = mpz(cipher)
      return long(pow(_cipher, key.d, key.n))

      RSA being implemented without blinding, using GMP's modular
      exponentiation, and without OAEP is something I pray that I never
      see again.

      Things not covered:

      * How the intro point/rendezvous system works, including peer discovery
      and etc (Assuming it is trivial to obtain lots of ECElgamal keys/IP
      address:Port combinations of endpoints, it appears that it is
      possible to use the CREATE/CREATED response to mount an UDP
      amplification attack. But I did not check how easy this would be to
      mount in practice.)

      * The bittorrent bits.

      * The "dispersy" component beyond "ok, at least the ECElgamal key
      generation uses M2Crypto, assuming the horribly broken keygen code
      (community.privatesemantic.crypto.ecelgamal.ecelgamal_init()) is
      dead like I think it is".

      Recommendations:

      * 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.

      * For the developers:

      * Use a CSPRNG when doing key generation. Neither GMP's LCG nor
      Mersenne Twister are CSPRNGs, even if they are seeded from
      "StrongRandom" that actually is a "StrongRandom" (rather than a
      horrible misnomer).

      * Add a construct similar to RELAY_EARLY.

      * Add authenticated encryption to cell payload. This will break
      wire compatibility.

      * Use constant time modular exponentiation. As a matter of fact,
      don't include your own implementations of ECElGamal, RSA, and
      Diffie-Hellman. Use well tested/known secure library code
      instead.

      * Blind RSA operations, use padding as appropriate.

      * Fix the symmetric encryption somehow, after obtaining a in-depth
      understanding of what things break security of the mode you wish
      to use in various ways (Eg: IV/Nonce reuse).

      See: http://web.cs.ucdavis.edu/~rogaway/papers/modes.pdf

      * Instead of a DH + ElGamal handshake, consider Ntor. Even with
      GMPY, doing modular exponentiation is relatively CPU intensive,
      and there is the threat of CPU exhaustion attacks here.

      * Clean out all the dead code, after printing out copies to use to
      scare small children.

      Eg: Tribler/community/privatesemantic/crypto/elgamal.py

      Most of the fixes require major revisions to the wire protocol. As
      it appears that there is no versioning, how that will be done is
      left as an exercise for the student.

      Alternatively, rebase the system on I2P.

    Leave a Reply