Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Basic P2p tunneling (p2t2p) feature request. #2

Open
speakeasy opened this issue Sep 27, 2018 · 2 comments
Open

Basic P2p tunneling (p2t2p) feature request. #2

speakeasy opened this issue Sep 27, 2018 · 2 comments
Labels
enhancement New feature or request

Comments

@speakeasy
Copy link

speakeasy commented Sep 27, 2018

It would be nice to have some degree of privacy possible in tunneling connections so that a second anonymous rendezvous dht is established for peer <-> tunnel peer <-> peer sharing is possible using anonymous connections. Basically this would comprise of end to end rsa/dsa encryption handshakes for aes through a 1 hop encrypted tunnel peer. It may also include a routing sharing ratio. This would have to use a secondary dht layer or object where users would generate extended signed pubkeys for single connections. The handshake should hide the expected public key/cert from the proxy peer and then smaller chunks say 1kb with a hash tree for say 9kb chunks could be routed through multiple peers simultaneously using shot lived tunnels (e.g. a minute), the self signing cert could be generated ever hour or 24 hours etc. for signing key/certs for rendezvous. or any other ideas about tradeoffs?

This would be especially useful for punching holes using p2t2p negotiated over tor to keep torrenting off of tor and i2p but anonymize dht functions through hidden services. Preventing easily unmasking the data being sent per users and thereby usual attacks used by corporations to track filesharing. Not necessarily highly secure from a determined enough attacker but enough to establish network neutrality and prevent censorship.

Also obfsproxy support would be nice. Possibly another feature.

@pfrazee pfrazee added the enhancement New feature or request label Sep 27, 2018
@pfrazee
Copy link
Contributor

pfrazee commented Sep 27, 2018

Tunneling requires the tunnel to give a lot of bandwidth. I'm not sure it should be a feature of the DHT, because it'd require the nodes to give away that bandwidth for free.

@speakeasy
Copy link
Author

speakeasy commented Oct 2, 2018

Well it would use more than running dht alone but would add anonymity in dht lookups. Not necessarily for data transfer but also in a torrent protocol it could exist. I believe they should be separate. Just considering that it should create a reasonable doubt, although I see that it would double bandwidth and overhead for the nodes it would provide security from an adversary. In fact such a protocol for torrents with the separate implementations would provide a reasonable security from ip traffic logging without sharing valid information, and that would constitute entrapment for an agency run adversarial program. Furthermore it could he possible to use a consensus for blacklisting IPs but that might negatively affect security. And then if it can be assured with a high degree of statistical accuracy that it is in fact and must have been entrapment then data can be shared freely because anything otherwise converges on it being the fruit of the poison tree.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants