Skip to content

Instantly share code, notes, and snippets.

@Aztorius
Last active May 8, 2016 18:40
Show Gist options
  • Save Aztorius/424b2e2fab421f0c0e54535d67849436 to your computer and use it in GitHub Desktop.
Save Aztorius/424b2e2fab421f0c0e54535d67849436 to your computer and use it in GitHub Desktop.
Snotra Protocol Specifications

Snotra Protocol v1.0

by William Bonnaventure

Intro

The Snotra Protocol is a TCP/UDP-based protocol designed to communicate between users in a secure and decentralized way.

The main idea is that all users are at least in one group. These groups can have many members (up to 16) including the one who created it. When we want to join the network for the first time, we have to join an existing group or create one. We can be in multiple groups at the same time (no limit).

Everyone is identified by a public key, and keeps the private key. When we want to join a group, we have to share our public key to a member of the group, and he must give us his public key too. Then we sent a request to join the group. Only the owner of the group or those who have the master key (a private key) of the group can add or remove somebody from it.

When we are in a group, we participate to its survival. Everyone in the group can have a dynamic IP address, so in order to find everybody later we have to make a file which contains the IP address and port with the last update date all of this encrypted by the private key of the user. When we want to connect to the group, the first thing to do is to test every IP address we registered in the file. When we find someone connected, we request this file to update all other IP address. Then we send our updated IP address and infos encrypted with our private key. As a consequence, a group can only survive if at least one person has the same IP address since the last update.

There are different level of "friends". The Unknown level is used if an incoming connection is received. The Neighbour level is used if the person is in the same group as you. The Contact level is used if you known the person. The lower level between two users define the global exchange permissions. With the Unknown level, no data is sent. With the Neighbour level, the file to maintain the group is exchanged, some basic requests are allowed, and a minimal chat also. With the Contact level everything is allowed (sharing files to him, communicate with voice/text/webcam, download files, search files, ...).

All trafic is encrypted. First with RSA, and then with AES. Files can be shared and downloaded in a similar way of torrents. First someone share a file so the software create a file like a .torrent, and then tell to all his contact (on every group) he has that file. Every group have a file that contains all filenames and size of files shared by members of a group.

All files are transferred in two ways. If the receiver is a Contact, we sent directly to him. If the receiver is anyone else, the traffic is routed through one of the sender's contact and one of the receiver's contact.

SENDER -> RECEIVER/SENDER's contact

SENDER -> SENDER's contact -> RECEIVER's contact -> RECEIVER

When we search a file, we sent the request to all our Contacts for a filename or a specific file (with its digest). Then they try to find the file in every group they are except the origin group of the request. Searching in one group is very fast because we can see in the file of the group if anybody shares a similar file. So searching in 16 users shares is done within 1 second. We sent also with the request the epoch time in second so we can stop searching after a predefined amount of seconds. If someone find the requested file in a group, he send back a response and start a tunnel through him to send the file.

If there is an average of 16 members in each group and everyone is in 3 groups and if it take 2 seconds to transmit the request. If we set a limit at 15 seconds, it will request to 2^(15/2) = 181 users. And in global, it will search the file over 181x3 = 543 groups <=> 543x16 = 8688 users. But because there is redundancy, these numbers are lower in reality. If a file has a probability of 0.3% to be own by a user, 8000*0.003 = 24 users have the file, so it can be downloaded.

The file is sent piece by piece. First, the size and the digest of each piece is sent, also with pieces owned by the source (if the download is incomplete). Then the user asks for a specific piece of the file and download it. When all pieces are retrieved, the file is complete. Each piece is verified with the digest. Pieces can be downloaded from different users at the same time. When we have at least one piece of the file, we can share it without having all pieces.

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