Solution for store sensitive data without having access to it

Question

I need to develop a system where we need to store cryptographed sensitive data, but have no directly access to it.

What I think is something like a private/public-ish key pair. We would hold the private one to encrypt the data the Users may enter and give they the public-ish key. The data can them only be decrypted using both the private and the public-ish key.

This way, we can store the data, but have no access to it. Also, once the Users wants to get their information, they will need to inform their key, so we can decrypt it and send it back.

Does this make sense? Is there a crypto standard for something like this? Or is there another crypto concept/system that I could use in this case?

Thanks!

Answer 1

From your description, I assume you (A) don't actually need access to the users (B) data at any point of time? Ie. A stores B's data, nothing more.

If so, your whole idea sounds pretty bad.

Something about normal asymmetric encryption first:

• The public key is used to encrypt. The public key, not the private key. The idea is that decrypting is hard. It won't be hard if you need the public key for it.
• There's not something like a public-ish/semi-private key. One of the two key holders always can calculate the other key too (but not vice-versa), namely the private key can be used to calculate the public key.
• There's no (single) asymmetric encryption scheme where decrypting needs both keys. You could use two kay pairs, ie. 4 keys, to make something like that, but not a single public/private pair.

Said that, the next problem is your definition of "storage without access". If A wants to store data without having access, why B should send the plain data to A? Because that's exactly what you're proposing: B sends data to A so that A can encrypt it then. Before encrypting, A has plenty access. Same story later when it is decrypted on A's side again before the data is sent back to B.

Third, A gives B a key, and later B sends the key back to A? How are you sure A won't keep the key to have access all the time? And why keys are sent around at all?

What you could do (and it's much easier): A stores the data, like you said, and nothing more. Don't make up nonsenical encryption strategies involving both sides. If B wants the data to be private, B can encrypt the data alone, with own keys and own methods, before sending it to A. A won't ever get any key.

And if you have that, you should think of integrity+authenticity too.

Answer 2

If you have an asymmetric keypair (public key and a private key): if you encrypt with the public key, then the private key is used to perform the decryption and vice versa. You do not use both simultaneously to perform the decryption. Not sure if this is a misunderstanding of the key system or just a typo?

Secondly asymmetric keys tend to be a bad choice for encrypting large amounts of data. A symmetric key algorithm such as AES would be preferrable, see the following for more info: RSA vs AES

If you want the user to be able to store data you can't decrypt that they can then decrypt at a later date. It might make more sense for the user to encrypt it with a symmetric key such as AES on the client side before you ever receive it. Then they can request the encrypted data back and decrypt it themselves.

I'm not sure if you are suggesting the user send unencrypted data, that you then encrypt with a private key? Which is then returned to them for decryption with a public key at their end? In that case the unencrypted data is still being exposed to yourselves right at the beginning. Apologies again if I have misinterpreted!