MITM Protection via the Socialist Millionaire Protocol (OTR-style)

Crypto disclaimer!  I am NOT a crypto expert. Don’t take the information here as 100% correct; you should verify it yourself. You are dangerously bad at crypto.


The problem

Man-in-the-middle attacks are a serious problem when designing any cryptographic protocol. Without using a PKI, a common solution is to provide users’ with the fingerprint of exchanged public keys which they should then verify with the other party via another secure channel to ensure there is no MITM. In practice, this is a very poor solution because most users will not check fingeprints and even if they do, they may only compare the first and last few digits of the fingerprint meaning an attacker only need create a public key with the same few first and last digits of the public key they are trying to impersonate.

The solution

There’s no good protection from MITM, but there is a way to exchange secrets without worrying about a MITM without using a PKI and without checking fingerprints. OTR (off-the-record) messaging utilizes the Socialist Millionaire Protocol. In a (very small) nutshell, SMP allows two parties to check if a secret they both hold are equal to one another without revealing the actual secret to one another (or anyone else). If the secrets are not equal, no other information is revealed except that the secrets are not equal. Because of this, a would-be MITM attacker cannot interfere with the SMP, except to make it fail, because the secret value is never exchanged by the two parties.

How does it work?

As usual, the Wikipedia article on SMP drowns the reader with difficult to read math and does a poor job explaining the basic principle behind SMP. Luckily, there are much better explanations out there. The actual implementation of it is, unfortunately, just as convoluted as the math. The full implementation details can be found in the OTR protocol 3 spec under the SMP section. Below is the basic implementation of the protocol as defined in OTR version 3:

Cryptully: Simple Encrypted Chat

Back in May I started a project with the goal of allowing simple chat (instant messaging if you will) between two people, except that everything was encrypted. The original goal was not to reinvent the chat program, but rather make a chat program with a very specific purpose: quick, encrypted chat between two people. Why? There are more chat clients that anyone can count out there and a similar number of them are encrypted. The problem is that few people use encryption and setting it up is a pain. The user has to install software and configure software. This does nothing but deter the user from using any type of secure communication. I set out to create a simple chat client with the following goals:

  • All messages are encrypted.
  • Easily accessible to everyone.As in, no knowledge of crypto required.
  • Cross platform; it should run on Linux, Windows, and OS X.
  • No software to install and no user accounts to create.
  • Just bare bones chat with a minimal interface. Nothing fancy here.
  • Simple enough that the code could be inspected by anyone who is curious to verify nothing suspicious is going on.
  • Ability for users to host their own servers if desired.
  • Open source (of course).

After a few months and iterations of designs and chat clients, I’m very happy to say that I’ve accomplished all those goals. Here’s what the finished product looks like:

It’s called Cryptully and it’s a basic encrypted chat program. The only cryptography the user needs to know is how to check a public key fingerprint and that is explained as simple as possible (read these numbers, if they match, everything is fine). Further, binaries are available for download where all the user need to do is download and run. There’s no dependencies to install or accounts to create.

Cross-platform deployment of Python applications with PyInstaller

A primary goal for my Cryptully project (an encrypted chat program) was to make a desktop application accessible to as many users as possible. Nothing annoys me more than wanting to use a service or program and having to install a program that I’ll just uninstall later or having to create an account. I’m a big proponent of making the barrier to entry to using a new service as low as possible. Since the nature of my program (cryptography) did not warrant a web application, I was pushed to the desktop. The desktop isn’t exactly known for getting something up and running quickly verses just going to a website. This led me to want to accomplish the following for my project:

  • Build and run on Linux, Windows, and OS X
  • No need to install any software
  • No user registrations

With that in mind, I selected the language and libraries that would facilitate that goal. This led to:

  • Python
  • QT
  • M2Crypto
  • PyInstaller

Python for cross platform development was a natural choice as was QT. I’ve found that QT has some nuances with presentation of my application on OS X, but the fact that it worked exactly as intended on Linux, Windows, and OS X was extremely impressive. This allowed me to get my program running on all three OSs, but it wasn’t user friendly, even for a developer. Windows, for example, required the installation of Python, PyWin, PyQt, M2Crypto, and the Visual C++ Redistributable Package. Hell, it took me a few hours to get all those installed and working correctly and I wrote the program. How could I package everything into a single binary file?

In comes PyInstaller.

Contacts WebAPI for Android Example

The first project I was given at my internship at Mozilla this summer was to implement the Contacts WebAPI for Android. This means it’s possible to create, update, view, and delete the contacts on an Android device through the web on Firefox for Android.  Of course, a user has to explicitly allow a webpage access to his/her contacts before Firefox goes anywhere near the contacts.

The Mozilla wiki has some simple examples of how to use the WebAPI, but I quickly threw together a more complete example. The tarball linked below is a collection of basic HTML files that demonstrate the functions of the contacts API in a hopefully straightforward way. Not all of the possible contact fields are present for the sake of page size (and my time), but the others, as documented on the Mozilla wiki, are trivial to implement.

Why did no one tell me about \x08?

For years I would occasionally run across a program that would display a little ASCII art rotating bar to show it was working and each time I wondered how it was writing to what I assumed was standard out, but replacing previously written characters. Not sure what I’m talking about? It’s best to just show a video since I’m not sure there’s a name for it.

Part of the problem is that I didn’t know what it was called so it made searching for it quite difficult. Of course, this type of effect can be achieved with Curses, but there’s no need to bring in a big library for something that’s so simple. Well, it all comes down to \x08. That’s the C escape code for the backspace ASCII character (like hitting the backspace key on your keyboard); or if you prefer, \b will work just fine too. It does as its name implies, writes a backspace which removes the previous character from the stream it’s written to. In this case, we can use it to print out a character, wait a little bit, backspace that character, and then print another in it’s place and so on to achieve the effect above.

Here’s a little C program to do just that put into the form of a nice function that would be useful in a real program. It would probably be better to put it in its own thread while the main thread does the work (or vice versa), but you get the point from the example below.