Ask HN: Which way for storing client's RSA public key is correct?

1 pointsby airswimmer4 anni fa1 comments

For end to end encryption, client should pass his own RSA public key to server after every re-login. Client should have a dynamic RSA public key. Client may have the same credential but with different RSA public keys. Client will generate a RSA key pair randomly after start the app for the first time.

In other words, client will login from different devices at the same time.

For now all user sessions are stored in Redis server using Django(Python) framework as backend. Other user info are stored in PostgreSQL database.

I am thinking about 2 approaches for exchanging public keys between client and server.

*client sends his login credentials and public key to the server, then server will verify the credentials, then*

1. Server add client's present pub key into his login session (redis server). Server will read client's pub key from Redis server to encrypt data. Later on, server will pass the encrypted to client.

2. Server add client's present pub key into PostgreSQL database with some columns, such as foreign_key to user_id, client_pub_key, valid_until, created_at. All the RSA key validation will be handled by the Django(Python) server. (I'm worried querying client RSA keys everytime from database will drag down the performance)

Which one do you think is modern, secure and fast for End-to-End encryption for user login from multiple devices?

Some better designs?

Appreciate your comments!

1 comments

speedgoose4 anni fa

If you don’t already have redis in your stack, stick with postgresql for now. You can always optimise later, but a proper machine (not a crappy public cloud VM with heavy throttled network storage) can handle a lot of SQL transactions before introducing redis is worth the effort.