1

Normally I would want to develop an app that encrypts user's data with symmetric encryption (AES 256) from a password based derived key (PBKDF2).

For a new project, I would like the users to be able to add data to their account without authenticating. All they would have to know is their account identifier (username, email, etc).

Could I accomplish this with asymmetric encryption like RSA? Unauthenticated input would be encrypted with an account's public key, and only the account holder could decrypt with their private key.

Would this be an acceptable approach, or am I totally off?

Edit: To clarify, a use case would be the ability for the system itself to generate data on a user's behalf that can only be decrypted by the user. Assumption that the system makes no logs of this.

Improve this question
4
  • Unauthenticated means "I don't know who did that", not "I didn't need to log in". You could certainly encrypt things with a user-specific public key, except: 1) If unauthenticated users can write to the datastore, they can't trust the data inside - you've just re-invented PGP-mail, essentially. 2) Most users can't handle a private key, so it immediately raises the question of "who is doing decrypting?". If it's (one of) your services, why are you bothering? You're in control of the database... just write to it normally.
    – Clockwork-Muse
    Nov 22, 2018 at 0:31
  • 1
    @Clockwork-Muse, the goal is for the service to never have user data in plaintext at rest. The user's private key is only accessible by their password authentication, and will decrypt data client-side. The public key will be known by the service to encrypt any data being "dropped" into the target user's account.
    – Sterling Beason
    Nov 22, 2018 at 0:46
  • In almost all cases, at-rest encryption is best accomplished via encrypting the database/filesystem (because that's a built-in feature). That only covers out-of-process attacks, though (SQL injection usually still works, for example). Decrypt-on-demand is usually done with a symmetric key (protected by the password), and on the server - unless you have an external app that registers a public key on creation, you have to distribute the key with the decrypting code, so that doesn't gain you extra security.
    – Clockwork-Muse
    Nov 22, 2018 at 7:44
  • You haven't said what "user data" might be showing up this way, though. That the user isn't creating it themselves is rather strange (the key would be available at that point) - this implies that it's of interest to the business, not the user, so you'd want a non-user key protecting it. What is this data? Where is it coming from? What are you using it for?
    – Clockwork-Muse
    Nov 22, 2018 at 7:49

2 Answers 2

Reset to default
0

I think that your users should be authenticated for adding data into their accounts. Take into account that if somebody could polute the data just by knowing the credentials.

Another approach that you can follow is that your application only will write the user data if has been signed properly. On the creation of the account you store the public key of the user and for adding data to that account only data that has been signed with the privake key that your application can verify. Here is an example:

  1. User generates a private and public keys.
  2. Your application generates an account with (username, email, public key) (account1)
  3. Some user wants to write data on account1.
  4. Your application verifies that the data received has a signature that can be verified with the public key of account1. If this operation is true this means that the data received has been signed with the private key of account1, in any other case you reject the data.

Hope these helps you

Improve this answer
0

Yes, if you encrypt data with the user's public key, only someone with the private key will be able to decrypt it.

Taking from the playbook of the Noise protocol, it seems to recommend mixing the public key with an ephemeral key. I can't reason what exactly this buys you but noise protocol was designed by smarter people than me so I take it at it's word that it's important.

https://noiseexplorer.com/patterns/N/

To be pedantic:

Because asymmetric encryption is relatively slow, Depending on data size it's usually better to generate a random symmetric key, encrypt the data with the symmetric key and then use asymmetric encryption on just the key.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .