Current distribution of WhatsApp alternatives [Update]

Many people are discussing alternatives to WhatsApp right now. Here I just track how many installations the currently discussed, crypto-enabled alternatives have according to the app store.

WhatsApp was already bad before Facebook acquired it. But at least now people woke up and are considering secure alternatives. Yes, this move could have come earlier, but I do welcome the new opportunity: its the first time wide spread encryption actually has a chance in the consumer market. So for most of the people out there the question is more “which alternative should I use” instead of “should I use one”. Right now I do not have the faintest idea which alternative with crypto support will make the break through – but you could say I am well prepare.

Screenshot installed instant messengers

Well – that’s obviously not a long term solution. Thus, to shed some light on the various alternatives and how they stand right now, here is a quick statistical overview:

Secure Instant Messengers, state updated 2014-03-11
Name	WebPage/GooglePlay	installed devices	Ratings	Google +1
ChatSecure	Website / Google Play	100 000 – 500 000	1 626	2 620
Kontalk	Website / Google Play	10 000 – 50 000	237	265
surespot	Website / Google Play	50 000 – 100 000	531	632
Telegram	Website / Google Play	10 000 000 – 50 000 000	273 089	97 641
Threema	Website / Google Play	500 000 – 1 000 000	9 368	12 594
TextSecure	Website / Google Play	100 000 – 500 000	2 478	2 589

The statistics are taken from Google’s Android Play Store. I would love to include iTunes statistics, but it seems they are not provided via the web page. If you know how to gather them please drop me a note and I’ll include them here.

These numbers just help to show how fat an application is spread – it does not say anything about the quality. For example Threema is not Open Source and thus not a real alternative. So, if you want to know more details about the various options, please read appropriate reviews like the one from MissingM.

Thoughts on crypted communication

Due to the recently published information about mass surveillance on a yet not known level right now the question remains how to encrypt communication. I had some thoughts regarding that topic involving a GPG like web of trust combined with user friendliness which I’d like to share here.

Given everything which was published so far, un-encrypted communication is not save at all. The same is unfortunately true for encryption methods which rely on encryption provided by the servers of some organization. If there is a centralized organization storing the keys for you, or just providing you with the encryption technology, you are screwed, because the intelligence agencies will force them to cooperate. For that reason, the encryption must take place on the end users system already (and the software must be Open Source).

However, if you have end-user encryption, you have the problem of the key exchange – if two people want to communicate securely, they need to exchange the keys or at least securely verify that a public key indeed belongs to their private key. That only works if they meet in person – or if there is a web of trust.

A common example of such a web of trust is the GPG web of trust: people who have properly verified that person A belongs to key M sign this key. If person B trusts person A, it can just use key M since it is already verified by person A. However, in case of GPG the web of trust never reached mainstream. It is mainly used by technical minded people. Most users never got used to it.

So, from what I can tell the only chance to establish a web of trust is to hide the technical details as much as possible from the users. The same is true for the actual key exchange – it needs to be as simple as possible so that each normal user can use it.

Given this background I would suggest the following solution at least for mobile phones. You download the app, and it asks the user for a password. In the background, a key pair is generated and secured with the password, and all data stored on the device are encrypted using the public key. If user A meets user B all they need to do is pressing a button in the app, and a QR code is shown. The other user scans that QR code, and its done. The user shows up in the contact list, and they can chat. In the background, the app extracts the key ID and fingerprint from the QR code, downloads the public key, signs it and uploads the signature automatically.

The biggest problem comes up when user C comes into play, wants to communicate with user A, but they both have no common connection in their web of trust. They would have to meet – or use some other way of exchanging the data securely. A simple way would still be to talk on the phone, but that never worked for GPG. So some kind of web service to host their QR code for a short time only would probably a solution, although it would be pretty risky.

To lower the danger of a man in the middle attack in the above given web example the key servers must only accept one key pair for each identity, which is different to the way GPG works. That would in fact mean that you can have each login only once – if you loose your key, your are screwed.

One question though remains: how many steps in the web of trust are still trustworthy? I guess that could be left as a configuration option if, and only if, a user wants to modify that.

To summarize: I guess that the current cryptography technologies we have could really help to establish secure communication. But to really bring that communication to the masses we need easy-to-use (read: your grandma!) applications doing everything in the background.

Pass – A perfect shell based password manager

Pass is a tool to store and manage passwords and other data securely and on command line – even with built in support for Git and remote Git repositories. Thus it is a welcomed alternative for existing password managers which often require a GUI, or do not provide repository support.

What it is

Pass is a shell based password manager to store passwords and login data – or anything you want, actually. The name “the standard unix password manager” however is pretty misleading: the author wanted to stress that it only uses standard Unix tools, but failed to highlight that with a catchy name and instead just created confusion.

But the author is right with his main point: pass is in fact just gluing together already well known and tested Unix tools: the encryption of all information is ensured by GPG, passwords are queried using gpg-agent, the version control and remote repository support is done by Git, and the tool itself is written in shell code. Thus you have features you can rely on – in fact, if you want you can directly access the Git repository and the Gnupg files, you do not have to use Pass at all.

Pass stores information in simple files, which can be grouped in folders. While the main idea of Pass is to store one password in one file you can actually access each file with editors to store as many information in it as you want. Each file is encrypted with the gpg key which was defined during the initial setup of Pass. As a result the Pass database is nothing else but a folder full of other folders and gpg encrypted files:

$ ls -1 $HOME/.password-store
business
commerce
financial
$ ls -1 $HOME/.password-store/business/
linkedin.com.gpg
example.com.gpg
important.com.gpg

Pass is included in all major distributions like Fedora, Ubuntu, Debian, and so on, and thus can be installed with the usual package management tools.

How it works

If you call Pass without any further options, it just outputs the content of its password store:

$ pass
Password Store
|-- business
|   |-- linkedin.com
|   |-- example.com
|   `-- important.com
|-- commerce
|   `-- amazon
|-- financial
|   |-- badbank.com
|   `-- mybank.com

The file type ending “gpg” is not shown here to not confuse users (I guess).

Showing the content of a file is straight forward:

$ pass business/example.com
login:  example
pass:   password

Adding new entries can be done with the command pass insert $FOLDER/$FILENAME. But it might be more convenient to just use the default editor to edit a new file: pass edit $FOLDER/$FILENAME. That way multi line information can be added more easily.

However, the real strength of Pass is that after each change – like adding a new password – git-add and git-commit are called: the new file is automatically committed to a local git repository:

$ pass edit business/example.com
[master 4c09c76] Added password for business/example.com using /usr/bin/vim.
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 business/example.com.gpg

As a result all changes are automatically under version control and can be reverted. But it gets better: Pass forwards arbitrary options and commands to Git itself. Thus it is possible to access the full functionality of Git – and to push the files to an online repository:

$ pass git push
Counting objects: 6, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 823 bytes, done.
Total 4 (delta 1), reused 0 (delta 0)
To git@example.net:pass
   aa2aff7..2011296  master -> master

That way the password store can be shared with any remote Git repository – and thus can be re-used by other clients, given that they have the proper GPG key.

Missing pieces

As shown above Pass is almost perfect if you need a way to manage passwords (or any other data at all) on command line level, including repository and encryption support.

But while Pass replaced all my other password managers literally in a few minutes there is still one big feature I miss: the support for GUI tools! It would be nice if Pass support could be included in the major Desktop Environments and major GUI programs used in the Linux desktop world:

• KDE’s Kwallet
• Gnome’s Keyring
• Android
• Firefox
• Chrome/Chromium

To summarize it: Pass is great, but would be even better if it could server as a backend for the usual GUI tools and desktop environments. There is already an experimental iOS client, so there is at least hope for an Android client…