Cryptographic Details
This page gives an overview about the encryption/decryption process of SafeChat. The general idea is to use public-key cryptography (in particular Elliptic Curve Cryptography). Each user generates a public and a private key. The public keys are stored at a central, trusted authority, the public key server.
If Alice wants to send Bob a message, we derive a shared secret using the Elliptic curve Diffie–Hellman key agreement protocol and encrypt the conversation using AES. We use Tom Wu's eliptic curve JavaScript library in our implementation.
Each elliptic curve is defined by domain parameters G (in our case secp256r1) and a secret value d, which represents the private key. The public key represents a point, which is the product of the d and G. The private key will be stored on the device, whereas the public key registered under the facebook username on the public key server.
The problem about the key generation in our case is that it has to be deterministic. The user needs to able to log-in from different devices (e.g. desktop and mobile) and encrypt/decrypt all messages with the same key. This is why we use the deterministic password base key derivation function PBKDF2 (implemented natively in iOS and compliant in Javacript by Parvez Anandam). The derived key-length is 256bits and its binary representation serves as the secret d. We use the Facebook username as a salt for PBKDF2 to prevent dictionary attacks.
The key generation is modelled as a petri net below.
In order to encrypt a message, a shared secret has to be derived from the Alices's private key a and Bobs's public key B. Alice can query Bob's public key a public key server.
The public key is just a point that represents the product of Bob's private key b and the parameters of the elliptic curve: B = b*G.
The shared point will be the point product of Alice's private key and Bob's public key:
S = a*B
note that: S = abG
Bob is able to compute the same shared point given his private key b and Alice's public Key A = a*G
S' = b*A
and therefore: S' = baG = abG = S
The string representation of the x and y coordinate of the shared point are appended to form the shared secret. This secret is used as a passphrase to encrypt the plaintext message with AES 256. We use the Gibberish AES JavaScript Library to encrypt the messages. The library is compliant with the OpenSSL implementation of AES. The passphrase is concatenated with a random salt and MD5-hashed multiple times to form the 256bit AES key. The salt and the message will be sent to Bob for decryption. Due to the randomness of the salt, the encryption key will be different for each message. This way, even if the key for a single message got cracked (e.g. by a know AES attack) the shared secret and private key of Alice and Bob would still be unknown to the attacker and all further messages would still be secure.
Assuming that Bob has already generated the shared secret from his private key and Alice's public key, he can easily generate the AES key using the transmitted salt and the shared secret. With this key he can decrypt the message.
The process for an encrypted message transfer is pictured in BPMN notion below:
