I'm looking to provide users with a way to give a service sensitive information, which the service can freely use up until the user decides otherwise. I want to encrypt the data at rest (and of course, in transit).

My thoughts right now run along like so... when the user signs up for the service, they provide their public key. The service generates a public/private pair for this user's account, too, and combines the user's public key with the new service-user public key to encrypt the data. I'm not sure what encryption scheme or tooling would be appropriate here, because I want to meet the goal that the service can now decrypt the data without the user's private key (so only using the service's own private key(s) and maybe the user's public key if it's still necessary).

The other half of the puzzle for me is that if there is a way for the user to stop access, I'm not aware of it. If the user regenerates their keys, that doesn't change how the data is already encrypted. Maybe that part just comes down to trusting the service will delete or re-encrypt when the user notifies of a new public key?

  • $\begingroup$ I have found another question that may have an answer... Does anyone have advice on the strength of this answer? security.stackexchange.com/a/87089 $\endgroup$ – Michael Feb 21 '18 at 19:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.