Recourier allows users to securely share messages over the Internet with a high degree of certainty the message will not be read by any entity other than the intended recipient.
To securely and anonymously create an encrypted message, simply enter a message and passphrase. The client encrypts the message using the AES-256 encryption algorithm and then uploads the encrypted message to the server. A link to the encrypted message is returned. To decrypt the message, visit the link and enter the correct passphrase.
All of this is accomplished without storing encryption keys or personally identifying information on your computer or on Recourier's servers. The keys are generated temporarily on your computer and are discarded once the encryption or decryption process is complete.
Whether encrypting or decrypting, the passphrase and unencrypted message never leave the client computer and are never received by the server.
From the user's perspective, a plaintext message and passphrase is entered, the encrypt button is clicked, and a link to the encrypted message is returned from the server. Under the surface, though, much more is happening.
To generate the deterministic 256-bit encryption key, the user entered passphrase is salted with a server generated 256-bit random number and run through a 1,000 iteration password based key derivation function (specifically, PBKDF2-HMAC-SHA256). The encryption key is then concatenated with the user passphrase, salted, and run through 1,000 iterations of PBKDF2-HMAC-SHA256 to generate a deterministic 256-bit authentication hash used to verify the decrypting user holds the correct shared secret. The shared secret never leaves the client, and never touches the server. Neither the passphrase nor the encryption key can be derived from the authentication hash.
The encryption engine uses the client generated key, salt, and a server generated random 256-bit initialization vector to compute the ciphertext using AES-256 in CCM mode. As an additional check to the authenticity of the message upon decryption, the plaintext and passphrase are concatenated, salted, and hashed to form a message signature. The signature verifies the plaintext has not been tampered with prior to decryption.
When submitting the encrypted message, the client transmits the ciphertext, message signature, and authentication token. The server stores these three elements along with an 80-bit message ID, and returns a link to the encrypted message so the user or recipient can decrypt the message at a later time.
The passphrase is never transmitted to the server, and is never written to your computer's hard drive.
All communication between server and client is secured using TLS/SSL.
When an encrypted message is stored on the server, the message contents are completely hidden from view. No information about the encryption key or the plaintext message is received or stored by the server; the only known attack at this stage is brute force of the user passphrase. Such an attack underscores the importance of a long, good quality passphrase. The longer the passphrase, the less chance a randomized password guessing attack will guess the key. It is recommended the user passphrase be at least 12 characters in length.
Each encrypted message is generated from a different 256-bit salt and user passphrase, thus making every encryption key different. Determining the key for one message does not directly help an attacker determine the key for another encrypted message. Since each key is only as strong as the passphrase, users can mitigate the efficacy of such an attack by selecting a long passphrase.
Similar to the encryption process, decryption uses AES-256 in CCM mode and happens entirely on the client machine. A client requests a message ID, and the server responds with a 256-bit random salt associated with the stored message. This salt, along with the user entered passphrase generates a 256-bit encryption key. The key, before being able to decrypt an encrypted message, uses the password based key derivation function to compute an authentication token.
Once verified as correct on the server, the authentication token allows the client to receive the initialization vector, ciphertext, and message signature. At this point, the plaintext is generated and the message signature is verified. The decryption is always performed on the client machine, and no evidence of the encryption key or plaintext are transmitted to the server.
While doing the most to mitigate the effectiveness of any attack, this software does not and can not protect against all of the following types of attacks:
SJCL was written by Emily Stark, Mike Hamburg and Dan Boneh at Stanford University.
Recourier is not associated with Stanford University or the SJCL in any way, shape, or form.