All the encryption layers for SAFEnet

Features
1

In this topic I’ll try to get my head around all the different
encryption layers used for the SAFEnet. I looked into the systemdocs but I’m not a C++ programmer so I can’t get in on that level. If I’m wrong, please correct me. I love to learn about how this stuff really works on a deeper level.

First layer
I start my maidsafeclient and my ip-adres is 22.33.44.55.66.
In the client software some IP-addresses and public keys are available for me to connect to a bootstrap-node run by Maidsafe. This is to make sure I always have a safe way to connect to the network, even without peers if I just downloaded the software. Because I encrypt the data to this node, there’s no possibility for a men-in-the-middle attack. This is because the first data I sent out to this node is already encrypted. The Maidsafe node receives my message and of course I provided my own public key so we can communicate fully encrypted with each other. This is the first layer of encryption. So not your internet provider nor the NSA can look from outside the network to your communications. they have to be part of the network if they wanna know anything at all.

Second layer
The next step is to request my personal file with my data-atlas and XOR-routing table. This is a file that’s stored on the network and only I can decrypt it. I decrpyt it using my username:pin:password (actually the username and pin provide the name of this file and the password decrypts it.) In here (if it’s not the first time I’m online) there’s the info to find other peers in the network. I connect to some close nodes based on XOR and they know my IP:port:public key. Remember, my data-atlas and file with personal info was encrypted using self-encryption. This is why it’s the second layer.

This is how David puts it on his blog:

Both node types join the network in fundamentally the same way. They read from either a locally cached list of previously known nodes, or they fall back to hard coded nodes in the source code. The nodes they list have IP:PORT and Public keys. The node will encrypt a message to one of these nodes requesting login (or connect). The bootstrap node gathers this info and returns it to the joining node (encrypted).

Third/Fourth Layer
So, my close nodes have my IP:port:public key etc. So now they’re gonna watch the chunks come in and out and try to understand what I’m doing you think? Maybe they have lists of files and their chunks and try to catch me downloading an blockbuster movie from Hollywood? Well, time to add another layer of encryption. Yes, you are in group of close nodes and some of them will know your IP because they need to get data from and to your computer. So in a group of 32 close nodes (based on XOR) maybe 4 or 5 will know you IP. But now the magic starts, remember; you don’t ask for data on the network, your close nodes will. So while this group of close nodes is randomly chosen, you will connect to another group of nodes which are your (data)managers. The connection to that group will be the third layer of encryption, and maybe already a forth one! Because for something like “browsing” the Safenet you will use an identity to request data. But let’s go back a little. So, your close group connects you to the manager-group who are “somewhere” in XOR-space. This connection will be encrypted so your close nodes cannot understand the data between you and the managers. Your managers on the other hand, will understand your requests but they have no clue about who you are. To them your just another XOR-adddress that’s close to them in XOR-space. This way the close nodes will work like a proxy to protect your identity. This part is added in routing V2. And probably will be active in Testnet 3.

So, let’s look a little closer to it:

  • Some of your close nodes know your IP:port etc. But they have no idea which data you Put or Get on the network.
    They only see some gibberish data going between you and you manager group which they route for you.
  • Your manager group can see the chunks come by (ofcourse you need a place to ask to Put or Get data) but they have no clue what your IP is. They don’t even know the IP:port of your close nodes. All they see is a XOR-address asking for data through a group of other XOR-addresses.

The fifth layer
Really, is there even more?? Yes there is. All your close nodes in XOR can change. Maybe, after months of using the system you changed a lot of the close nodes because you find nodes that are closer to you. But of course you need something to prove that you are the ID that you are. If you became like a member of some sort of youtube-like site 2 months ago, you still want to be member today don’t you? Even while all your close nodes and your XOR “friends” are gone. That’s why there are different identities in Safenet. You can even create a new one for browsing every day. Or maybe every request! But some of your ID’s will be there in your data-atlas so you can always prove that you are you. So if you connect to a friend using Safenet, and you start a chat, your ID will use a PKI-system to make sure that the connection over all the hops is encrypted. Your chat is encrypted on your own computer and will be decrypted by his computer the moment it comes in. Because the Safeclient will use a number ID’s the list of encryption-layers could go on forever.

16 Likes
2

Great stuff

This is a bit out of date, the client has a bootstrap list, so you will get a public key to encrypt to that node. That allows you to pass a key in anonymous nodes for messages from the bootstrap node. On login or join as a client you will get your real keys and connect to your group (they check the request with your address and keys). As a vault you already have a proper connection key so the first bit is not required.
This way all messages are encrypted from message 1 :wink: This prevents man in the middle attacks on join, in normal mode they are already protected as you have spotted. Good analysis

It is a bit mental, but kinda has to be these days I think.

9 Likes
3

@anon40790172 this is a really helpful post and would be great if you can update it in line with David’s corrections, especially as I don’t quite understand them! We could make this a FAQ, perhaps.

3 Likes
4

The part about the bootstrap node is also quite mysterious to me, so I’m a bit scared to update my own post with that information, need more understanding. Looks to me now that only after you log in to your own data-atlas you’ll be able to connect to your closest nodes. So than it would be:

  1. I have a list with ip-adresses with port and public keys
  2. I connect on ip-level (encrypted), and ask for my personal file/data-atlas
  3. I decrypt my data-atlas, in here is my info for the 4 closest nodes and their XOR-adresses and puclic keys.

I heard @erick welcomes questions for his lectures, so maybe he can clear some things up about that. Another part I don’t really get is the XOR-adress. I get the math behind it but what if I alter the software and create a XOR-adress for my own node which is not random, and try to get close to some data or other node? I heard something about the network providing the XOR-adress. So that’s different from my node creating it’s own. Not really sure about that.

1 Like
5

Yes this is it.

To become part of the routing network (vault) there a a lot of tests, basically the network can alter any address you provide, we have done test though on the network testing an xor address you provide (it has to be equal to the hash of a public key + signature) and this allows the network to force the vault to keep trying until it provides a network address that the network agrees is OK. So in short you cannot provide an address, you can keep asking to store different keys on the PKI part of the network. This means you will be located in a group that is surrounded by older (higher ranked nodes).

For public names this scheme is the same, so for clients trying to get a public key to suit their chosen public name, the network again forces the user to keep trying (its automatic and actual people do not see the retries).

tl;dr the network only allows certain addresses to be created :smile:

5 Likes
6

I am actually at the same level of understanding you are on this at the moment (maybe a little less actually!), with the same zones of confusions, so keep asking questions until everything is crystal clear, it is helping everybody! I am busy with other things at the moment but I’ll eventually get there. Don’t worry about not getting everything right the first time or being complete either, multiple people are going to re-read, correct, and complete it eventually. As long as you are doing your best to be rigorous and thinking clearly, that should be fine. As the whole community better grasp how everything works together we should become collectively self-correcting in our understanding. (BTW, that is how a research community works ;-)).

8 Likes
7

I made a big update with the last info I got from @dirvine in this post. Hope it clears things up!
Scroll to the top to see the new version of “All encryption layers for SAFEnet”

1 Like
8

Great post @polpolrene

1 Like
9

I was thinking that maybe someone could go through how traditional server architecture works and how all those functions have been broken up into these decentralized processes.

I think that part of the problem for a lot of new people is that they don’t understand how the current client server model works, and what an improvement this represents.

3 Likes
10

I started doing it for explaining how BitTorrent works in Lecture 2, I can do more ;-).

3 Likes
11

Yeah, that would be great!

One of the things would be to explain and distinguish the vocabulary.
“In traditional client-server architecture, they have a process called A, which does this function, for this reason”
“A has these problems because it exposes your data (headers whether destination or origin, as well as content) in this way and this way.”
“SAFE breaks this process up into two roles called X and Y, which still does all the functions of A, BUT, it doesn’t have the problems of A.”

One of the problems I have with explaining to people is that I have a general sense of how the Client-server model works, but I don’t know a lot of the technical vocabulary, and so that makes it had to have a discussion and distinguish, unless I’m willing to just make up words.

@erick Getting this in written form, in some kind of a Maidsafe evangelism packet, I think could be very valuable.

1 Like
12

I spent most of the day studying encryption, which one do what, and asking myself what kind of encryption the SAFE Network use between peer if any, and what kind of encryption I think it would have.

I was going to start a new topic asking these kind of possibly repeatable question from the past, thanks to discourse feature, discourse show me this topic.

This topic is very useful and it is hidden far behind.

What paper is related to this? I didn’t find.
What documents is related to this? I didn’t find.
What wiki is related to this? I didn’t find.
Someone, please link me something related to this topic.

I think it should have a kind of static category in this forum where only moderator copy or link useful topic like that there. A kind of centralised (I know you don’t like this word) category where people like me can read all the technical details and question that are already answered there before asking our own and waste time to everyone.

Now I’m going to read the 2 first topic that referenced this one here which his questions that I was going to ask if I didn’t find them.

Sorry to bring this topic up again, but it’s really an important one.

2 Likes
13

You can study the SodiumOxide library and analyze the code. At a glance SAFE use curve25519xsalsa20poly1305 as Public-key authenticated encryption, xsalsa20poly1305 as Secret-key authenticated encryption, ed25519 as Public-key signatures and, of course, Hash512. The self encryption want to change to aessafe 256X8 cbc.

2 Likes
14

I used to think having a curated list of quality topics would be useful - still could be. We did have something similar in terms of a FAQ category, created mainly by individuals who decided to share something they learned, as a FAQ topic, but that went when we created the wiki which now holds all the FAQ.

I think the best would be to point out and fill any gaps in the wiki, which can include links to topics, but I’m not sure a curated list of topics would be worth the effort. There is already a search function, and it is a lot of work for someone to create and maintain such a list.

2 Likes
15

So this is like Tor but with only a guard and middle relay? I get that unlike Tor its not a direct singular flow between nodes, its like guard group A → Manager group B, but still when requests leave my computer it will go to a guard node and then onto a manager node, so essentially its a two hop anonymity network.

Or is it more like (request file) → break into multiple pieces → Multiple guard nodes each received a piece → each pass on to (mulitple?) manager nodes → each pass onto where chunks located in network?

16

If you look to SAFE with TOR perspective one might say that each node (vault) is a middle relay. But in TOR there are end-nodes as well which can spot that someone is looking at a particular website. In SAFE you request a file, and it comes from several sources. Maybe even 700 sources as you download a personal 700mb file. And the nodes don’t have a clue if you are looking at a website or doing something else. TOR is protecting your browsing experience. But SAFE doesn’t connect to the good old WWW and is more focused on storing and retrieving data. Including safesites.

2 Likes
17

But your guard node still sees 700 1mb chunks coming through to you right? The entire security premise of tor hinges on having a nonmalicious guard node, how is safe different in this regard?

18

@feelz I feel it’s worth mentioning to you that ip addresses are scrubbed on I believe the second hop and the data managers etc are only handling chunks of data that had already been encrypted client side.

19

Vaults just connect to each other and 3 or 4 in your group know your IP. But all they see is messages going from you to another vault.

As a client you connect over a relay_node. So you connect to a node (in XOR) and that node connects you to a group. Communication between you and the group is encrypted. So the relay-node doesn’t have a clue what’s going over the pipe. Your close group (as a client) does but they don’t know your IP as they see a connection come in from the relay_nodes. Probably 3 or 4 of them.

1 Like