Surpass Tor by implementing Riffle features.

[Destroyinator69420]

Riffle is ten times faster than tor while being written in a slower language then Tor (golang instead of Clang) It supports the hybrid verifiable shuffle to enforce the rule that no node will tamper with traffic, once the TLS connection has been initiated, it uses faster authentication encryption to secure the connection by refusing to foreword tampered traffic. To enforce this, future py-IPv8 nodes that tamper with traffic or perform SSL downgrade attacks will have their trust token balance reset and paid to the victim that caught them, if they have a positive balance, they will receive trust tokens, if their balance is negative, the victim will earn 10% more for the next 2 weeks. The malicious node's address will be permanently banned from the network. The difference between the hybrid variable shuffle and authentication encryption is that the hybrid verifiable shuffle requires each node prove to the rest of the network that they are not tampering with traffic, but it is slow. Authentication encryption requires each node to refuse to forward tampered traffic and to report the node behind them, if they do not refuse to forward the tampered traffic, they will be reported instead. I will like the paper here.

[qstokkink]

Thank you for your suggestion. We can investigate and explore the internals of Riffle (both the science behind it and its implementation). However, creating an entirely new anonymization layer is not a small feat. It will take months (if not years) to properly work out this proposal. I'll tag this as "long term".

[Destroyinator69420]

I found their github for you, riffle is written in go.

[Destroyinator69420]

Here are the papers relating to issue #1077. They will be useful in resisting collusion attacks. https://www.freehaven.net/anonbib/cache/tarzan:ccs02.pdf
https://www.freehaven.net/anonbib/cache/morphmix:wpes2002.pdf
With a p2p network, 51% and collusion attacks are much more of a threat than tor, since their is no directory authority to kick malicious nodes. The Tarzan algorithm will help with malicious nodes created by copyright enforcement trolls and the scarcity of IP addresses will help mitigate 51% attacks.

[MaKeG0]

I'm sorry if i'm going to add problems but seemed to be the same kind of issue.
I was looking on the https://geti2p.net/en/ network, this is the repo https://github.com/i2p/i2p.i2p.
Mine is a noob question and i was wondering if it would be possible the use of ipv8 on i2p network.

[qstokkink]

@MaKeG0 No worries; the short answer to your question is: yes, in several different ways even. You could bridge data transfer between an IPv8 network and I2P and you could tunnel IPv8 data over I2P (and vice-versa). You could even reimplement I2P completely using IPv8's peer-to-peer UDP connections.

If you use a library like https://github.com/l-n-s/i2plib, you can probably fuse the two networks together with only a few lines of code. Of course, whether you should bridge, tunnel, or even reimplement, will depend on your use case.

[RealJosephKnapp]

@MaKeG0 No worries; the short answer to your question is: yes, in several different ways even. You could bridge data transfer between an IPv8 network and I2P and you could tunnel IPv8 data over I2P (and vice-versa). You could even reimplement I2P completely using IPv8's peer-to-peer UDP connections.

If you use a library like https://github.com/l-n-s/i2plib, you can probably fuse the two networks together with only a few lines of code. Of course, whether you should bridge, tunnel, or even reimplement, will depend on your use case.

The challenge here is I2P is written in Java for Vanilla I2P and I2P+ and C++ for i2pd. py-ipv8 is written in python with an incomplete reimplementation. Correct me if i am wrong about kotlin-ipv8 here. The Riffle protocol is very similar to Tor an we can learn from it. 1. Mandating that all messages be of an identical size decided upon by the swarm mitigates traffic analysis based on the size of the messages, shorter messages are padded with random data prior to encryption and longer messages are split into multiple messages prior to encryption and padded if necessary. The hybrid verifiable shuffle uses the slow verifiable shuffle to open and close tunnels using asymmetric encryption, I recommend Quadruple Kyber-1024 + RSA-4096 + RSA-PSS-4096 + Dilithium5. Then once the tunnel is opened faster AES-256 is used in combination with HMAC authenticated encryption and an internal hash to check that the ciphertext is not tampered with. All of this could be done with the current Tor 0.4.8.10 protocol at the cost of backwards compatibility, which py-ipv8 doesn't have to worry about to the same extent. I recommend Blake3-512 due to its speed and security, although AES-256 could be replaced with Kalyna-512, which is a derivative of AES with more rounds and a larger keysize should the CPU's cryptography extensions support it. It is also worth considering looking at Tor 0.4.8.10 and its implementation of v3 hidden services and proof of work to prevent ddos attacks, using random python code execution similar to RandomX and EquiX would prevent ASIC attacks. It would be worth looking into python wrappers for OpenSSL 3.2.1+ and LibreSSL 3.8.2+ for encryption.