Safemsg

Safemsg: secure message exchange system with self-destructing messages and client-side encryption.

Why is Safemsg the best choice for security?

So, why is Safemsg better that other secure message exchange systems? Let us give you two good reasons why trusting a system based on "self-destruction" may be a wrong choise:

• In conventional secure message exchange systems, messages are dispatched (over SSL) to the server that stores them until they are requested, when they are forever deleted from the server and after that moment cannot be accessed again. But what if someone hacks into the database of the server? That's right, they will acquire access to your messages.
• What evidence do you have so as to trust a secure message exchange system? Is it likely that somebody eavedrops into your conversations? Is it possible that your messages are logged server-side? So long as messages are stored unencrypted in the server's databse, one may malevolently peek into them...

So, why choose Safemsg?

With Safemsg, messages are encrypted client-side and the server has zero-knowledge about the message. Furthermore, Safemsg is open source, so anybody can inspect the code and point out to possible security holes. You are also free to download and install Safemsg on a server of yours so long as you attribute the original software and you don't make profit out of it (Safemsg is licensed with the GNU GPL v2 licence).

Features

Safemsg is a secure message exchange system which can be used to exchange passwords and other confidential data. SafeMessage has the following features:

• Is web-based and there is no need to install anything on your system,
• Messages are encrypted client-side, so the server has no information about the original message,
• A REST interface allows users to store message on a remote server,
• Once a message is read, it is permanently removed from the server's database,
• The whole system is completely open-source.

A running instance of Safemsg is available at www.jaqpot.org/safemsg

How Safemsg works...

Let's say that peer A needs to communicate a password, say 'abcd' to peer B. This is how SafeMessage works. First, peer A creates a SafeMessage:

• Peer A encrypts the message locally using a key X,
• Peer A POSTs the encrypted message to the server which responds with the URI of the created message,
• Peer A sends the key and the URI of the message to peer B,

Then, peer B fetches and decrypts the message:

• Peer B fetches the message using its URI and
• The message is permanently destroyed on the remote server,
• Peer B decrypts the message locally.

In case someone intercepts the communication of A and B and reads the message, then, when peer B attempts to read the message, they will realize that the password has been stolen and proper action can be taken. However, even in that case, the only information that has been revealed by the server is the encrypted message and not the actual one (which is not known to the server). Necessary conditions for very high security are:

• The key is used once and is then discarded (one-time pad),
• The key is random,
• Nobody is able to acquire access to the key, i.e., the two peers have to be extra cautious when exchanging the keys.

Using the API

To create a safe message, the client applies a POST as follows:

HTTP/1.1 POST /register.php

specifying the parameter msg which is the encrypted message.

Possible status codes are:

• 200 - Success, the message was stored and its ID can be found in the response body,
• 400 - Bad request. Most probably because no message was specified,
• 500 - Internal server error explained in the response body.

Here is how the response of this request looks like:

{
    "response": {
        "id": "24cb14d1-922f-425f-9fad-55626ef26be7-vuQ4pn9q",
        "created": 1419044972
    }
}

in this JSON document, the field id refers to the identifier of the created message, while created is the creation timestamp (server-side) of the created message.

The following parameters can be specified for additional security features:

• msg, the message to be created,
• bind_ip[], reveal the message only if peer B accesses if from one of the registered IPs. Any attempt to access the message from some other IP will destroy it. Notice that there are numerous ways for someone to fake an IP address, so this is not a very reliable security measure.

To retrieve the message, the client applies a GET as follows:

HTTP/1.1 GET /retrieve.php?id={id}

where {id} is the identifier of the message which the client wants to retrieve.

HTTP status codes are:

• 200, success: the (encrypted) message is returned in the response body,
• 404: the identifier of the message is wrong, or the message was previously deleted. No information is provided as of whether the requested identifier was previously registered.
• 500: internal server error, e.g., database connection error.

User interface

A web-based user interface is provided in which Javascript is used in a second security layer where messages are encrypted locally (client-side) and are POSTed to the server in an encrypted form. The client who creates the message is given a link (URL) of the generated encrypted message and a key that is used to decrypt the message. Peer A needs to give to peer B both the link and the key to access the message.

Two access points are provided for this reason:

• /create.php: where a new message can be created,
• /see.php?id={id}: where clients can access messages provided that they have the key.

Links

Limitations of Safemsg

Safemsg provides a high level of security against various types of threats. However, you should mind that:

• Safemsg does not provide any sort of anonymity and your identity can be traced unless you use some anonymisation system like Tor. Safemsg does not in any way mask or hide your IP address,
• Safemsg implements a symmetric encryption system where the two peers must share the same key, so both peers have to take good care of the key.
• Safemsg cannot protect you from key loggers and other malware,
• Safemsg cannot protect you from screen scraping (people standing behind you, hidden cameras etc),
• Safemsg cannot protect your from untrustworthy peers. Exchange confidential information only with people you can trust.