Encryption scheme

[povilasb]

I'm raising this issue based on discussion at #1084 (comment)

The problem is that some people might expect that Crust always uses authenticated encryption. This is not true in case of direct connections. When someone is connecting to Crust publicly accessible listener, encryption scheme will look like this:

1. remote peer uses anonymous encryption to encrypt the first message: Connect(our_pub_key), Bootstrap(our_pub_key), etc.
2. remote peer immediately switches to authenticated encryption and expects future messages to be encrypted in such way;
3. Crust connection listener accepts new incoming connection, decrypts the first message and switches to authenticated encryption;
4. all further messages will be encrypted using authenticated encryption.

So as you see, the communication starts with anonymous encryption. The reason is that, the Crust connection listener is not capable of identifying the incoming TCP/uTP connection based on it's source port so that it could immediately use authenticated encryption.

Maybe some hackery is possible so that upper layers could somehow hint what connections with what public keys we're expecting. But such implementations don't seem feasible to me.
Do we have any security concerns with anonymous encryption in the beginning?

[ustulation]

This has nothing to do with source port etc. Connections should be allowed by crust only if it's trustable. People shouldn't be randomly connecting to each other, the dht layer should govern who needs to connect to whom. If crust doesn't know if it should accept a connection from someone it should either reject it or buffer it (in LRU cache etc) until it hears from the user that the connection is indeed needed (then read anything on it or write to it, for the 1st time)

[ustulation]

Otherwise if you just allow ppl to randomly connect to each other, the upper layer then has to do the work of buffering/discarding messages/connections - so that is just shifting the responsibility which could have been done by crust especially since it has to deal with keys too (so conceptually allow only the known keys to connect). Whether this part should go to yet another layer is up for debate, but i feel crust could easily do it as it also has the responsibility of actually using the keys (indicating it has some knowledge of the situation already).

[povilasb]

The problem is that when everything is encrypted from the very first message, there's no way to identify the incoming message. Say it is encrypted with authenticated encryption. Then we have no way do decrypt it, because we don't know the peer that sent this message. That's why I mentioned TCP/UDP packet source port, cause that would possibly the only way to identify incoming connections. Otherwise, we would be just guessing. So that's an argument against using authenticated encryption in connection listener.

Regarding unexpected connection filtering in Crust I do agree that Crust could do it. In this case we still don't need authenticated encryption for connection listener. We can

1. use anonymous encryption to receive the first message that only connection listener can decrypt
2. have every message (Connect, Bootstrap, etc.) send their public key
3. using this public key, terminate unexpected connections immediately
4. accept other connections and upgrade to authenticated encryption

To my mind, from security and usability perspective such scheme should work ok.