How messaging works

M2 sends messages directly between the users leaving out by default the normal in between messaging servers.

Peer to peer

The result of this peer to peer design is that any users activity logging is removed from possible third party. The only logging that can be performed is on the PC or phone of the party using the apps.

peer-to-peer-communicate

In general computers on the Internet communicate Peer to peer, but most messaging services uses in-between servers for handling the user connects and look-up, messaging queues, message send and receive to and from all parties. Thereby also user activities and information about who are talking to who can be potentially logged. In m2 this is removed and are handled directly in app on user PC or phone.

See also:

Encryption

Both content and meta-data are encrypted in m2. (Meta-data are the information about who are involved in the communication). Encryption are secured by a key exchange procedure that ensures only the intended parties are able to read it’s messages.

The key exchange procedure is like this:

  1.  A public/private RSA key pair is created.
  2. The app sends the public part of the RSA key to the other party.
  3. The other party creates a AES key and encrypt this key with the received public RSA key.
  4. This party sends the encrypted AES key back.
  5. The received encrypted AES key is de-crypted with the party private RSA key.

Both parties do this procedure against the other party. When both parties have received the other party AES key, conversation can start. The parties then use each others AES key to encrypt data sent to the other party.

Three levels of encryption

Users certificates

Message contents are encrypted using a AES 128 key and the receiver’s RSA 4096 public key is used for encrypting the message AES key. (see key exchange procedure) This first encryption, using a user certificate with public key, ensure that only the intended receiver can ever read the message content.

Encrypt peer to peer session data flow

The total data flow are encrypted on session level with fresh keys for each session. This session encryption secures both content (once more) and meta-data between the communicating peers. Session encryption uses AES 128 to encrypt the data flow and a session generated RSA 2048 private/public key for lock/unlock the AES keys. (See key exchange procedure)

Packet obfuscation

Data packet’s (Internet UDP packets) are encrypted individually with a single key to obfuscate meta-data and instructions contained in the packets. Not a real full size encryption, but to potentially confuse outside tracking of m2 traffic and make the data flow less readable for analyses.

Except for the IP address in the UDP packets (sender and receiver IP address), nothing meaningful can be extracted from the communication flow after this encryption procedures.

Offline support

Although m2 is a peer to peer based system, messages can optionally be sent between parties via offline in-between servers. Both parties must agree for this to happen.

This functions are supported because peer to peer require both parties to be online at same time for successful message delivery. For in-frequent users, the delivery stability suffer when only peer to peer are supported. (Users are not online at same time) Offline messages are still encrypted end to end and messages stored on the offline servers.

No link between sender and receiver are stored on the offline servers. Only the global hash identity of the receivers are readable. The identity of the sender is concealed inside the encrypted message. The offline services, (normally us), will not be able to inspect from whom or whatever content a message contain, and the servers also delete any message when delivered or within a time-frame (7 days) if not delivered.

IP address protection and use of middle-man

The information left in an encrypted data packet stream are the IP address information about who computer send and who computer receive.  In many cases this is valuable information in order to discover who are involved in sending information to each other.

If someone using m2 like to avoid this type of potential discovery, the communications can be set to us a middle-man proxy. The only purpose for this proxies are to remove the information about from whom to whom are the data packets are traveling. See blind middle man proxy