This commit is contained in:
irungentoo 2015-09-15 22:07:17 -04:00
commit a5c6247d3a
No known key found for this signature in database
GPG Key ID: 10349DC9BED89E98

View File

@ -9,30 +9,30 @@ The generated public key is set as the client_id of the peer.
Adding a friend Adding a friend
--------------- ---------------
Alice adds bob to her friends list by adding his 32 byte public key (client_id) to her friends list. Alice adds Bob to her friend list by adding his 32 byte public key (client_id) to her friend list.
2 cases: 2 cases:
case 1: Alice adds Bobs public key and bob waits for Alice to attempt to connect to him. case 1: Alice adds the public key of Bob, then Bob waits for Alice to attempt to connect to him.
case 2: Bob and Alice add their respective public keys to their friends list at the same time. case 2: Bob and Alice add their respective public keys to their friend lists at the same time.
case 1: case 1:
Alice sends a onion data (see: Prevent_tracking.txt) packet to bob with the encrypted part containing the friends request like so: Alice sends an onion data (see: Prevent_tracking.txt) packet to Bob with the encrypted part containing the friend request like so:
``` ```
[char with a value of 32][nospam number (4 bytes)][Message] [char with a value of 32][nospam number (4 bytes)][Message]
``` ```
Ex message: hello bob it's me alice -_- add me pl0x. Ex message: hello Bob it's me Alice -_- add me pl0x.
For more info on the nospam see: Spam_Prevention.txt For more info on the nospam see: Spam_Prevention.txt
Bob receives the request and decrypts the message using the function crypto_box_open() Bob receives the request and decrypts the message using the function crypto_box_open()
If the message decrypts successfully: If the message decrypts successfully:
If Alice is already in Bobs friends list: case 2 If Alice is already in Bob's friend list: case 2
If 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. If Alice is not in Bob's friend list and the nospam is good: Bob is prompt to add Alice and is shown the message from her.
If Bobs accepts Alice's friends request he adds her public key to his friends list. If Bob accepts Alice friend request he adds her public key to his friend list.
case 2: case 2:
Bob 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 Bob and Alice both have the others public key in their friend list, they are ready for the next step: Connecting to an already added friend
In the next step only crypto_box() is used for encryption and only crypto_box_open() for decryption (just like in the last step.) In the next step only crypto_box() is used for encryption and only crypto_box_open() for decryption (just like in the last step.)
@ -46,9 +46,9 @@ Crypto request packets
-------------------------------------- --------------------------------------
``` ```
[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] [char with a value of 32][Bob (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]
``` ```
The 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. The encrypted message is encrypted with crypto_box() (using Bob's 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.
Each node can route the request to the receiver if they are connected to him. This is to bypass bad NATs. Each node can route the request to the receiver if they are connected to him. This is to bypass bad NATs.