Close this search box.

Seeld’s privacy-conscious registration process

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.

Registration process sequence

The following is a sequence diagram representing exactly what happens when registering.

Registration process

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.  

The payload

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: 

  1. The private key sent over at registration is protected with the key derived from the original passphrase, which is never sent over the web. 
  2. The server will send back the keys at login so that the logging user can decrypt that self-encrypted payload. 
  3. The server will provide the public key to persons that want to contact with this user, so that the contact request remains invisible to the server. 

The request

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:

  1. A box address, used to deposit and fetch the copies of messages sent by this user
  2. An AES device storage key, which encrypts the data cached on the browser or app for further security
  3. An AES exchange key, which protects some non message-related data exchanged between the logged user and the server

More information on the core concepts defining Seeld can be found here.