Secure instant messaging

Secure instant messaging is a form of instant messaging. Both terms refer to an informal means for computer users to exchange messages commonly referred to as 'chats'. Instant messaging can be compared to texting as opposed to making the cell phone call. In the case of messaging it is like a short form of emailing. Secure instant messaging is a specialized form of Instant Messaging that along with other differences encrypts and decrypts the contents of the messages such that only the actual users can understand them.

Instant messaging background

Instant messaging has been around in some form or another for decades. Generally it is a process by which users on a computer network can quickly communicate with one another using short text based sentences rather than using email. Each user has a client piece of software that communicates with a common server that orchestrates the chat sessions. Instant messaging is similar in concept to texting rather than making the phone call. Over the years two distinct settings for the use of instant messaging have evolved.

The first would be the corporate or institutional environment composed of many potential users but who are all under the same organizational umbrella.

The second setting would be individual users ‘after work’ or at home who do not have a mission oriented commonality between them but more likely are family and friends.

In the first corporate setting security risks became apparent from the outset. What stops a disgruntled employee from messaging some sensitive company data to a colleague outside the enterprise? The reverse of that would be the example disgruntled employee downloading some virus or spyware onto his machine inside the corporate firewall to release as desired. Accordingly organizational offerings have become very sophisticated in their security and logging measures. Typically an employee or organization member must be granted a login and suitable permissions to use the messaging system. This creating of a specific account for each user allows the organization to identify, track and record all use of their messenger system on their servers.

The specialized requirements of the organizational messaging system however, run almost completely contrary to what an individual user may need. Typically non organizational use instant messengers advertise their availability to the Internet at large so that others may know if that person is online. The trend has been too that manufacturers of instant messaging clients offer interoperability with other manufacturer’s clients.

This competitive edge grew out of the heretofore use of proprietary communications protocols used by the client manufacturers. Compatibility between clients is likely to become almost universal as a unified messenger protocol the ‘Extensible Messaging and Presence Protocol’ (XMPP) is being adopted by more and more manufacturers. The XMPP has been at least in part been formalized by the Internet Engineering Task Force as RFC 6120, RFC 6121 and RFC 6122 which will further the trend towards instant messaging standardization.

For the typical social individual user this product evolution spells greater ease of use and more features.

Features of social instant messengers that are counter productive to security

• Presence and Status Broadcasting - Messengers attempt to maintain a social environment and always stay 'connected'.
• Interoperability – Many other manufacturers can interoperate with the example messenger.
• Contact Lists - Maintains lists of all desired contacts.
• Client-Server Design – Requires use of third party servers to provide chat functionality to messenger clients.
• Logs Messages – Messages and other events are recorded.

Security is more than content encryption

Certainly the contents of the messages must be understandable only to the desired parties but what of other behaviors or traits of instant messengers? Almost by definition alone a secure messenger cannot be a social messenger. Therefore to be considered secure a messenger must behave differently than a normal messenger in more areas than just encrypted vs. plain text message contents.

• A secure messenger must never broadcast its status or presence online.
• A secure messenger must not be able to send messages in clear text form.
• A secure messenger must never log or store any information regarding any message or its contents.
• A secure messenger must never log or store any information regarding any session or event.
• A secure messenger must not rely on third party servers for message security and handling.

Secure instant messaging is a form of instant messaging wherein at the very least the users are exchanging chat messages the contents of which they have caused to be encrypted with keys they generate and control.

Recent news events have revealed that the NSA is not only collecting emails and im messages but also tracking relationships between senders and receivers of those chats and emails in a process known as 'meta data' collection.

Although innocuous sounding the term 'meta data' that refers to the data concerned about the chat or email as opposed to its actual contents has been shown to something valuable to collect.

Therefore instant messengers that not only encrypt message contents but also offer a 'stealth' presence on the Internet will provide their users more overall security during chat sessions.

Secure instant messengers aren’t needed for every chat session but when there is a requirement for private, secure and untraceable messaging there is no other means to effect those requirements.

Table overview of secure messengers

Client Name	Open Source License	Without Central Server	Symmetric Encryption (e.g. AES, DSA)	Asym.: RSA	Asym.: NTRU	Asym.: ElGamal	Default Asym. Keysize	Max. Asymm. Keysize	Forward Secrecy	Multi-Encryption	Clientside Encryption	Encrypted Groupchat	Encrypted Filetransfer	Public Key not stuck to IP?	Proxy /Tor	Chat to offliners	TCP	UDP	SCTP	Serversoftware open source	Website
BitMail	BSD	Yes	Yes	Yes	no	no	2048	8192	Yes	Yes	Yes	Yes	no	Yes	Yes	Yes	Yes	Yes	no	Yes	http://bitmail.sf.net
Bopup	No	No	Yes	No	No	Yes	2048	2048	Yes	No	No	Yes	Yes	No	No	Yes	Yes	Yes	No	No	http://www.bopup.im
Chadder	No	No	no	no	no	no	?	?	no	no	?	no	no	no	no	no	Yes	no	no	No	http://etransfr.com/products.html
Chatsecure	GPLv3+ / Apache 2.0	Yes	no	Yes	no	no	1028	1028	Yes	no	Yes	no	no	no	Yes	no	Yes	no	no	Yes	https://chatsecure.org/
CryptoCat	GPLv3	No	no	Yes	no	no	1028	2048	Yes	no	yes	no	no	no	Yes	no	Yes	no	no	Yes	https://crypto.cat/
FireFloo	BSD	Yes	Yes	Yes	no	Yes	2048	8192	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	http://firefloo.sf.net
Folpy	GPL v3	Yes	no	Yes	no	no	1024	1024	no	no	Yes	no	Yes	no	no	no	Yes	Yes	no	Yes	https://bitbucket.org/folpy/folpy
GoldBug	BSD	Yes	Yes	Yes	no	Yes	2048	8192	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	http://goldbug.sf.net
Hemlis	?	?	?	?	?	?	?	?	?	?	?	?	?	?	?	?	?	?	?	?	http://heml.is
Kontalk	?	?	?	?	?	?	?	?	?	?	?	?	?	?	?	?	?	?	?	?	http://kontalk.org
Kik	No	No	No	?	No	No	?	?	?	no	?	no	?	yes	No	?	yes	?	no	No	http://kik.com
Myenigma	No	No	Yes	Yes	no	no	2048	2048	Yes	no	Yes	no	no	yes	?	Yes	TCP	?	no	No	https://www.myenigma.com
RetroShare	GPL	Yes	no	Yes	no	no	2048	?	no	no	Yes	Yes	Yes	no	no	no	yes	yes	no	Yes	https://retroshare.sf.net
SecuXabber	GPLv3	Yes	no	Yes	no	no	1024	2048	Yes	no	Yes	no	no	no	?	no	Yes	no	no	Yes	http://sourceforge.net/projects/secuxabber/
Sicher	No	No	Yes	Yes	no	no	1024	1024	no	no	Yes	Yes	Yes	no	no	Yes	Yes	no	no	No	http://www.sicherapp.com
Spot-on	BSD	Yes	Yes	Yes	no	Yes	2048	8192	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	http://spot-on.sourceforge.net/
Surespot	GPLv3	Yes	no	Yes	no	no	1024	2048	Yes	no	Yes	no	no	no	?	no	Yes	no	no	Yes	https://www.surespot.me
Telegram	No	Yes	no	Yes	no	no	1024	2048	Yes	no	Yes	no	no	no	?	no	Yes	no	no	No	https://www.telegram.org
TextSecure	GPLv3	Yes	Yes	Yes	no	no	2048	2048	Yes	Yes	Yes	Yes	Yes	Yes	?	Yes	Yes	no	no	Yes	https://whispersystems.org/#encrypted_texts
Threema	No	No	no	Yes	no	no	1024	2048	No	no	no	Yes	no	no	no	Yes	Yes	?	?	No	https://threema.ch
Waste	GPL	Yes	no	Yes	no	no	1024	1024	no	no	Yes	no	Yes	no	no	no	Yes	no	no	Yes	https://waste.sf.net
WhistleIM	No	No	no	Yes	no	no	?	?	no	no	No	no	no	no	no	no	yes	no	no	No	https://whistle.im

Table criteria description

The table above describes an overview of Instant Messenger Clients, which are sending the Message encrypted. For that, several criteria are to consider.

Open Source

Encryption algorithms must be transparent. For that, the open source status of the application is essential. Messengers, which are not revealing the source, must be trusted by the company, offering the messenger. To find flaws and failures in the code, only an audit of a community being able to look into the source can check, if the encryption implementation has been done in a proper way. In general it is recommended to not trust closed source encrytion.

Decentral Model

A messenger will fail, if a central server is closed or surveilled. For that decentral server architectures have been developed, either bei a peer-to-peer technology, or by open source chat servers, which can be set up by everyone. An architecture, where all the messages go not through a central server is a big plus in redard for security, because a one-stop-shop for surveillance is not as secure as if a decentral model is chosen.

Symmetric Encryption

Symmetric enrcyption describe a kind of passphrase, only both users know to decrypt the message. It is a hidden secret, only both participants know.

Alternatives in Asymmetric Encryption

Asymmetric encryption means, that both participants have a private and public key. The public key must be exchanged. A mathematical operation then encrypts the message with the public key of the receiver. Mostly the RSA Algorythm is used here. As it is based on not-solveable complex mathematical operations, the encryption might be regarded as safe. But what happens if the complex problem is soon a simple one? Better to not have only RSA as the only method in this regard, but also here some alternatives: e.g. ElGamal or NTRU. NTRU is regarded as secure even for quantumcomputing.

Key size

The key size describes the length of the needed mathematical operation. Simply spoken, the longer the key, the longer it takes to crack it. Today a key size of 2048 for asymmetric keys is recommended.

Forward Secrecy

Forward secrecy describes the option to change the encrryption key every session or even instant.

Multiencryption

Multiencryption describes several layers of encryption. E.g. you can add a symmetric encryption within an asymmetric encryption, the ciphertext then is locked once more with an additional password.

Clientside Encryption

The encryption key must be stored on the device of the user, not on a remote server in the web. Also the plaintext should be processed to ciphertext on the device of the user. It must happen in his hand, not on a remote server.

Groupchat and Filetransfer

Some Messengers offer Groupchat and Filetransfer. These features as well should transfer only encrypted bytes.

Key not stuck to IP?

Public keys are used to identify users. A user's IP address can in some cases be related to his or her public key. Messengers that do not relate the user's public key to the user's IP address are considered more secure. This offers more security because the IP cannot be targeted to gain access to the private key. If an attacker knows the IP related to a public key, he or she can try to get on the remote machine, download and decrypt the private key and thus decrypt all encrypted communication.

Proxy

Proxies and Tor might help to have the own IP not related to the public key.

Chat to Offline Users

Messengers without a central server need special means to be able to message to friends, which are offline. This is mostly done by storing the messages in other online friends. As this is a quite convenient feature, some messengers offer this in an encrypted way too.

Transport protocols

Not all messengers support the most given transportprotocols like TCP, UDP and SCTP.

Chatserver open source

As some Messenger need a central server, the source of this chat server need to be published, to be transparent and auditable as well for this bridge, a message takes. Here as well as for the client the claim should be, that this part of the software should be open source as well.

See also

• Comparison of instant messaging clients