From 01949b6a679d4949735972283284309d8caef0bd Mon Sep 17 00:00:00 2001 From: irungentoo Date: Mon, 23 Dec 2013 16:21:07 -0500 Subject: Added proposal on how to solve all the privacy related problems with the DHT. --- docs/Prevent_Tracking.txt | 141 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 141 insertions(+) create mode 100644 docs/Prevent_Tracking.txt (limited to 'docs') diff --git a/docs/Prevent_Tracking.txt b/docs/Prevent_Tracking.txt new file mode 100644 index 00000000..eb8db794 --- /dev/null +++ b/docs/Prevent_Tracking.txt @@ -0,0 +1,141 @@ +Current privacy issues with the Tox DHT: + +1. It makes tracking people across different IPs very easy. +Solution: Have each new DHT use a temporary public/private key pair not related +to the long term public/private key pair. + +2. Metadata on which key is friends to which can be collected (The hardening +makes this somewhat harder by introducing a bunch of random traffic but not +impossible.). +Solution: If no long term keys were used in the DHT it would solve this +problem. (possibly knowing which ip is connected to which is much less +precious.) + + +So, it seems all our privacy problems are solved if we can manage to make every +node in the DHT have a keypair that is not related to the long term keys and is +generated every session. + + +So, every node in the DHT now has a temporary keypair not related to their real +long term one. + +But, how do people find themselves then? We have to add a way for people to +tell their friends what their DHT public key is, we also have to somehow make +it so people can send/receive friend requests, this has to be done without non +friends being able to find out where a node is. + +The solution: Onion routing + enable the storage of some small amount of data +on +DHT nodes. + + +Alice and bob are friends, before joining the DHT they generate temporary +session keypairs to be used for the DHT instead of their long term keys. + +Bob finds a bunch of random nodes then picks 3 random working ones (A, B, C). + +Bob gets the know working node with an id closest to his real one from his list (D) + +Bob then creates an onion (the packet will go through A, B, C and will end up at D) +announce request packet with his real public key, ping_id as zeros and +searching for his real public key. + +Bob will announce response packets and will recursively send onion announce request packets +to closer and closer nodes until he finds the ones closest to his real public key. + +Once he has done this, he will send some onion announce request packets with the right ping_id previously +received from the node when he queried it to announce himself to the node. + +The nodes he announces himself to keep the information to send onion packets to that node in memory. + +Alice meanwhile searches for the Nodes closest to Bobs real id using a temporary keypair and announce +request packets, she does this until she finds nodes that respond with a ping_id of zero. + +She sends data to route request packet with information telling Bob her temporary id in the DHT +(or a friend request if she is not friends with him). + +Bob finds her by using her temporary id and they connect to each other. + + +NOTE: crypto_box is used for all the asymmetric encryption and crypto_secretbox is used for all the symmetric. +Also every DHT node have a random symmetric key which they use to encrypt the stuff in normal get node request that is +used to encrypt stuff in the following. + +Onion packet (request): + +initial (sent from us to node A): + +[uint8_t packet id (128)][nonce] +[our temp DHT public key]encrypted with our temp DHT private key and the pub key of Node A and the nonce:[ +[IP_Port of node B][a random public key]encrypted with the random private key and the pub key of Node B and the nonce:[ +[IP_Port of node C][a random public key]encrypted with the random private key and the pub key of Node C and the nonce:[ +[IP_Port of node D][data to send to Node D]]]] + +(sent from node A to node B): + +[uint8_t packet id (129)][nonce] +[a random public key]encrypted with the random private key and the pub key of Node B and the nonce:[ +[IP_Port of node C][a random public key]encrypted with the random private key and the pub key of Node C and the nonce:[ +[IP_Port of node D][data to send to Node D]]][nonce (for the following symmetric encryption)]encrypted with temp symmetric key of Node A: [IP_Port (of us)] + +(sent from node B to node C): + +[uint8_t packet id (130)][nonce] +[a random public key]encrypted with the random private key and the pub key of Node C and the nonce:[ +[IP_Port of node D][data to send to Node D]][nonce (for the following symmetric encryption)] +encrypted with temp symmetric key of Node B:[IP_Port (of Node A)[nonce (for the following symmetric encryption)] +encrypted with temp symmetric key of Node A: [IP_Port (of us)]] + +(sent from node C to node D): +[data to send to Node D][nonce (for the following symmetric encryption)]encrypted with temp symmetric key of Node C: +[IP_Port (of Node B)[nonce (for the following symmetric encryption)] +encrypted with temp symmetric key of Node B:[IP_Port (of Node A)[nonce (for the following symmetric encryption)] +encrypted with temp symmetric key of Node A: [IP_Port (of us)]]] + +Data sent to Node D: + +announce request packet: +[uint8_t packet id (131)][nonce][our real long term public key or a temporary one (see next)] +encrypted (with our real long term private key if we want to announce ourselves, a temporary one if we are searching for friends) and the pub key of Node D and the nonce:[[(32 bytes) ping_id][client id we are searching for]] + +(if the ping id is zero, respond with a announce response packet) +(If the ping id matches the one the node sent in the announce response and the public key matches the one being searched for, +add the part used to send data to our list (if the list is full make it replace the furthest entry)) + +data to route request packet: +[uint8_t packet id (133)][public key of destination node][nonce][temporary just generated public key]encrypted with that temporary private key and the nonce:[data] +(if Node D contains the used to send data for, it sends the stuff in this packet as a data to route response packet to the right node) + +Data sent to us: +announce response packet: +[uint8_t packet id (132)][nonce] +encrypted with the DHT private key of Node D, our long term public key and the nonce:[[(32 bytes) ping_id][Node_Format * (maximum of 8)]] +(if the ping id is zero, it means the client id we are searching for is stored on ) + +data to route response packet: +[uint8_t packet id (134)][nonce]encrypted with that temporary private key and the nonce:[data] + +Onion packet (response): + +initial (sent from node D to node C): + +[uint8_t packet id (140)][nonce (for the following symmetric encryption)]encrypted with temp symmetric key of Node C: +[IP_Port (of Node B)[nonce (for the following symmetric encryption)] +encrypted with temp symmetric key of Node B:[IP_Port (of Node A)[nonce (for the following symmetric encryption)] +encrypted with temp symmetric key of Node A: [IP_Port (of us)]]][data to send back] + +(sent from node C to node B): + +[uint8_t packet id (141)][nonce (for the following symmetric encryption)] +encrypted with temp symmetric key of Node B:[IP_Port (of Node A)[nonce (for the following symmetric encryption)] +encrypted with temp symmetric key of Node A: [IP_Port (of us)]][data to send back] + +(sent from node B to node A): + +[uint8_t packet id (142)][nonce (for the following symmetric encryption)] +encrypted with temp symmetric key of Node A: [IP_Port (of us)][data to send back] + +(sent from node A to us): + +[uint8_t packet id (143)][data to send back] -- cgit v1.2.3