-1

Here are the requirements: 1. Receive data and store it encrypted data with public key 2. Private key is not supplied and not stored 3. Return encrypted data through the APIs 4. Display decrypted data in the web client with the private key supplied (but never sent over the wire)

  1. Is this standard mode of operation?
  2. I was thinking the client would supply the private key on demand and it will be stored in memory, so every new session the key would need to be supplied again. that way the client can decrypt these fields to display.
  3. Any better suggestion on how to handle customer sensitive data, where only the customer can see that decrupted data, and not even the admin on our service can decrypt the data?
Berethor
  • 261
  • 1
  • 11
  • Regarding requirement 1, you should encrypt the data before sending, not before storing. – Janoz May 24 '16 at 13:42
  • The issue with this approach is that the data inserted, is actually sent via the customer's customer, via our own client, on a public domain, which does not, and should not, posses the key. The only place i can encrypt that is in our backend – Berethor May 24 '16 at 15:07
  • Summarizing: Client 1 uploads data to the server. The server encrypts the data with a public key. Client 2 has the matching private key, downloads the encrypted data and decrypts the data. Note: the server does have access to the plaintext data one-time during encryption. Correct? Is the data smaller than the asymmetric key? – zaph May 24 '16 at 15:48
  • Your "web client" is a web browser, yes? – Neil McGuigan May 24 '16 at 17:23
  • zaph - yes, that is correct. The data should be smaller than key. – Berethor Oct 10 '16 at 14:36
  • Neil - yes, web browser – Berethor Oct 10 '16 at 14:36

1 Answers1

0

Encrypt the data on the client and send the encrypted data to the server. This eliminate the need for the server to have a public key per client. Since only the client has the key a symmetric key algorithm such as AES is a better solution.

Generally even when using PKI the data is actually encrypted with a symmetric key. Asymmetric key encryption has several limitations such as being exceptionally slow and limited in data size to the key size. There needs to be a compelling reason to need a public/private key pair.

zaph
  • 108,117
  • 19
  • 176
  • 215
  • The issue with this approach is that the data inserted, is actually sent via the customer's customer, via our own client, which does not, and should not, posses the key. The only place i can encrypt that is in our backend. – Berethor May 24 '16 at 15:06