The concept of the perfect messenger


    Hi% username%!
    This post was worth writing about three years ago, when the idea of ​​open-source secure P2P messenger came up. But all this time I was hoping that I had enough strength to cut the project into one. Unfortunately, time passed, but the project never came to life. The only thing I managed to do was to develop a detailed concept, a kind of protocol and fill in all sorts of crypto pieces that would be useful when writing this messenger. And now, when there is a bitmessage on the stage, very similar to my idea of ​​BitTorrent Chat and hated by Telegram to everyone, I see that the train has left and I will not be in time with it if I wish.
    Therefore, we offer you the concept of a secure, anonymous P2P messenger with a near-zero entry threshold. 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 what the comrades of their BitTorrent Chat posted about their project, some of the points I have are very similar with them. Let's start with them.

    1. DHT


    Nowhere without this thing. 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 you 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 public key hash. When exchanging information with other nodes, there is an exchange of public keys, thus it becomes possible to establish a secure connection between the nodes. Of course, an MITM attack is possible here, but it’s 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 ECC key pair for himself whose public key hash will be his unique permanent address . He distributes this hash to everyone, publishes and distributes it in every possible way. Of course, it’s not very convenient to dictate a 512-bit 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. It exchanges keys, replenishes 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 a few more proxy nodes (or does not select) that will issue commands to these nodes
    2. Each of the selected nodes itself or through the proxy nodes sends the command "Receive a message for Id such and such and pass this node"


    It is logical that the last node "such" will be the node of the subscriber, but the rest will not know about it. All that the other nodes know is that the encrypted message for subscriber X needs to be transmitted to node Y. And we don’t know what it will do with it there further. Maybe he will pass it on, or maybe she will decrypt it herself.

    After all the selected nodes have agreed, the subscriber publishes in DHT (the same way, through the proxy node chain, or directly) the pair “Id of the subscriber - Id of the node receiving the message for him” signed with his private key. There can be several host nodes, for greater fault tolerance.

    After that, you can send messages to the subscriber by encrypting them with a shared key (ECDH) and encrypting the message with the key shared with the receiving node over it. The receiving node decrypts its part of the message and passes it on to the subscriber, encrypting with the common key with the next node.

    When a message arrives at the subscriber’s node, he doesn’t forward it anywhere, but decrypts it and reads it himself. (similar to i2p)

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

    As you can see, the possibility of MITM between subscribers is excluded here, as they initially know exactly each other's public keys, 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.

    2. Offline posts


    It's simple, they can be stored in a BitMessage-like storage, it is ideal for this.

    3. And where is the zero entry threshold?


    The problem with all kinds 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 complicated for unprepared users.

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

    4. What about long addresses?


    It was the most delicious part, in the sense that it was supposed to bring money. It was assumed that the developer’s public key will be wired into the client. Of course, this is open source and anyone who wants to could replace it, but the majority of users would still use the official client.

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

    But, one could get by with a more civilian thing like NameCoin. Then there would be no need for any centralization at all.

    That's all sobsno, so I would like to see my utopian IM, and I hope BitTorrent Chat will be very similar to it.

    Also popular now: