End-to-end security

When talking about real security, it’s important to keep track of where the security starts and where it ends. Most people these days have heard of encryption, and many might know what the locks in the location bar in browsers mean. And many might also assume that most of our communication must be encrypted these days. And that is true, to some degree. Most of our connections to servers will be encrypted in one way or another. The transport of data is usually somewhat protected. But the content, from sender to receiver, is a different story. You can see this most obviously in the case of email, where we use protocols like SMTP, IMAP and POP3 to communicate with mail servers - and that mail servers can use to communicate with each other as well. When your computer talks using SMTP and IMAP with a server, that connection will almost always be encrypted. When a mail server talks to another mail server using SMTP, it will also sometimes be encrypted. So, some of the jumps are encrypted. But inbetween, when the data moves through the mail servers, the data will not be encrypted. And when it arrives at the receivers machine, it won’t be encrypted either.

The same thing is true for many chat protocols. As seen in the section about transport security, CoyIM will use a secure connection to the chat server - including trying to upgrade the connection to use advanced Tor features to secure the transport even more. But when you send a message to a person, just as with email, any server inbetween can read that message.

In the case of email, the two most common solutions are called OpenPGP and S/MIME. These make it possible for a sender to encrypt a message to a specific receiver, and also to sign it in such a way that the receiver can be certain that the sender is who they claim to be. For CoyIM, we have chosen to use a protocol called OTR. This is a protocol that allows you to add encryption and signing to any chat protocol. There’s nothing specific about OTR that ties it to XMPP. We use our own implementation of OTR, called OTR3.

OTR is composed of three different interlocking algorithms. It uses a version of a protocol called SIGMA for the key exchange. It uses a ratcheting protocol for sending and receiving data. And it uses the a zero-knowledge proof of knowledge called Socialist Millionaires’ Protocol (SMP) to authenticate that you are talking to the person you think you are talking to. Together, these three protocols provide several important security features.

Several lower level primitives are composed to create these three algorithms. For long lived identity keys, OTR uses the DSA algorithm, with a 1024 bit modulus and a 160 bit q value, which gives a rough security level of 80 bits. OTR generates new ephemeral public and private keys using the Diffie-Hellman algorithm. These keys are generated and manipulated over the prime field defined as Diffie-Hellman Group 5 in RFC3526. This prime is 1536 bits, which also gives us an approximate security level of 80 bits. Diffie-Hellman is used both in the initial key exchange, but also during the ratcheting protocol. For symmetric encryption, AES-128 is used with the CTR cipher mode. Finally, SHA-1 is used to generate fingerprints, and as part of HMAC constructions, while SHA-256 is also used for hashing and HMAC construction.

The AKE - the authenticated key exchange is responsible for doing an initial key exchange of new, random keys. Once that is done, the DSA long lived keys are used to sign this key exchange, which provides for authentication. The key exchange itself is not deniable. You can prove to someone else that you talked to a person. However, the actual content of the conversation will be deniable.

The ratcheting protocol that is used to actually send and receive information works by continuously doing new key exchanges while mixing in key material from the previous iterations of the ratchet. The way this is done means that if an attacker gets hold of keys in memory at any single point in time, they will not be able to decrypt future conversation (from the point of the next ratchet), since new keys will be generated and exchanged. This security property is known as post-compromise security. The OTR ratchet also generates new keys for every message by hashing the key material used previously. It then throws away this old key material. What this means is that the ratcheting protocol provides forward secrecy as well. This security properties means that if an attacker gets hold of your current key material, they can’t use that to decrypt previous messages. Finally, each message will be encrypted using AES-128 with the CTR cipher mode. A MAC will then be computed over the message and sent together with it. It might seem strange to use this custom combination of a cipher mode that easily can be attacked with a separate message authentication. However, this is precisely the point of this construction. After a message has been sent, the MAC key for that message will be sent back by the other party in the clear. Since the CTR mode makes the cipher text malleable, someone inbetween could in theory modify the cipher text - without being able to read the message - and then generate a new, valid MAC for the modified message. This is one way in which this method gives deniability. Basically, after the fact, you can’t be sure that the message was not modified, so it can’t be used as proof. The other mechanism for the deniability is that both sides always have the keys necessary to write a message. In this way, the other party could never prove that they didn’t fake a message from another person. Together, these two features make the deniability of OTR quite strong.

All in all, the OTR messaging protocol provides for a range of security properties, which together gives its users a level of security and privacy unmatched by other protocols. The idea of the protocol is to regain the same kind of security you get from having personal face-to-face conversations without any recording equipment.

The implementation that CoyIM uses for OTR is called OTR3. It is written in the Golang programming language, which reduces the risk of security vulnerabilities. The library has also been audited, which we will cover in a following section. One aspect of the implementation of OTR which we are very proud of is that it is actually constant time. In most cryptographic implementations, operating on different keys will vary by small amounts in the time taken, or the energy used. While this might seem like an academic vulnerability, it has been used in real world attacks. A constant time implementation means that all operations on secret data is done in such a way that it takes exactly the same amount of time, no matter what that secret data is. As far as we know, the OTR3 library is the only constant time implementation of OTR in existence, and this provides a significantly improved level of security for CoyIM.