mirror of
https://github.com/irungentoo/toxcore.git
synced 2024-03-22 13:30:51 +08:00
142 lines
6.9 KiB
Plaintext
142 lines
6.9 KiB
Plaintext
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):
|
|
|
|
[data to send back]
|