-
Notifications
You must be signed in to change notification settings - Fork 2
This is a list of frequently asked questions about our project. We will update it as we go along and receive more questions.
- How does the encryption work?
- Isn’t a passphrase too insecure for generating a key?
- What data are we storing?
- Why are there two apps I have to authorize - SafeChat.IM Client and Authenticator?
- How can validate the promised privacy and encryption?
- Why do you not an existing encryption protocol like Off-The-Record Messaging?
The encryption is based on public-key cryptography. The key pair is generated on your device, based on the passphrase you chose. The public key is then stored on a server, that we host. If you chat with a friend, the plugin asks the server, if your friend has a public key in the database. If yes, the public is sent to the plugin and all messages are encrypted from then on. Note, that your private key never leaves your device.
If two users, who both have a public key stored on our server, communicate, the App derives a shared secret from its private key and the public key of the other person using the Elliptic curve Diffie–Hellman protocol. Messages will then be encrypted with the shared secret using AES-256. For more details on the cryptographic process, we refer to the details page.
Usually random numbers are used to generate a public/private key pair. However, since we have to be able to generate the same key on multiple device we have to use a deterministic method. Right now, we use the passphrase and your Facebook id as a salt. This way we prevent rainbow table attacks. However the strength of the key depends on the passphrase you chose. We therefore ask you to chose a phrase not a word!
Another possibility we are thinking about is using a random hash, which will be shown as a QR code and can be scanned with the mobile. Our main goal is to make encryption as easy as possible which is why we don’t want you to export/import keys on multiple devices.
We only store the facebook_id of the users together with their public key. We DO NOT store any personal information, friend lists or the like. We also do not store the messages you sent in any form.
In order to access messages from your Faceboook profile we need to query the Facebook Server with an application that has very extended permissions (e.g. read/write messages on your behalf). This is done using so called auth-tokens. Each auth-token is associated with certain permissions. SafeChat.IM Client has an auth-token that allows to query message data. When we register your public key on our server, we have to make that you are actually the person for which we store the public key. Facebook allows to debug auth-tokens and give information about who is the person behind the auth-token. Therefore, by sending an auth-token with the request to store a public key, we can make sure that it is actually stored for the right user. However, if we used the SafeChat.IM client app token to validate that information, we would theoretically be able to access your messages from our server (the moment we validate your information). Therefore, we created a second Facebook App, SafeChat.IM Authenticator, that only has the most basic permissions. Only the restricted access token leaves your device, we have no point access to your private messages.
As soon as we start developing we will Open Source the entire code. You can see for yourself, which information is stored and how encryption works. We believe that open security is the best form of security.
Indeed, Off-the-Record Messaging (OTR) provides a very strong encrypted messaging protocol. However, opposed to SafeChat.IM OTR messages are encrypted with a session key, that changes constantly. This leads to a number of limitations: Offline messaging is not supported, group chats are not supported, and messages cannot be read after the conversation/session is over (deniability for the conversation).
We want to provide encrypted communication without limitations. We are targeting people that do not use encryption, because it is too much of a hassle. If they feel that not encrypting their messages is somehow more convenient, they won’t use the plugin.