Imagine a mobile app that connects to an API server.
I'm not sure if RSA is the right technique for this, please feel free to recommend alternatives.
The backend/database super users should not be able to recognize personal data (except email) that the user submits (in this case personal tracker data) while the user should be able to read that data in cleartext. In the case of a lost phone or something, the user should be able to retrieve his old RSA keypair without him even noticing, just by using his email and password. Besides all that we want to be able to verify the user by sending him an email on registration.
- User downloads app, app generates local RSA keys.
- User registers on the app, provides strong password and email address for verification and this is sent to the server over https:
- Hashed Password (Bcrypt, salt is stored inside hash)
- Encrypted RSA Keys (encrypted with ? using the password)
- Plaintext email for contacting/verification purpose
- Server recieves data, creates new user entry in database and stores the already hashed RSA Keys also with the user entry.
- User uses app, sends sensitive data encrypted with RSA to the server, server stores that encrypted gibberish.
- User can retrieve old entries in the app by retrieving the gibberish and decrypting it with the local RSA key.
- User loses his Smartphone, therefore the unencrypted RSA keys
- User buys new phone, installs app and logs in with his credentials
- Server first uses hashed password to check if credentials are okay, if yes, sends the user his encrypted rsa keys for him to decrypt them with his password locally.
- Voila, user has now recovered his encrypted data while backend has no idea of what is inside the data.