security and usability: message encryption

Recently I began to do a bit of research on security and usability in order to make it a little project for students to work on. I was well aware that the most secure system is not effective if people can't use it and that security (lets say: a very long password) and human preferences (a rather short one if at all) are not matching. However I was amazed how big the problems are.

First I was looking at message encryption. It seemed the most likely scenario: Write something that only you and a particular other person should see in plaintext. Well known for archiving this is PGP. During the recent revelations about the NSA’s  practices (time of writing: Oktober '13)  Crypto-Partys were flourishing all over the place and teaching people how to use PGP was seemingly the way out of the trouble. But as far as research and my personal experience is concerned it leads to another problem: the one of using PGP. Ina classic study on PGP it took the participants quite a long time to get encryption working, several people broke the security by sending their private, secret key by accident. Security Guru Bruce Schneier says: »[My tips for online security] are not things the average person can use. […] Basically, the average user is screwed.«

I started to look at an alternative method for message encryption: Off-The-Record-Instant-Messaging. The protocol is designed with usability in mind (and there is a little paper on the topic) . You don’t need to manage keys by yourself, authentication works via a answering a question and the like. However, I still run into problems: To negotiate keys you both need to be online, so just sending an encrypted message into the blue does not work; To tell somebody that »encryption works but, let’s authenticate« results in a »WTF?« on chat (if you get your non-nerd-friends to play the game that far).

And despite of some background knowledge I myself am still confused about keys and their management– and that is just the part which has some interaction with the users: Which keys may be exchanged, which may never be exchanges and which are… whatever, it is complicated and it is no wonder that the mental model and the actual system diverge. (You get in contact with keys even on OTR if you can’t use the authentication-by-shared-answer [added])

What works probably fairly well is locking data via a password and unlocking it (Though I have no empirical study on the subject).  The user’s likely mental model of a locked box matches the one of the system fairly well. And that box is not some mysterious whatsoever but a file, something that most users will know. If they send it, the password needs to be shared via a second channel – but that’s it. But for sending many messages it is not very comfortable.

So encrypting messages is rather difficult, and even a relatively usability-aware protocol like OTR is noticeable less easy to use than plain text. To say that this is how it is and that one should RTFM is no solution. In general, because than, every unusable thing could be justified with that. And, more specific, because if only those who have something to hide encrypt, they are easily spotted and if one side can use encryption, but it seems to much for the other, both will stay without.

Update 05.11.13: Spelling and typo. Key management on OTR clarification. Link to the definition of a crypto-party,