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

AnonTest: anonymous proxies for streaming (testing-only) #119

Closed
synctext opened this issue Apr 25, 2013 · 10 comments
Closed

AnonTest: anonymous proxies for streaming (testing-only) #119

synctext opened this issue Apr 25, 2013 · 10 comments

Comments

@synctext
Copy link
Member

Goal: first step towards improving your privacy. Experiment only, not yet a Darknet!

Youtube-Like GUI:
Youtube-slow-buffering

measure the performance of self-organising darknet
test user-donated proxies in great detail
quantify for each proxy: bandwidth, latency and NAT puncturing
join and download a single file
file is streamed through multiple proxies

Operation:
use WxWebView to create remote logging on a webserver
participant first goes to http:https://AnonTest.tribler.org using WxWebView
testpage is loaded, indicating starttime of test
Dispersy anontest community is joined, this community consists of willing proxies
to have sufficient oversupply of willing proxies in anontest dispersy community, we first donate to others
for roughly 4 minutes we announce as willing proxies and act as relay
after 5 minutes all help activity to others is terminated
load initiate_own_anontest.html
select randomly both how many and who will be your proxies
for the proxy chain length the following weights are used

Amount of proxies to use probability
0 20%
1 20%
2 20%
3 20%
4 20%

report initial statistics to anontest
hardcoded to streaming a 60second clip from movie like: http:https://vodo.net/thetunnel

ToDo: how many proxy chains do we build? (1 to keep it simple)
ToDo: for congestion control we require each destination to use the same proxy chain for multiple UDP packets
ToDo: how does the neighbor-invite mechanism and UDP puncture work via the exit node and swarm peers
ToDo: facilitate multiple Libswift leechers all behind exit nodes, support puncture

The webpage http:https://AnonTest.tribler.org reports with updates every 10 minutes how the test is going.
Similar to: this trial with thousands of people we conducted together with BBC in 2009
Desired outcome: performance versus anonymity gain, see figure below of streaming/download speed versus number of relaying proxies
IMG_20130425_173708

@synctext
Copy link
Member Author

synctext commented May 8, 2013

After we've run this test once, we would like to expand it with heavy crypto.
For instance, re-run the test with DTLS, similar to TLS used in TOR, https://pypi.python.org/pypi/Dtls/0.1.0

@synctext
Copy link
Member Author

What we have done, optimized for speed-reading..
Example: https://bitmessage.org/wiki/FAQ#How_does_Bitmessage_compare_to_other_messaging_methods

message Function Tor protocol specification Our Tor-subset for video streaming
CREATE Circuit
EXTEND
DESTROY -
PUNCTURE-REQ UDP NAT puncturing -
PUNCTURE UDP NAT puncturing -

PADDING (Padding) (See Sec 7.2)
CREATE (Create a circuit) (See Sec 5.1)
CREATED (Acknowledge create) (See Sec 5.1)
RELAY (End-to-end data) (See Sec 5.5 and 6)
DESTROY (Stop using a circuit) (See Sec 5.4)

     5 -- CREATE_FAST (Create a circuit, no PK) (See Sec 5.1)
     6 -- CREATED_FAST (Circuit created, no PK) (See Sec 5.1)
     8 -- NETINFO     (Time and address info)   (See Sec 4.5)
     9 -- RELAY_EARLY (End-to-end data; limited)(See Sec 5.6)
     10 -- CREATE2    (Extended CREATE cell)    (See Sec 5.1)
     11 -- CREATED2   (Extended CREATED cell)    (See Sec 5.1)

Variable-length command values are:
     7 -- VERSIONS    (Negotiate proto version) (See Sec 4)
     128 -- VPADDING  (Variable-length padding) (See Sec 7.2)
     129 -- CERTS     (Certificates)            (See Sec 4.2)
     130 -- AUTH_CHALLENGE (Challenge value)    (See Sec 4.3)
     131 -- AUTHENTICATE (Client authentication)(See Sec 4.5)
     132 -- AUTHORIZE (Client authorization)    (Not yet used)

@whirm
Copy link
Contributor

whirm commented Aug 28, 2013

@synctext
Copy link
Member Author

synctext commented Sep 2, 2013

Developers meeting (2Sep) showed the open key issues to be:
0. Operational test on DAS4 supercomputer

  1. Raw server 100% CPU problem and 6 Mbps only throughput
  2. Libswift LEDBAT congestion: Fixing congestion control issues libswift/libswift#4
  3. Rewrite of community versus current Event-Based style
  4. GUI with 2nd player on frontpage
  5. Exact details of the test (5min donate; 1min play;1080p; 6 Mbps movie ?)
  6. statistics community
  7. BarterCast3 bytecounting goes live
  8. Do first some simple Libswift download test + 1-hop proxy tests via forum.tribler.org users.

anontest_meeting_minutes__2sep2013

@synctext
Copy link
Member Author

Incremental evolution plan:

  1. single tunnel 0-4 hops and download from hard-coded seeders.
  2. multiple tunnels fixed hops and download from hard-coded seeders.
  3. add an unused global list of participating peers IPv4, public key
  4. add an unused reachability peer mechanism
  5. use global peer list to build a random-chosen tunnel

Related work:
I2P network: http:https://www.i2p2.de/how_threatmodel.html#sybil
Implemented in I2P 0.6.0.6: "Peers who do not have reachable interfaces: these peers must build a tunnel pointing at them where the gateway is one of the peers they have established a connection with who has both a publicly reachable interface and who has agreed to serve as their 'introducer'".

@Devristo
Copy link
Contributor

Devristo commented Oct 2, 2013

Several ways we can use the Hashcash algorithm suggested by I2P

In general the hashcash algorithm:

  • Harder to follow / deanonymise many nodes
  • Costs to follow little/single node still bearable for global adversaries.
  • Only useful if the resources available to malicious nodes are not far higher than 'correct nodes'.

Places we can use them:

  • create a partial hashcollision to the proxy overlay hash, with his own ip address as 'email address'
    • Makes creating identities multiple identities on the same IP costly
  • Same as above but with netmask
    • Makes creating identities in the same range costly
    • Works better with the /x subnet masks we discussed.
  • Use it in circuit creation, partial hash collision with previous nodes public key
    • Will make it more expensive to eclipse a path.
    • All public keys are known by initiator so can verify them all.

@synctext
Copy link
Member Author

synctext commented Oct 3, 2013

The last 3 bullet points are unclear to me.

Hashcash is just a rate-limiting mechanism, it fails to build real trust.
BarterCast builds real trust around digital identities. Identities need to cost something to thwart the Sybil attack.

I suggest focusing on building an operational multi-tunnel system and leave Sybil,Hashcash to the next developer/student..

Interesting that the 11 years old I2P project never managed to nail HashCash:
"We currently have not implemented any particular technique to address Sybil, but do include placeholder certificates in the router's and destination's data structures which can contain a HashCash certificate of appropriate value when necessary (or some other certificate proving scarcity)." http:https://www.i2p2.de/how_threatmodel.html

@Devristo
Copy link
Contributor

Devristo commented Dec 9, 2013

plot

@synctext
Copy link
Member Author

synctext commented Jun 3, 2014

Towards a generic anonymous downloading mode
tribler_6 3pre_anonymous_downloading_checkbox_27feb2-014

@Devristo
Copy link
Contributor

Devristo commented Jun 4, 2014

Some graphs (no crypto)

latencies_density
latency_scatter

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants