summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--docs/updates/Crypto.md77
-rw-r--r--docs/updates/Spam-Prevention.md12
-rw-r--r--docs/updates/Symmetric-NAT-Transversal.md43
3 files changed, 132 insertions, 0 deletions
diff --git a/docs/updates/Crypto.md b/docs/updates/Crypto.md
new file mode 100644
index 00000000..6b489c3b
--- /dev/null
+++ b/docs/updates/Crypto.md
@@ -0,0 +1,77 @@
1Draft proposal for how crypto will be implemented.
2
3
4Encryption library used: http://nacl.cr.yp.to/
5
6
7When running the program for the first time the crypto_box_keypair() function is used to
8generate the users public-private key pair. (32 bytes each)
9
10The generated public key is set as the client_id of the peer.
11
12Note that only the crypto connection runs on top of Lossless UDP. The friend requests do not.
13
14Adding a friend
15---------------
16
17Alice adds bob to her friends list by adding his 32 byte public key (client_id) to her friends list.
182 cases:
19case 1: Alice adds Bobs public key and bob waits for Alice to attempt to connect to him.
20case 2: Bob and Alice add their respective public keys to their friends list at the same time.
21
22case 1:
23Alice sends a crypto request packet to bob with the encrypted part containing the friends request like so:
24```
25[char with a value of 32][nospam number (4 bytes)][Message]
26```
27
28Ex message: hello bob it's me alice -_- add me pl0x.
29
30For more info on the nospam see: [[Spam Prevention]]
31
32Bob receives the request and decrypts the message using the function crypto_box_open()
33
34If the message decrypts successfully:
35If Alice is already in Bobs friends list: case 2
36If Alice is not in Bob's friends list and the nospam is good: Bob is prompt to add Alice and is shown the message from her.
37If Bobs accepts Alice's friends request he adds her public key to his friends list.
38
39case 2:
40Bob and Alice both have the others public key in their friends list, they are ready for the next step: Connecting to an already added friend
41
42In the next step only crypto_box() is used for encryption and only crypto_box_open() for decryption (just like in the last step.)
43
44
45Connecting to an already added friend
46-------------------------------------
47
48Alice and Bob are friends.
49As soon as they connect they each generate a new keypair which will only be used for the current connection (The session keys).
50They then send themselves the following packet (the crypto handshake) (encrypted part encrypted with the public nonce in the packet the public key of the receiver and private key of the sender)
51```
52[char with a value of 02][Senders Public key (client_id) (32 bytes)][Random nonce (24 bytes)][Encrypted message containing: [random 24 bytes base nonce][session public key of the peer (32 bytes)]]
53```
54
55If the packet is decrypted successfully:
56Each start using the secret nonce, the public key provided by the other and their own session private key to encrypt data packets (adding to it + 1 for each packet.)
57Each node sends themselves an empty data packet (data packet with 4 encrypted zero bytes)
58Data packet:
59````
60[char with a value of 03][Encrypted data]
61````
62Each data packet received is decrypted using the secret nonce sent to the other (with +1 added for the first packet +2 for the second, etc...) along with the private session key of the receiver.
63Every data packet sent is encrypted using the secret nonce we received (with +1 added for the first packet +2 for the second, etc...), the session public key of the receiver and the session private key of the sender.
64
65The encrypted connection is only deemed successful when the empty data packet is received and decrypted successfully.
66
67
68Crypto request packets
69--------------------------------------
70
71```
72[char with a value of 32][Bob's (The reciever's) Public key (client_id) (32 bytes))][Alice's (The sender's) Public key (client_id) (32 bytes)][Random nonce (24 bytes)][Encrypted message]
73```
74
75The encrypted message is encrypted with crypto_box() (using Bobs public key, Alice's private key and the nonce (randomly generated 24 bytes)) and is a message from Alice in which she tells Bob who she is.
76
77Each node can route the request to the reciever if they are connected to him. This is to bypass bad NATs.
diff --git a/docs/updates/Spam-Prevention.md b/docs/updates/Spam-Prevention.md
new file mode 100644
index 00000000..a0713fd1
--- /dev/null
+++ b/docs/updates/Spam-Prevention.md
@@ -0,0 +1,12 @@
1
2Situation 1:
3Someone randomly goes around the DHT sending friend requests to everyone.
4
5Prevented by:
6Every friend address:
7[client_id (32 bytes)][nospam number (4 bytes)][checksum (2 bytes)]
8contains a number (nospam).
9
10The nospam in every friend request to that friend must be that number.
11
12If not it is rejected.
diff --git a/docs/updates/Symmetric-NAT-Transversal.md b/docs/updates/Symmetric-NAT-Transversal.md
new file mode 100644
index 00000000..49038216
--- /dev/null
+++ b/docs/updates/Symmetric-NAT-Transversal.md
@@ -0,0 +1,43 @@
1Notes:
2
3Friend requests need to be routed.
4
5The current DHT should be capable of punching all NATs except symmetric ones.
6
7######
8
9Symmetric NAT hole punching:
10
11If we are not connected to the friend and if the DHT is queried and ips
12returned for the friend are the same but the port is different, the friend is
13assumed to be behind a symmetric NAT.
14
15Before attempting the procedure we first send a routed ping request to the
16friend. This request is to be routed through the nodes who returned the ip of
17the peer.
18
19As soon as we receive one routed ping request from the other peer, we respond
20with a ping response.
21
22Ping request/response packet:
23See: Crypto request packets in [[Crypto]]
24
25Message:
26For the ping request:
27[char with a value of 254][char with 0][8 byte random number]
28
29For the ping response:
30[char with a value of 254][char with 1][8 byte random number (The same that was sent in the request)]
31
32As soon as we get a proper ping response from the other we run the different
33ports returned by the DHT through our port guessing algorithm.
34
35######
36
37Port guessing algorithm:
38
39Right now it just tries all the ports directly beside the known ports.(A better one is needed)
40
41######
42
43We send DHT ping requests to all the guessed ports, only a couple at a time.