I am still on the quest of looking for an instant messaging solution that is secure, privacy-preserving, cross-platform and works in China. In my last article, we looked at how to use Matrix. While it works, it is unsuitable for laymen. With features such as chat rooms, it is aimed to be an alternative to Slack rather than a personal instant messaging application. People who I have asked to try it have expressed confusion.
Other alternatives exist, but they have their own problems.
Wire, basically a Signal clone (server side is written in Haskell and Rust which is a plus in my book), depends on GCM at the time of writing, which is not available in China.
Conversations (XMPP+OMEMO) does not do E2E encryption (OMEMO) by default. Moreover, the iOS counterpart ChatSecure is not in the Chinese App Store because it has a proxy functionality.
Today’s topic is Threema, which does not have the problems mentioned above fortunately. However, its encryption algorithm is different from the apps above, which all use the Double Ratchet Algorithm. The Threema protocol (described here) is much simpler. It consists of two layers, the transport layer and the E2E layer. The E2E layer happens between clients, it simply uses the “Box” API from NaCl where the shared secret is generated using ECDH. The shared secret is kept long-term and used for encrypting all messages between two parties. The transport layer happens between client and server, it is like a simple TLS with certificate pinning. A new temporary key is generated whenever the client restarts, which gives us forward secrecy, for a weak adversary.
While the protocol is simple, which is a great advantage since fewer things can go wrong, it does sacrifice some security, namely in the forward secrecy department. Consider a strong adversary, which can eavesdrop on the messages between client and server, i.e. it breaks the transport layer confidentiality. In the Double Ratchet Algorithm, which guarantees forward secrecy on the E2E layer, almost every message is encrypted using a different key. Thus, if the adversary finds a key, its not likely that he is able to recover many old messages. In the Threema protocol, if the shared secret is leaked, then the strong adversary can recover all old messages. Threema argues that: “The risk of eavesdropping on any path through the Internet between the sender and the server, or between the server and the recipient, is orders of magnitude greater than the risk of eavesdropping on the server itself.” The statement, I believe, depends on the country which the service is operating in. If it is operated in a country where the government can easily listen into the transport layer with a gag order, then I probably would not consider Threema a good choice. Fortunately, it is operated in Switzerland, which is known for its strong data protection laws.
With the GFW in play, while not perfect, Threema appears to be the best we can do so far. In the future, I hope the forward secrecy aspect can be improved and parts of it can be open sourced.
Update (November 8, 2017):
After further testing, it appears that not all functionalities of Threema work. Threema uses three servers, chat server, discovery server and media server. The discovery server is responsible for adding/finding contacts and its address I believe is api.threema.ch. Unfortunately, that address is blocked by GFW using DNS poisoning, we can see a report on GreatFire. On the other hand, the chat server appears to be working. Hence, to use it, one must add contacts over a VPN or while overseas.
Update (November 21, 2017):
I was in contact with the Threema support team and they confirmed that DNS poisoning was happening. On the other hand, they informed me that Threema Work still works in China (later confirmed by me) and generously gave me a free copy of the basic version. I suspect China did not block it because it is an enterprise product, but we will never know.