0
$\begingroup$

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?

$\endgroup$
2
  • $\begingroup$ I don't understand what 1 is about. Why can't you save the private key in the browser? 2 isn't a question. What's the issue with that scenario? $\endgroup$ Jan 25 at 15:51
  • $\begingroup$ @AmanGrewal, I edited 2 to be a question. So should I save the key on the client? The issue is just that it might be obtained by an attacker there. $\endgroup$ Jan 25 at 21:05
1
$\begingroup$

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)

$\endgroup$
1
  • $\begingroup$ Thanks a lot for your explanation. I don't quite understand how the attacker would use the obtained password list in the scenario you described. Passwords would of course be hashed before saving them on server side. So this would generally hold without your modification if we could get users to use passwords that can not be just plain guessed? $\endgroup$ Jan 26 at 9:13

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.