As stated in this page from the documentation, the registration process often requires the user to provide a lot of data. The service provider often keeps that data accessible to the system, so that the servers can then profile the user and sell insights to advertisers: what does the user read/talk about, isthe user’s email or phone number known to other systems to cross-reference that data, etc.
Seeld’s philosophy differs, in the sense that we designed the system excluding data harvesting possibilities. Therefore Seeld only asks three things at registration: the user’s chosen pseudo, the user’s passphrase and the user’s display name.
The display name being sensitive, the client application will encrypt it before sending the registration request to the servers. That way, even administrators will be incapable of knowing a user’s display name.
The following is a sequence diagram representing exactly what happens when registering.
The client initially receives three bits of information at registration: the pseudo (username), the display name and the passphrase.
The pseudo will be the only part that will be known to the server, for obvious reasons: we need one thing to identify who’s logging in! However we preserve the person’s anonymity by not making this identifier its email address or phone number.
The display name is more sensitive, so we will make sure we encrypt it before sending it to the server.
The passphrase is ultra-sensitive, so we will use SRP and key derivation functions to avoid even sending the passphrase.
Initially we generate a random salt, which we use in conjunction with the person’s original passphrase to create a derived key. We then use that derived key to generate the the encryption keys. This mitigates the risk of storing both the the encrypted key’s passphrase and the encryption keys in the same place.
We also generate a random SRP salt which, used in conjunction with the pseudo and original passphrase provides the SRP’s verifier. This will allow us to perform a login without sending the original (typed by the user) passphrase on the network.
Finally we generate a secret key. The client application will send this key when fetching the user’s messages from his own box. Other secret keys will be generated for box addresses set up with the person’s contacts.
Once all this is done, the client generates a self-encrypted payload using the generated encryption keys.
The payload contains everything sensitive the server doesn’t need to function: the display name, the person’s contacts (still empty at the moment), etc.
The encryption keys are also encrypted, even though we send them with the registration request. Note that:
The payload, along with the details necessary to login (SRP salt and verifier, KDF salt…) constitute the registration request. The server never sees the passphrase, the display name, the secret key or the user’s contacts!
However, the server will generate three other artifacts:
More information on the core concepts defining Seeld can be found here.
