Traditional IM (OTT), SMS, etc. communications send messages in "plain text". This means that the information is sent without anything done to protect the information from being read by anyone else. It is akin to sending a postcard.
Imagine you are on vacation in Italy, Florence to be precise, and you send a postcard to your sister in London. As the postcard travels anyone that touches it can read it. Typically you do not send information like a credit card number or your pin number or an intimate thought using the postcard format. Today this is what sending an email or a text message or an instant message or a picture is like. The message is the postcard which travels along many hops until it reaches its destination. At every one of these "hops" the message could potentially be read.
For example you, are reading an email at Starbucks. To read this email the information travels from the server (gmail) through their (Google's) ISP, to Starbuck's ISP, to the Starbucks location you are at. At any one of these points the email can be read. To illustrate this we can run the traceroute command which shows the hops your data is taking to reach its destination.
We can see that to get to Google's server at mail.google.com, the data is being routed through at least 11 hops, anyone of which could have a chance to intercept the information. Now if you controlled the routing and could make the data on your network always pass through a certain one of these hops, you could monitor all of the “plain text” data being sent on your network. Not exactly "secure".
You may have seen at times when you used your web browser that the URL was pointing to https:// instead of http:// and there was an associated padlock icon or similar. This indicates that the connection is being made using SSL or Secure Sockets Layer. This means that the connection from your web browser to the server is encrypting the information. "In cryptography, encryption is the process of encoding messages (or information) in such a way that eavesdroppers or hackers cannot read it, but that authorized parties can." (Wikipedia). So applying this to our mail.google.com traceroute above, this means that only hop 1 (my computer) and hop 11 (Google's server) can see the information, all that hops 2-10 can see is encrypted HTTPS traffic. This is great! There is however still a problem. We have logged onto https://mail.google.com presumably to send an email, which in this case contains a credit card number. So we send the email to someone at Hotmail, cherie. Now the email which is in plain text is sent from Google's server to the Hotmail server and eventually to the recipient's device, taking a multi-hopped path much like the traceroute above. At this point we no longer have control over how the message is secured. Is Google using SSL to transmit the message to Hotmail? Probably. Is the message downloaded from Hotmail to the recipient's device in a secure manner? Maybe, but how can we be sure? Now extrapolate this example to any information you send on the internet. What is happening to your data when it is on the server or in transit in plain text? How could anyone possibly know? How secure is the server at protecting your plain text data from hackers? What are the guardians of your data doing with your data?
Surespot solves these problems by using end to end encryption. Whereas SSL can be thought of as client to server encryption where the hops cannot access the plain text but the server can, end to end encryption encrypts the data so that only the end users can decipher it. No one along the network route the message takes from one client to another, not any of the hops, not even the surespot server, can view the contents of the data. Only adam and cherie.
Encryption is an electronic lock and key system. You take a plain text message and encrypt it using a key (secret). You can then decrypt the message using the same key. Pretty simple. You encrypt data at one end using the key, send it over all the network's hops and servers, and at the other end it can be read because the key is known. None of the hops and servers in-between can read it because they don't know the key.
So adam encrypts a message for cherie with a key, then cherie decrypts it using the same key. Simple right, except for the fact that cherie needs to know the key! Somehow we need to get the key to cherie but how can we send it over the network? We can't encrypt it because we need a key to encrypt so we have a catch 22. Or a chicken and egg situation. The answer is we don't send the key over the network. Well not the key we're using to encrypt the messages at least.
When a user is created in surespot an associated key pair is generated. A key pair consists of a public key and a private key. These keys allow us to do magical things. So now adam has a key pair and cherie has a key pair. The private key is stored on the device, the surespot server does not need and never will have access to it. The public key is given to the user that you wish to exchange messages with. So surespot ensures that adam gives cherie his public key and cherie gives adam her public key. Now the brilliance of shared key derivation can shine. The key pair algorithm that surespot is using allows the following mathematics to happen: adam can now take cherie's public key and with his private key can derive a secret. Cherie takes adam's public key and with her private key derives the same secret! Re-read that part a few times. This shared secret is unique to adam and cherie, only they know, and assuming their private keys remain private, only they will ever know. This shared secret has never been and never will be exposed to the surespot server or any other hops along the network route that the message takes. This shared secret can now be used to exchange information securely. This is the crux of what makes surespot work.
When a user is created in surespot two ECC (secp521) key pairs are generated, one for key derivation, and one for signing.
The username plus keypairs create a 'surespot identity'. This identity is stored on the device symmetrically encrypted using 256 bit AES-GCM with a PKCS5S2 key derived from the user's password (plus salt and other data). The public keys are uploaded to the server where they are signed by the server using the server's private key. A user may create multiple identities and switch between them at will.
To login the client generates a signature using the identity's private signing key against the username, password, and randomly generated data. The server validates the client provided username, password, and aforementioned signature against its stored public signing key for the identity in question. If successfully verified the client is issued a session cookie which authenticates them for future requests until the session expires or they logout.
As the exchange occurs over SSL, session cookies are thought to be a secure enough mechanism to facilitate authentication, but in the future every request could be validated against the signature. The fact that messages could not be decrypted by a session hijacker given the end to end encryption nature of the system also factors into this decision.
As the private key stored on the device is the, uh key, to unlocking all of the data, it is of utmost importance. In the case of a lost or stolen device, if the key is lost along with it, so is all of the data. Identity backup/restore and key versioning help to mitigate this problem. A user may backup their (encrypted) identities (username and key pair history) to device storage, or the cloud and restore them upon demand. Obviously the security is only as strong as the password used to store the identity in whatever cloud service and the surespot password, so make them strong! Never shall a private key be stored on a surespot server.
MITM is currently thwarted by the following:
A user may generate a new pair of key pairs at any time. This process is as follows:
After two users invite then accept each other the users are now friends, the two friends can access each other's public keys, which allows key derivation and message exchange. The scenario plays out as follows at a high level glance:
surespot ensures that no message data or keys are stored on the device an unencrypted fashion. This means that even if someone has your device they will not be able to get the information without knowing your password. Users will be prompted to create a secure password upon creating an identity.
surespot is 100% open source this means that anyone on the planet can review the source code and find flaws. When you have an entire planet looking at the source code you can be assured that the implementation is highly scrutinized and proven. This means that surespot does exactly what it says it does, there can be no back doors or pilfering of any information.