The concept of the perfect messenger

Hi% username%!
This post was worth writing about three years ago, when the idea of ​​an open source secure P2P messenger appeared. But all this time I hoped that I had enough strength to cut the project into one. Unfortunately, time passed, and the project never came to life. The only thing I managed to do was to develop a detailed concept, a semblance of a protocol, and to encrypt any cryptoshtacks that would be useful when writing this messenger. And now, when there is bitmessage on the stage, very similar to my idea of ​​BitTorrent Chat and hated by all Telegram, I see that the train has left and I don’t have time for it with all my desire.
Therefore, your attention is invited to the concept of a secure, anonymous P2P messenger with a near-zero threshold of entry. I even came up with a name for him:

So, this is a post about how ParanoIM could become if I brought it to mind.

Judging by the fact that comrades of their BitTorrent Chat laid out about their project, some of the points I have are very similar to them. Let's start with them.

1. DHT

Without this thing, nowhere. If you do not know what it is, Kademlia is an empty phrase for you, then you should read about it in the relevant articles . Here I will only tell who are the nodes and what lies in the table itself.
')

But yes

Physical node Each node at startup generates a new ECC key pair, its identifier will be the hash of the public key. When exchanging information with other nodes, the public keys are exchanged, thus it becomes possible to establish a secure connection between the nodes. Of course, an MITM attack is possible here, but this is not very scary for us, because the nodes themselves do not exchange any valuable unencrypted information with each other during the construction of the network.

Subscriber

Or just a messenger user. A person who generates a permanent key pair of ECC, whose public key hash will be its unique permanent address . This hash he distributes to all, publishes and distributes in every way. Of course, it’s not very convenient to dictate 512bit hash to granny, but there's nothing to be done. There is a way around this inconvenience, but more on that later.

Initially, the subscriber behaves like a normal node. Keys exchange, joins the list of neighbors, nothing unusual. But, in order to start communicating, he randomly selects several nodes and forms a tunnel from them as follows:

1. Selects some more proxy nodes (or does not choose) that will give commands to these nodes.
2. Each of the selected nodes itself or through a proxy node sends the command “Receive a message for Id such and send such a node”

It is logical that the last node “such then” will be the node of the subscriber himself, but the others will not know about it. All that is known to the rest of the nodes is that the encrypted message for subscriber X needs to be sent to node Y. And what she will continue to do with it there, we do not know. Maybe the next will transmit, and maybe she will decipher herself.

After all selected nodes agree, the subscriber publishes in DHT (also through a chain of proxy nodes, or directly) signed with his private key a pair of "Id subscriber - Id node receiving messages for him". There may be several receiving nodes for greater fault tolerance.

After that, the subscriber can send messages by encrypting them with the key shared with him (ECDH) and on top of this by encrypting the message with the key shared with the receiving node. The receiving node decrypts its message part and forwards it to the subscriber, encrypting it with the key with the next one.

When a message gets to the subscriber's node, it does not send it anywhere, but decrypts it and reads it. (similar to i2p)

The same works in the opposite direction. The sending party can indicate in the message a list of nodes that will receive responses. Or the subscriber can receive this list himself by making a request to the DHT.

As you can see, the possibility of MITM between subscribers is excluded here, since they initially know exactly the public keys of each other, and not some other identifiers. All that an attacker can do is try to reveal anonymity, but with a large number of nodes it will be very difficult for him to do so.

2. Offline messages

Everything is simple, they can be stored in BitMessage-like storage, it is ideal for this.

3. And where is the zero entry threshold?

The problem with all sorts of cool things like torus, i2p, bitMessage and others is that they need to be configured for a long time, they have a clumsy interface and they are very difficult for untrained users.

My idea was to make a jabber server, to which the subscriber would locally cling to any jabber client to which he was used, and who himself would be a client for the ParanoIM network. Generation of key pairs \ addresses could be done in a simple web interface that would run locally.

4. What with long addresses?

It was the tastiest part, in the sense that it was supposed to make money. It was assumed that the client will be sewn up with the public key of the developers. Of course, this is an open source and whoever wanted to replace it, but the majority of users would still use the official client.

So, it would be possible to sell the usual human-readable names / uins, tying them to the hashes of subscribers' public keys. And then sign the lists of these pairs with a private key and send an update to all the nodes. Which, of course, would not hurt to contact these subscribers by their usual hash.

But, it would be possible to manage with a more civilized thing like NameCoin. Then there would be no need for any centralization.

That’s what I’d like to see my utopian IM, and I hope BitTorrent Chat will be very similar to it.