0

I am trying to create a communication app from scratch (more like an html parsed messaging app) using the Signal protocol. While I do have lot to of programming experience, I am a crypto novice and therefore I am unable to figure out how do I sign in my users to this their so called email IDs (i.e. in the Signal protocol, where does the concept of Username and Password fit in). On the top of my head I have this idea:

  1. Use Username + Password to generate the keys
  2. Encrypt the Signal's key store with Username + Password

How wrong am I? What would be the real use case of username and password?

Thanks.

  • 1
    Signal do not want someone like you implementing the Signal protocol and then mentioning the word "Signal" while talking about your app. It is extremely easy to build a very bad, very insecure app, lie about it, get some dumb users to trust you, and get endangered when they put real secrets in the app. And they will, even if you say "beta" or "not reviewed by professionals", etc. Professionals even recommend authors purposefully break the build of open source projects on github so that idiots won't use them. If you build it to learn, please never release it outside your laptop. – Z.T. Jun 16 '19 at 16:56
  • Bleh 😑 it is just a fun after work project. I don't understand where did you get the pretext that I am going to commercialize it. Instead of typing this judgemental crapology, I am sure a real answer may have helped "people like me" 🤦‍♂️ – Jishan Jun 16 '19 at 21:28
1

"someone like you" refers only to "crypto novice".

Signal protocol says nothing about identity management.

Your server should have a "users" table and for each user a list of public keys.

A user should be able to perform the following operations:

  1. Create a new user identity using a new (not seen before) user identifier, and add a new public key to that new user identity record on your server ("registration").

  2. On a new device / new installation, prove to the server's satisfaction that they are the same user as an existing user record, and add a new public key to that existing user identity record on your server ("login").

  3. Once logged-in (proving they have a private key matching the public key of a user in your database), they can delete public keys associated with their own user record ("logout" and "logout on other devices").

The user's identity can be:

  1. A pseudonymous username protected by a password (but how to do recovery if they forget the password? Using email? Then just do login by email token and don't use passwords).

  2. An email address protected by email verification (server sends token to email address, API receives it, now believes user is owner of email address).

  3. A phone number protected by sending code via SMS.

  4. An identity provided by some SSO (gauth, FB login, corporate, etc.).

  5. A pseudonymous username not bound to anything external, protected by having a valid pey pair. No way to recover the identity if user loses access to all their key pairs. On registration, user is prompted to create a recovery key pair and keep the recovery private key, serialized like diceware password, safe (on paper). On a new device, they use the recovery key to login, then create a new key pair for this new device and remove the key pair of the old device. The recovery key pair is generated same way all key pairs are generated, the user doesn't get to pick it. That's why it's not a password.

  6. Something else.

A user's key pair is generated using OS CSPRNG and stored on the device where it was generated, using the way the OS recommends to store secrets (e.g. on iOS using keychain and secure enclave, on laptop possibly encrypted by password but UX issue explaining this is local operation).

The private key should never leave the device. There should be no way to backup the private key. If the user loses their phone, they can login on another phone, create a new key pair, delete the old key pair from the server database ("logout from that device").

While it is possible to encrypt the user's key pair using their account password and store the encrypted key pair on the server and give it to the user on login - thus they would have the same key pair on many devices - I would not consider that end-to-end.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.