WO2019004942A1 - Algorithms for peer-to-peer messaging system - Google Patents

Algorithms for peer-to-peer messaging system Download PDF

Info

Publication number
WO2019004942A1
WO2019004942A1 PCT/SG2018/050318 SG2018050318W WO2019004942A1 WO 2019004942 A1 WO2019004942 A1 WO 2019004942A1 SG 2018050318 W SG2018050318 W SG 2018050318W WO 2019004942 A1 WO2019004942 A1 WO 2019004942A1
Authority
WO
WIPO (PCT)
Prior art keywords
keys
clients
client
server
devices
Prior art date
Application number
PCT/SG2018/050318
Other languages
French (fr)
Inventor
Dmitry Mikhaylov
Quanan ZHANG
Andras BOBRENKO
Aliaksei RADZIVONAU
Original Assignee
Sitechexport Pte. Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sitechexport Pte. Ltd. filed Critical Sitechexport Pte. Ltd.
Publication of WO2019004942A1 publication Critical patent/WO2019004942A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/164—Adaptation or special uses of UDP protocol
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/12—Transmitting and receiving encryption devices synchronised or initially set up in a particular manner
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/12—Shortest path evaluation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H04L45/745—Address table lookup; Address filtering
    • H04L45/7453—Address table lookup; Address filtering using hashing

Abstract

The present application discloses a system that enables NAT traversing using UDP hole punching by using at least one client device with a publicly available IP address and software for each client that implements a protocol to perform UDP hole punching and which distributes information about clients having publicly available IP addresses, clients successfully passed the NAT traversing and clients using relay servers with relay servers' information. The application also discloses a system to enable session key establishment when syncing parties are not able to be online at the same time comprising client software that creates Diffie-Hellman half keys and session keys and publishes the half- keys on a server that also manages the distribution of the half-keys and encrypted messages.

Description

ALGORITHMS FOR PEER-TO-PEER MESSAGING SYSTEM
Background
In the area of instant messaging and VoIP, there are currently a bunch of solutions, built with fairly similar architecture.
For messaging, the industry-standard is to use so-called client-server architecture, when each client (where client means a piece of software, run on client device - smartphone, desktop computer, laptop, etc.) communicates with server (where server means a piece of software, commonly known as back-end, which runs on a computer, usually owned by instant messaging service provider, and accessible over Internet). When a client A wants to send a message to another client B, he sends it to the server with mark «message for client B», and client B then can pull this message from server (pulling can be done periodically, or can be triggered by some events).
For VoIP calls, the scheme is generally the same. The difference is, that some of VoIP clients use so-called peer-to-peer connections when transferring voice/video signals, because using server to re-translate the signal is usually too expensive in terms of resources (the server internet connection is usually fast and broad-band, but still limited, it's computational powers are usually significantly larger, than on any client device, but also limited) and may lead to significant delays, because average delay will be sum of delay from Client 1 to Server and from Server to Client 2. Peer-to-peer connection is a networking connection when two devices are connected «directly» in terms of networking.
There are two huge problems in these approaches. First, this solution's infrastructure has «critical» points - e.g. disabling server means disabling the system overall (disabling may occur due to accident e.g. hardware failure, power failure etc. or due to Denial of Service - DoS - attacks). Even if there is more than one server, their number is still limited, and in multi-server architecture there usually exists a DB server or servers, whose number is even less, than the number of servers, that communicate with clients.
Second, each active client (e.g. client who communicated with server at least once) uses computational resources and internet channel of the server, meaning each client costs some money to a company owning a server.
This application is intended to eliminate or significantly decrease the effect of the above 2 issues. State of the art
There are well-known solutions, that operate in so-called «server-less» mode. In the area of IT, more than a dozen of years exist a bunch of P2P file sharing services (like
BitTorrent or e-Mule), that are almost server- less. The creators of this protocols did not create servers at all or reduced their functionality so that the mentioned price of single active user is significantly lower, compared to traditional architectures.
When instant messaging over IP became more and more popular, these technologies were brought to messaging. Widely-known solutions are Bleep, Tox and many others.
These messengers used peer-to-peer (direct) connections for messaging (peer-to-peer was used only for VoIP before).
What it actually means - for these messengers to operate they do not need servers. Each client in their network is itself a small server.
They operate well and solve the problems of traditional architecture, but only when we speak about laptop and desktop computers.
Though most of these messengers have mobile client, they are quite not usable, because smartphones operate differently, than desktop or laptop because of energy saving policy, which dictates another operating system architecture. Smartphones do not allow applications to operate constantly (for example, iOS gives an application a small period of operation time when it is putted into background and then this app will not have any processor time until it is pushed forward by direct user's action - e.g. pressing application's icon or pressing a so- called push notification, a pop-up that notifies user that application has a new event or information available), or warns user about it (like on modern Android devices, the user is informed if any application consumes too much battery power). Still, even if constant operation is allowed and user is not warned, applications that operates constantly, and, moreover, constantly uses network - which is a high-consuming operation in terms of battery usage - will have a significant usage and market limitations.
What it all really means, from one side we want clients to communicate directly with each other, from the other side, we understand, that mobile clients will (and should) most of the time stay offline (and their mobile application will be unavailable for direct
communication) .
So, with smartphones specialty in mind, we come to a problem of offline messages - when Client 1 wants to send a message, a document or initiate a call with Client 2, who's messaging application is offline. This problem does not exist in traditional architecture (server is supposed to be online «eternally» - which means so-called up-time characteristic - the percent of time server is available - to be >99%).
Another problem is the security - even if we create any solution for offline peer-to-peer messaging, security should be taken into account. Current security trend and industry- standard is so-called «perfect forward security*. It means, that:
1) each message should be encrypted with end-to-end encryption;
2) encryption key should be re-negotiated with a certain frequency (the frequency is calculated in bytes"1 unit of measure, which means that we should update this key every N bytes sent);
3) if client's secret data (long-term key used for client authentication) were stolen, it must not affect the security of already-sent data - and this is a key point, that differs perfect forward security from a plain end-2-end encryption, which can be implemented with asynchronous encryption easily and doesn't require all communicating clients to be online at the same time.
Here we should put a side note about long-term keys. Each client has a so-called key- pair - a Public Key and a Secret Key, generated locally when user registers in messaging system or when he first signs-in, depending on specific implementation. This key-pair is used in authentication operations. They are called "key-pair" because when some message M is encrypted with one key, it can be decrypted only with the other one. So, if we encrypt something with Public Key (SK), the notation is PK(M), to get M back we have to make SK(PK(M)), and vice versa. PK is accessible by everyone (that's why it is Public). This key- pair, again, is used only for authentication, and this scenario is called «signing» - Client 1 sends message M, containing random data, to Client 2.
So, according to perfect forward security principles, if SK becomes known to a hacker, we must ensure that previously sent messages cannot be decrypted. To do so, we can use Diffie-Hellman algorithm, or any of its derivations, but for "key negotiation" procedure, which is a part of all varieties of Diffie-Hellman algorithm, it is needed, that both users communicate, and, in peer-to-peer scenario, require that both users have to be online when one desires to chat with another.
These 2 problems are commonly known as «Asynchronous Offline Messaging* and «Asynchronous Offline Perfect Forward Security*, and this application addresses both of them.
And the last important point is a so-called multi-device usage. A common scenario of messenger usage is to have the same account on smartphone, laptop and desktop PC, because 1) It is much more comfortable to write messages using a physical keyboard, and, when it is available, users prefer laptop or desktop PC rather than smartphone;
2) Most of people use messengers for their business purposes also, so messengers can not only be used for texts or calls, but also require file sharing feature. But most of files are created on laptops/desktop PCs.
It becomes clear, that we should assume, that user may have two or more devices, sharing the same account and when message is sent or received, it should eventually be available on all devices. And, as we previously stated, message can be sent or received when one or all of user's device are offline.
There's a related issue called history retrieval. We should assume, that user can log-in into his account on a new device while there already exists a history of texting and files shared on another devices using this account.
Description of Drawing
Figure 1 shows a general UDP hole punching implementation
Figure 2 shows a network structure of serverless P2P-traversing
Invention description
In this application we propose the messaging system, based on peer-to-peer communications, that resolves 4 general problems:
1) We have to beat the problem of large per-user cost of traditional architecture;
2) We have to deal with offline messages;
3) We have to provide perfect forward security when one user is offline;
4) We have to provide the way to use same account on different devices, including history retrieval.
The first problem is resolved partly with peer-to-peer communication scheme, but still exists even in P2P. We must note here, that not all client devices, specifically - not all internet connection types of client devices, allows peer-to-peer communication. Majority of clients are connected to Internet via so-called NAT - Network Address Translation. In practice, it means that several devices have single "external" (also known as "white") IP address - address, that is accessible via Internet - and these clients can perform only «outgoing» connections, but not receive incoming connections.
There are several techniques, that deal with NAT. The industry-standard is ICE (Interactive Connectivity Establishment), but implementing ICE also requires a server. To deal with it, we propose a new technique of NAT traversal, P2P-traversing. This technique generally relies on the same solutions as ICE, but doesn't strongly rely on server. In fact, in case if just one user has «white» IP (e.g. doesn't use NAT to access Internet), the system proposed can operate without server. Or there may be just 1 medium-capacity server running ICE software, that will allow a huge network to start P2P connections.
To describe the P2P-traversing, first we describe the NAT Traversing technique called UDP hole punching as shown in Figure 1.
On Figure 1, the entities are:
1) CLIENT 1 is a messaging software running on device;
2) CLIENT 2 is another instance of messaging software running on another device;
3) NAT is a networking software and hardware (like router) used by CLIENT 2 to access Internet;
4) SERVER is an instance of ICE software running on a machine, available over internet.
On Fig. 1, the steps are shown with numbers 1-4 as follow:
1) CLIENT 1 sends a UDP packet to SERVER. It first goes to a device that implements NAT (usually, a router)
2) Router (NAT on the fig.) sends this packet further to a SERVER, remembering, that this packet was sent be CLIENT 1 and the program port X is allocated for this request. This is done, because, if SERVER wants to reply, it will reply to NAT device on the same port, so NAT device has to remember to which client it has to send message, came to this port.
3) The SERVER sends the IP and port X it saw from CLIENT l's request to CLIENT 2 (this can be done in many ways, essential is that CLIENT 2 somehow gets this credentials »).
4) CLIENT 2 now sends packet to IP and port X it gathered from SERVER. NAT device remembers that all packets from port X should go to CLIENT 1 and translates it to him. This is, actually, a P2P communication.
This technique is called UDP hole punching, and, as it seen from fig. 1, requires a server.
Now we propose the algorithm, that doesn't require server all the time, just at the very beginning. In case the system has at least 2 clients and one of them has "white" IP address and its IP address is known to other clients, the system doesn't require server at all - server functions may be delegated to this client. If the system would also comprise at least 1 server, running the same software as clients, but, as a server, having a significantly data channel bandwidth and availability, it may improve stability and connection establishment speed. In case of this solution servers can be geographically spread to increase stability and connection establishment speed in the region.
Referring to Figure 2 of the present invention, let's assume that CLIENT 3, 4, 5 has "white" IP addresses. Also, let's assume, that these addresses are somehow known to CLIENT 1 and CLIENT 2, which desire to communicate. Also, let's assume that these IP addresses are also known by CLIENT 3, 4, 5 (e.g. CLIENT 3 knows addresses of CLIENT 4 and 5).
In this case both CLIENT 1 and CLIENT 2 can perform NAT traversal, using CLIENT 3, 4 or 5 as a SERVER on fig. 1. What we should assume here is:
1) CLIENT 3, 4 and 5 are untrusted, which means they may want to perform an attack on the internal infrastructure, providing wrong IP:Port data to others;
2) CLIENT 3, 4 and 5 can be executed on any devices and may have not 100% availability;
3) It may be expensive in terms of time and battery usage for CLIENT 1 and 2 to perform NAT traversal on each CLIENT 3, 4, 5. Information from this traversal should be distributed and replicated multiple times between these clients.
To overcome these issues, every client implements the following protocol:
1) CLIENT 1 sends UDP requests with his identifier to every IP:port he knows, in this request client puts his identifier in messaging system (e.g. his public key). This is done periodically, e.g. several times per second
2) CLIENTS 3, 4, 5 listen for incoming UDP requests, and, when they receive one, they respond with duplet IP:Port where IP:Port is an IP:Port pair where they got this request from
3) If UDP hole punching is available for the kind of NAT CLIENT 1 is using, he will receive the IP:Port duplet. CLIENT 1 then replies with ID:IP:Port:DateTime:Nonce:Signature quintet (we'll call it a connection quintet), where ID is CLIENT l's identifier in the system (generally - his Public Key), DateTime is a timestamp, Nonce is a number-used-once - a cryptographic "salt", and a Signature is calculated as: Signature = SKl(ID+IP+Port+DateTime+nonce),
Where SKI is a Secret Key of CLIENT 1.
4) CLIENT 3, 4 or 5 (the one that originally received UDP packet from CLIENT 1 and replied with a IP:Port duplet) should receive this message and store it in his database (updating record if another record for the same ID already exists) and distribute it among other clients with "white" IP Addresses.
5) All CLIENTS implement the request "get connection quintet". Once they need to connect to some ID, they perform this request to "white" IP clients, verify the quintet using Signature and communicate with another CLIENT using this connection credentials.
Let's imagine we have 100 clients and 1 "white" IP client, that is known by everyone. It runs the same software, as clients, but it's IP address is known by clients at the very beginning.
Right after start, all the clients shall perform P2P traversing with "white" IP CLIENT and it will collect all the connection quintets, according to the protocol. According to steps 5, server will share this data among everyone on request.
What happens if we now turn off the "white" IP CLIENT and one of the clients will change its IP, making the connection quintet invalid:
1) All the connection attempts to this client will fail
2) It will be able to P2P-traverse using information about other clients which were not invalidated because their connection quintets are still valid and it can perform P2P traversing with them as like they have "white" IPs
3) After traversing performed with some CLIENT N according to steps 1-4 of the protocol, CLIENT N will have an updated version of connection quintet;
4) According to step 4 of the protocol, these changes will spread across the network. According to step 5 new credentials will be used once some CLIENT M would like to communicate with CLIENT whose IP has changed.
So, we see, that this network, once established (precisely speaking, sufficiently established, because server may go down before full network table will be spread among all clients), is self-sufficient even without a single client with "white" IP address. Using signed connection quintets, we may assume that it will be impossible to pollute the network with wrong connection quintets. Let's see in details how it is done.
When some CLIENT N is requested for connection quintet, it replies with the quintet:
ID Connection Quintet : DateTime : Nonce : S ignature Here, ID is CLIENT N's ID in the network, Connection Quintet is a connection quintet for requested client, DateTime is a timestamp of response, Nonce is nonce, Signature is calculated as:
Signature = SK(ID+Connection Quintet+DateTime+Nonce)
We should assume here that all clients have their clocks synced (it can be performed in a multiple of ways which are outside the scope of this Application).
To verify the connection quintet, receiver should verify:
1) Signature of the response is correct;
2) DateTime of the response should be reasonably (< 10 minutes is assumed to be a reasonable value) close to request time;
3) Connection Quintet's Signature is correct;
4) The Connection Quintet's DateTime is more or equal to the DateTime of the latest Connection Quintet for the desired client, if it already exists in requester's database.
Using these 4 checks, it will be easy to verify the response is valid. If it is not, this client will not be used for connection quintet retrieval any more. It may be blacklisted locally or globally, according to specific implementation. The global blacklisting may occur if Signature checks were failed.
It must be noted here, that UDP hole punching is the most reliable, but not the only technique of NAT traversing. There are 2 more techniques. One is called «router-assisted traversing* and the other - «traversing using relay net», or TURN. The first technique can be implemented locally and does not affect the described protocol. TURN, though, is not a pure «ΝΑΤ traversing*: it actually uses external server as a relay. The TURN information can be added into first UDP traversing request and saved along with the connection quintet.
It is important to say, that this solution has some assumptions:
1) if new not- "white" IP client comes to network, "white" IP client is needed;
2) if a significant number of users would change their IP addresses simultaneously, the network may not be re-established without a "white"-IP client.
But still, the solution proposed has advantages both over traditional and P2P architectures, because mentioned situations rarely occur. It's worth mentioning, that Distributed Hash Tables algorithm is an option to provide connection information distribution across network.
Next, we have to address the issue of offline messages. Actually, we need just several additions to address it. Two things needed to be implemented is routing and extending the protocol to send/receive message and store it to local DB. The algorithm looks like:
1) Find the shortest route to client, except tested ones (on the first run it is direct connection), and take the closest to the destination online node
2) If there are no online nodes at all, go to step 1, else - send message
The protocol is extended:
1) Client can send message
2) Client listens to messages, if received, it goes to DB if message is for anther user, or it is shown to user if the message is for this user
3) Client can push message closer to its receiver ones he sees that closer node to the receiver is available
4) When pushed, message is removed from client's persistent storage
According to this algorithm, message will be pushed as close to the client as possible, and once he'll be online and message will be in 1 push before him OR closer paths will be found, the message will be delivered. To ensure reliability of this solution, messages can be pushed to several nodes (which are the same clients) simultaneously, where these nodes may be selected randomly, based on how close they are to the receiver, based on their availability or their traffic throughput capabilities. Also, each client can have a reliability rating, depending on the overall uptime.
The proposed algorithm successfully resolves the issue with asynchronous offline messaging in P2P networking.
It is important to say, that proposed solution has some disadvantages:
1) it creates additional network traffic;
2) it is slower, than on traditional architecture.
But still, it overcomes more serious issues of traditional and P2P architectures.
The last issue to address in the proposed application is perfect forward security.
Let's see the traditional Diffie-Hellman algorithm:
1) Alice and Bob agree on a finite cyclic group G of order n and a generating element g in G. (This is usually done long before the rest of the protocol; g is assumed to be known by all attackers.) The group G is written multiplicatively.
2) Alice picks a random natural number a, where 1 < a < n, and sends gAa to Bob.
3) Bob picks a random natural number b, which is also 1 < b < n, and sends gAb to Alice.
4) Alice computes (gAb)Aa, which is a secret key.
5) Bob computes (gAa)Ab, which is a secret key. The first step does not actually include protocol - it is «hard-coded» during application development.
As it can be seen, stages 2 - 3 require communication, while we need it to be done, when one client is offline. Let's assume, that Alice is offline when Bob wants to communicate with her. Also, let's assume, that before going offline, Alice performed the following:
1) Generated a bunch of random numbers a [al , a2, ... , am] ;
2) Using this array, created array of half -keys [gAal, gAa2, gAam];
3) Saved them locally in duplets KeylD-i : gAai
4) Sent them to nearby clients (whose IP addresses and ports are known to her).
Now, Bob have to do following:
1) Find online clients, who store Alice's half-keys
2) Get any of them, preferably - random, with it's Key-ID
3) Make from it a secret key (generate random number b, make (gAa)Ab)
4) Send message, encrypted on this key, and include Key-ID and gAb into this message Now Alice, when online, will be able to receive message, find her half-key using Key- ID, complete it to a full-key using gAb, that Bob attached to message.
Of course, this scheme is quite primitive, Alice's signature is required on every half -key distributed into the system, but still it allows to implement perfect forward security in asynchronous offline messaging.
So, the proposed solution successfully resolves general challenges of instant messaging: significantly reduces impact of server denial in case of accident or malicious attack, allows offline messaging in peer-to-peer communications, allows perfect forward security in chats when one user is offline.
Worth to say, the approach of P2P traversing and offline perfect forward security can be implemented together and separately, depending on specific needs. For example, if we don't need perfect forward security, just end-to-end encryption can be implemented along with P2P traversing. In this case encryption is performed using long-term keys. At the same time, traditional client-server architecture can benefit from implementing the proposed modification of Diffie-Hellman. In this case, it will be possible to support perfect forward security between asynchronously offline clients.
We can extend the protocol of establishing perfect forward security to support multiple devices using same account. The goal is to be able to receive all incoming and outgoing messages on all devices sharing the same account. To achieve this, we have the following options:
1) Periodically synchronize the database between devices using peer-to-peer connection between them. This synchronization can be performed using direct connection (e.g. plug smartphone in a laptop or synch over same network), using server (when two clients exchange their databases over server and them perform a merge operation);
2) Establish a long-term key between all devices and that will be used to synchronize half -keys between devices;
3) All devices sharing same account shall publish the half-keys, and all clients who want to send messages to them will send same message multiple times, using these half-keys, and all outgoing messages should be encrypted with session key, generated from receiver's half-key and session keys, generated from half -keys of other devices using same account;
Using this extension, we will be able to support multiple devices simultaneously using same account.

Claims

Claims
1. A system, that enables NAT traversing using UDP hole punching in a network comprising:
a. At least 1 client devices connected to the global network using NAT b. At least 1 client devices connected to the global network and having publicly available IP addresses
c. Software for each client implementing a protocol to perform UDP hole punching using pre-defined addresses of clients with publicly available IP addresses, distribute information about clients having publicly available IP addresses, clients successfully passed the NAT traversing and clients using relay servers with relay servers' information
2. A system from claim 1, which uses Distributed Hash Tables to spread connection information across network
3. A system from claim 1, also comprising at least one server, which runs the same software as clients and has at least 1 "white" IP address which is known to the clients
4. A system from claim 1, also comprising a system for local blacklisting of clients, accidentally or maliciously spreading wrong connection information based on 2- layer signature checks of connection information and connection information synchronization response
5. A system from claim 1, also comprising a system for global blacklisting of clients, based on spreading information about their IDs, accidentally or maliciously spreading wrong connection information based on 2-layer signature checks of connection information and connection information synchronization response
6. A system to enable session key establishment when syncing parties are not able to be online (have network connection) at the same time, comprising:
a. Client software, that creates Diffie-Hellman half -keys and publishes them on a server
b. Client software that takes one of half -keys from a server, creates a session key and publishes half-key used to create a session key on a server c. Server, that manages distribution of half -keys and distribution of encrypted messages
7. A system from claim 5, that uses another client to store half-keys and encrypted messages
8. A system from claim 6, that implements algorithm of shortest route search to find best candidates to store half-keys
9. A system from claim 7, that uses multiple clients to store same half-keys to improve their availability
10. A system from claim 8, where clients to store same half-keys are selected based on how close they are to receiver
11. A system from claim 8, where clients to store same half-keys are selected based on their availability
12. A system from claim 8, where clients to store same half-keys are selected based on their traffic throughput capabilities
13. A system from claim 5, that enables to sync incoming and outgoing messages between multiple devices keeping the perfect forward security using periodic database synchronization between devices using same account over a direct connection
14. A system from claim 5, that enables to sync incoming and outgoing messages between multiple devices keeping the perfect forward security using periodic database synchronization between devices using same account, exchanging their databases over a server and performing a merge operation
15. A system from claim 5, that enables to sync incoming and outgoing messages between multiple devices keeping the perfect forward security by establishing long- term keys between devices using the same account and using these long-term keys to encrypt random numbers, from which half-keys are generated, and publishing them along with half-keys
16. A system from claim 5, that enables to sync incoming and outgoing messages between multiple devices keeping the perfect forward security, where all devices publish their half-keys, all incoming messages are encrypted with session keys, generated from all devices half-keys and all outgoing messages are encrypted with session keys with session keys with receiver and session keys generated from half- keys of all other devices using same account
PCT/SG2018/050318 2017-06-30 2018-06-29 Algorithms for peer-to-peer messaging system WO2019004942A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
SG10201705421UA SG10201705421UA (en) 2017-06-30 2017-06-30 Algorithms for peer-to-peer messaging system
SG10201705421U 2017-06-30

Publications (1)

Publication Number Publication Date
WO2019004942A1 true WO2019004942A1 (en) 2019-01-03

Family

ID=64742444

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SG2018/050318 WO2019004942A1 (en) 2017-06-30 2018-06-29 Algorithms for peer-to-peer messaging system

Country Status (2)

Country Link
SG (1) SG10201705421UA (en)
WO (1) WO2019004942A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112152992A (en) * 2020-07-21 2020-12-29 北京天顶星智能信息技术有限公司 End-to-end data secure transmission network communication method and device
US20230269213A1 (en) * 2022-02-22 2023-08-24 Whatsapp Llc Client-to-client message synchronization

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6330671B1 (en) * 1997-06-23 2001-12-11 Sun Microsystems, Inc. Method and system for secure distribution of cryptographic keys on multicast networks
US20070162750A1 (en) * 2005-12-01 2007-07-12 Hartmut Konig Method for changing a group key in a group of network elements in a network system
US20090316687A1 (en) * 2006-03-10 2009-12-24 Peerant, Inc. Peer to peer inbound contact center
US20100146126A1 (en) * 2008-12-04 2010-06-10 Microsoft Corporation Peer-to-Peer Network Address Translator (NAT) Traversal Techniques
US20120039453A1 (en) * 2009-03-23 2012-02-16 Telefonaktiebolaget Lm Ericsson (Publ) Event identification in peer to peer networks
CN101645870B (en) * 2008-08-07 2013-04-17 赵运磊 Method for exchanging secret key effectively and fairly
US20130173747A1 (en) * 2011-11-21 2013-07-04 Young Jin Kim System, method and apparatus providing address invisibility to content provider/subscriber
US9497160B1 (en) * 2013-06-24 2016-11-15 Bit Action, Inc. Symmetric NAT traversal for direct communication in P2P networks when some of the routing NATs are symmetric

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6330671B1 (en) * 1997-06-23 2001-12-11 Sun Microsystems, Inc. Method and system for secure distribution of cryptographic keys on multicast networks
US20070162750A1 (en) * 2005-12-01 2007-07-12 Hartmut Konig Method for changing a group key in a group of network elements in a network system
US20090316687A1 (en) * 2006-03-10 2009-12-24 Peerant, Inc. Peer to peer inbound contact center
CN101645870B (en) * 2008-08-07 2013-04-17 赵运磊 Method for exchanging secret key effectively and fairly
US20100146126A1 (en) * 2008-12-04 2010-06-10 Microsoft Corporation Peer-to-Peer Network Address Translator (NAT) Traversal Techniques
US20120039453A1 (en) * 2009-03-23 2012-02-16 Telefonaktiebolaget Lm Ericsson (Publ) Event identification in peer to peer networks
US20130173747A1 (en) * 2011-11-21 2013-07-04 Young Jin Kim System, method and apparatus providing address invisibility to content provider/subscriber
US9497160B1 (en) * 2013-06-24 2016-11-15 Bit Action, Inc. Symmetric NAT traversal for direct communication in P2P networks when some of the routing NATs are symmetric

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
FROSCH T. ET AL.: "How Secure is TextSecure?", 2016 IEEE EUROPEAN SYMPOSIUM ON SECURITY AND PRIVACY, 12 May 2016 (2016-05-12), pages 457 - 472, XP055566892, [retrieved on 20180917] *
MARLINSPIKE M. ET AL.: "The X3DH Key Agreement Protocol", REV. 1, 4 November 2016 (2016-11-04), pages 1 - 11, XP055566900, [retrieved on 20180917] *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112152992A (en) * 2020-07-21 2020-12-29 北京天顶星智能信息技术有限公司 End-to-end data secure transmission network communication method and device
US20230269213A1 (en) * 2022-02-22 2023-08-24 Whatsapp Llc Client-to-client message synchronization

Also Published As

Publication number Publication date
SG10201705421UA (en) 2019-01-30

Similar Documents

Publication Publication Date Title
AU2012262053B2 (en) System and method for secure instant messaging
CA2636780C (en) Method and device for anonymous encrypted mobile data and speech communication
US9078128B2 (en) System and method for secure identity service
JP2008508573A (en) Improvements related to secure communications
WO2022173882A1 (en) Secure network protocol and transit system to protect communications deliverability and attribution
Kaiser et al. Efficient privacy preserving multicast DNS service discovery
WO2019004942A1 (en) Algorithms for peer-to-peer messaging system
Ma et al. DTLShps: SDN-based DTLS handshake protocol simplification for IoT
Kaiser et al. Adding privacy to multicast DNS service discovery
EP4008085B1 (en) Secure out-of-band symmetric encryption key delivery
US11716222B2 (en) Communications bridge
Wang et al. T-IP: A self-trustworthy and secure Internet protocol
Hiller et al. The case for session sharing: relieving clients from TLS handshake overheads
CN111327628B (en) Anonymous communication system based on SDN
AlSabah et al. PriviPK: Certificate-less and secure email communication
Martinez-Julia et al. Secure identity-to-identity communications over content-centric networking
Avramidis et al. Chord-PKI: Embedding a public key infrastructure into the chord overlay network
Rahman et al. Implementation of Secured Portable PABX System of Fully Fledged Mobility Management for Unified Communication
US20230199001A1 (en) Secure streaming media based on updating hypercontent in a secure peer-to-peer data network
Tsai et al. A scalable anonymous server overlay network
EP3890269A1 (en) Client privacy preserving session resumption
Saboori et al. Dual-Path Peer-to-Peer Anonymous Approach
Loesing et al. Implementation of an instant messaging system with focus on protection of user presence
Buford et al. Property-Based Peer Trust in the Sleeper Service Discovery Protocol
Karimov et al. DEVELOPMENT OF SECURE MODELS AND ALGORITHMS FOR THE EXCHANGE OF SERVICE MESSAGES BY MESSENGERS

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18823063

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18823063

Country of ref document: EP

Kind code of ref document: A1