I have a possible deanonymization attack on py-ipv8

Bug discussion
#1

The trustchain is not opaque, therefore I can trace who gave bandwidth to whom. Although I cannot specify what file was being transferred, I can guesstimate based on the file size a list of possible files. I could also operate a malicious exit node that would perform SSL downgrade attacks on clients, a paper called “Riffle
An Efficient Communication System With Strong Anonymity” tells of a hybrid variable shuffle that would be used to ensure that a handshake between a server and a client was not tampered with, and how authentication encryption would verify that the message is legitimate after the connection has been established. (https://people.csail.mit.edu/devadas/pubs/riffle.pdf) In the future, it might be possible to crack a riffle public key on a quantum computer. It already is for ecliptic curve cryptography and 2048 bit RSA.

The ease of tampering with traffic would be used to tag each message and track its proliferation through cooperating nodes. It is also possible to derive the protocol used in the secret session by looking at the packet size because different protocols have different packet sizes. It is important that these holes are fixed so that no one can attack py-ipv8, it is also important to fix these holes so that people can trust py-ipv8.

1 Like
#2

It would be best to not push these changes too fast, or mistakes might be made. For the trustchain, one might look to Monero or Zcash for anonymization protocols that are already shown to work.

1 Like
#3

See the discussion here

1 Like
#4

You are right that TrustChain accounts granular bandwidth statistics between users. Fortunately, there are methods to address this, for example, by using ring signatures in combination with zero-knowledge proofs. These protocols, however, sacrifice scalability since such proofs are computationally expensive to compute. Another approach could be to defer and aggregate payouts by individual until a particular threshold has been reached, which would effectively make correlation attacks much more difficult. Users could also add a bit of ‘noise traffic’ to the accounting to complicate traffic correlation attacks. We added a few comments about these solutions in our peer-reviewed journal publication, see here.

Unfortunately, I cannot provide comments on the applicability of the Riffle attack in Tribler. We are using a Tor-like protocol so some of the de-anonymization attacks targeted at Tor might be a threat also in Tribler (and Tribler might expose new attack vectors).

1 Like
#5

The hybrid verifiable shuffle is the only protection I know of that can check if traffic is being tampered with. If Tribler encounters a sudden influx of users, the copyright trolls will likely set up malicious exit nodes to spy on traffic. I am willing to accept a slightly slower connection to make sure that does not happen. If successful, py-ipv8 might even be considered better than Tor.

#6

Maybe it would be an Option to configure tribler that way that it only accepts torrent Traffic that is encrypted:

Then an exit node operator can not spy easily on what content one ist downloading. BitTorrent Protocol Encryption is relativelkey weak. But may be still strong enough to provide some security against malicious outproxies.
Under european privacy laws it would anyway be illegal to do surveillance on an outproxy traffic. (At least for a private company, state agencys is a different thing of course). Trying to remove any encryption may even violate some anti hacking laws as they exist for example in germany. So i think it would be very difficult for copyright trolls to use any outproxy data to sue any users as they would have to break the law to do so.