Making a secure file sharing scheme usable

Question

I am trying to realize a secure file sharing scheme based on asymmetric crypto. Users will access this via browser. In short, it works like this:

• Users register and set their username and password. From this password, a public/private key pair is deterministically generated and the pk is published to the server.
• Once someone wants to publish a file to a selection of receiving users (organized as a room or group), they retrieve the respective list of public keys and generate a symmetric key. They then encrypt the file with the symmetric key and that key with each of the receiver's public keys respectively. Then they send those keyfiles and the encrypted file to the server.
• To receive the file, another user can download their keyfile and the encrypted file, then decrypt the keyfile with their own private key and the file with the decrypted symmetric key.

Now there is two main drawbacks to this (in descending priority):

1. After logging in by providing their password, in order to generate the asymmetric key pair and thus be able to encrypt and decrypt files the client (browser) has to somehow save the password or ask for it anytime it is used.
2. I want to be able to add a new user to a room/group so that they can access the published files in there. To do this, that user needs to get the "permission" of another member of that room to access the file (by that user reencrypting the keyfile). Can the effort required by another user be reduced?

Do you think those can be fixed within this scheme or how can it be changed to not have these drawbacks?

Answer 1

Here's one obvious problem that you don't mention:

Users register and set their username and password. From this password, a public/private key pair is deterministically generated and the pk is published to the server.

That means if someone downloads the password list from the server, he can go through his list of weak passwords, convert them all into a key pair (using the deterministic process) and see if that public key is listed as anyone's public key. Given how often weak passwords are used, that's bad.

Even if the username is stirred into the algorithm, it's still bad (the attacker needs to work on each public key separately, that increases his work effort somewhat).

Here's a modification that might make it not so bad; we have the end users generate their public/private keypairs randomly, and then store the private key on the server in an Opaque-type protocol (and the public key in the clear).

That is, the user would take his password $p$ (hashed along with his user name using Argon-2), selects a random value $r$, and computes the EC point $rpG$ over an elliptic curve (where $G$ is the point generator, and the curve may be Curve25519), and sends that to the server, which computes $s(rpG)$ (where $s$ is the server private key) and sends that back to the client; he then computes $r^{-1}s(rpG) = spG$; he then sends that through a KDF, generating a symmetric key $k$, and uses that key to encrypt his private key, and sends that off to the server.

Then, when it comes time to log in, the user enters the password $p$, and repeats the above process, obtaining $k$; the server also gives him the encrypted private key, which he then decrypts.

The disadvantage of this is that the user must interact with the server every time he logs in.

The advantage of this is that an attacker must interact with the server for each password for each user he wants to test; the server can easily notice that it is being queried literally thousands of times for a particular user, and take appropriate action.

And the server never learns the user's private key (it has the encrypted version; however he doesn't learn the symmetric key to decrypt it)