Tag Archives: cryptography

Keeping it private – part 2


So in the last post we described the setup of the app and how it starts off on its journey to build a private channel.  To quickly recap, the phone now has a public/private keypair, a secret key that you’ve exchanged with the system and the system has got your public key and knows it’s from you, which gets stored in our directory ready to give it to anybody else who asks.

The next step is to build a private, encrypted channel between you and your friend.  The first step is to get their public key, so the app asks us, what the registered public key is for your friend[1].  We give that to you using the private channel between you and the system and we sign that response, so you know the public key comes from us not to mention coming back over our shared secret channel[2].

You then generate a channel name (a friendly name, usually the persons name), channel id and a new secret key, the app bundles this up in much the same way as it did when it started to talk to the server.  The bundle of data, including your public key is encrypted using your newly generated secret key and then your secret key gets encrypted with your friends public key.  You also sign this entire packet.  The phone then sends that to us.  We do a few things to just double check that this message is from you.  Firstly it has to come over our shared secret channel which we know is from you and secondly the digital signature on the channel message (which we’ll forward on) has to be signed by you[3]. If that’s ok, we send it on to your friend.

When your friend gets your message, the first thing they do, is get your public key from the server.  They then check the signature on the negotiation message to make sure that it really has come from you.  If it isn’t, the throw it away.  They then decrypt the first part of the message using their private key.  In this part is the secret key that you are going to use to chat with each other.  They then send an acknowledgement message to you, encrypting that message with their secret key, signing it with their private key[4] accepting the channel.

So what have you got now?  You have now exchanged a secret key with your friend that we the system haven’t seen, in a way that makes your sure that you’ve exchanged that key with who we say it is.  You can now chat away, with us forwarding your messages knowing that nobody in the middle can read your messages or impersonate your friend.

We’ll start to explore how the app detects if we’re messing with the public keys that we’re publishing, in the next post, when Mars attacks.

[1] This is to ensure that you don’t get sent a different public key in the message at face value asserting to be from a specific phone.

[2] Some might wonder what the point of signing the message is if it’s coming from the server over our shared secret channel which we’ve already authenticated.  This is a practical measure for security.  Secret keys must be available to the server processes to wrap and bundle our messages and anything we forward to you from others.  That means if a front line server is compromised somebody could start to impersonate us on that server fairly easily.  Our private key on the other hand is kept well away from the front line machines in a processes not on the same network directly connected to the servers terminating chat connections.  If we can afford it, we’ll use a hardware security module.

[3] This proves that someone hasn’t just managed to obtain your secret key (say from us) and that you have access to your private key still, the other half that we’ve authenticated and hold.

[4] Lastly, to close the loop on the protocol, the far end signs the acknowledgement.  Now notionally this isn’t actually necessary as you’ve encrypted your secret key with their public key so if they’ve decrypted it (and sent you a message back) you can assert they’ve got their private key.  That’s all well and good for single user channels but that isn’t so easy when you want to have multi-person chats with a group of friends.

Additionally: Private key operations are expensive, they take lots of processing power and that in turn eats battery life.  We use them for critical parts of the protocol but not everything all the time.