NAT Traversal & Bootstrapping

[anon40790172]

@dirvine

Therefore it is easy for the network to encrypt the last hop direct to the client.

Ohw, I thought this was already the case, that the close nodes in XOR did this before they pass the data to the relay nodes. But you want indeed do this at the last part otherwise it would hurt caching?

[dirvine]

@Tonda

What if the attacker does what I stated before? Creates a database of chunks they deem illegal then encrypts each them with the target users public key to analyze the appearance of it when encrypted (i.e, fingerprint). As the relay, the attacker waits until the target requests an illegal chunk. Now that the attacker now knows what the chunk in question looks like when encrypted with the targets public key, they can identify that the requested chunk is indeed an illegal chunk. I know that this computationally expensive and impractical, but it is indeed possible right?

That is OK, chunks encrypted like that will not be chosen by a user as the data map a user has will point to real chunks. What I am suggesting will mean all attackers see is an encrypted stream with zero knowledge of it’s contents. So they wont see anything, encrypted with another key anyway, If a chunk is encrypted with anything other than content it will not be an immutable chunk from a known datamap. So we are OK there as well, if that makes sense. The attacker would make a list of chunks nobody wants.

If the relay can see nothing except encrypted streams then he has no idea what they are even if he knows some “illegal” chunks look like.

I am not 100% sure I am answering you here, shout if not and I can add some more info to this point. Maybe worth starting a thread about self encryption and snooping or similar. Though saying that will mean debating the pre rfc perhaps and I am not sure there is bandwidth in the dev team just now as we are pushing pretty hard. We can see though.

[Tonda]

In the case of outbound data. Is it possible for the client to add random sacrificial bits to the chunks payloads to alter its appearance for the outbound relay node. Once the chunk is in XOR space, one of the managers or groups could just discard the random sacrificial bits and proceed normally. That way the attacker will not be able to mach any public data on the network with any of the data they relayed for any given client. Yay?

[anon40790172]

@Tonda

What if the attacker does what I stated before? Creates a database of chunks they deem illegal then encrypts each them with the target users public key to analyze the appearance of it when encrypted (i.e, fingerprint). As the relay, the attacker waits until the target requests an illegal chunk. Now that the attacker now knows what the chunk in question looks like when encrypted with the targets public key, they can identify that the requested chunk is indeed an illegal chunk. I know that this computationally expensive and impractical, but it is indeed possible right?

If the client would use a different key for the XOR-group next to the relay node you wouldn’t have this problem. Just keep the relay node in the dark about the key used between the XOR-group and the client.

[dirvine]

@anon40790172

Ohw, I thought this was already the case, that the close nodes in XOR did this before they pass the data to the relay nodes. But you want indeed do this at the last part otherwise it would hurt caching?

Yes each hop encrypted direct between nodes, but the relay reads the data and encrypts to the client. The scheme mentioned would mean the relay is in fact relaying blind, which is nice in terms of last hop security.

As you say this is last hop only or caching is busted, so we get best of both worlds here I think. I should say this is pre-rfc, but seems to make sense with no side effects apart from no cache in your relay for you, which is probably a good thing.

[anon40790172]

@dirvine

I should say this is pre-rfc, but seems to make sense with no side effects apart from no cache in your relay for you, which is probably a good thing.

I don’t know how much delay each layer of encryption creates. Might slow down data a bit?

[dirvine]

@Tonda

In the case of outbound data. Is it possible for the client to add random sacrificial bits to the chunks payloads to alter its appearance for the outbound relay node. Once the chunk is in XOR space, one of the managers or groups could just discard the random sacrificial bits and proceed normally.

All the client needs to do is know it’s close group (Maid Managers) and encrypt direct to each of them. It reduces the attack vector to close groups only and may even be improved beyond that. They need not be connected to their close group, but several things are better if they do, like push notifications etc.

[Tonda]

I’m a bit confused. The previously stated attack vector not open for exploit?

@Tonda

Creates a database of chunks they deem illegal then encrypts each them with the target users public key to analyze the appearance of it when encrypted (i.e, fingerprint). As the relay, the attacker waits until the target requests an illegal chunk. Now that the attacker now knows what the chunk in question looks like when encrypted with the targets public key, they can identify that the requested chunk is indeed an illegal chunk. I know that this computationally expensive and impractical, but it is indeed possible right?

Basically if I wanted to figure out what public data you are downloading as your relay, could I grab all of the “illegal” chunks off of the SAFE network, take all of those “illegal” chunks encrypt them all with your public key then take a snapshot of how each chunk looks like while encrypted with your public key ( basically a data fingerprint).

I would then proceed (as your relay) to capture your inbound encrypted chunks and compare them to the ones I already encrypted with your public key. If they match, game over you lose.

Is this possible? If yes, can we mitigate this by having the close group add a few random bits to the chunks before encrypting them with your public key (the bits can be thrown away when the chunk reaches the client).

Would this alter the appearance of the encrypted chunk and prevent (me as the evil relay) from recognizing the chunks fingerprint and nailing you to the wall?

[dirvine]

@Tonda

Basically if I wanted to figure out what public data you are downloading as your relay, could I grab all of the “illegal” chunks off of the SAFE network, take all of those “illegal” chunks encrypt them all with your public key then take a snapshot of how each chunk looks like while encrypted with your public key ( basically a data fingerprint).

Ah I see, it’s like this.

1. Authenticated encryption means both parties have each others key (node to node etc.)
2. Anonymous encryption (nacl box_seal) means it is one way encrypted (your attack uses this)

So I see the confusion. The notion is that the last hop encrypt would indeed use anonymous encryption and would present the problem you describe here. It would mean encrypt every chunk like that and compare. But it’s actually worse. The Get response contains a get request (signed by you) and some other info form the original message, so they would need to get your get request and enclose that in the chunk and encrypt it … and so on.

So you raise an interesting point, never the less. If the second from last node was also know to you then we could use authenticated encryption (which would be then no open to this attack). Now if the second to last node was one of your close group we have all the info we need for this to take place. Then an attacker would require to get your close group … and so on (again).

Now then, in both cases, if your Get client was anonymous, which for us means create a throw away keypair. Then this becomes significantly harder (never impossible as no encryption is, anyone can guess a key, it’s just infeasible).

Anyway, the long and short here is that when we do the RFC for this we should consider these points in more detail. It is already very hard as there would need to be a ton of encrypts and compares, but also with snooped on Get requests (signed) so then this gets very hard. However with this security stuff it is best to assume we somehow can get and be in the route of the Get request. Then we can dig into this more. I see where you are coming from and I hope this gives some more info. It will be in an RFC very soon. I have 2 to get done and should get onto these shortly, there is some debug and nat_trversal to sort along with some business meetings I need to really get into as well. It won’t be long though.