1

I know there are several issues about encryption, but my case is slightly different

  • Users have confidential information stored on their device
  • They have a RSA key pair
  • The information must be encrypted and sometimes shared with another user in a secure manner. The server in no case can know the contents of this information

Options

1) Encryption on the device with the public key and decryption with the private key. When the user wants to share data, encrypts it with the public key of the third party and sent by the server. The user decrypts them with the private key

2) There is a HMAC encryption key for data. The secret key is encrypted on the device with the public RSA key and decrypted with the private key to be used. There is an encrypted copy of the data in the server. When the user wants to share data, encrypts the secret key with the public RSA key of the other user and link to acopy of the data in the server

Pros and cons

1) Encryption and decryption slow. Data synchronization requires a copy per user. An evil user does not put the system at risk

2) Encryption is faster. There may be a copy of the data server and sent only the key. Delete a contact involves renewing the key and distribute?

My question is which option to choose and in the case of 2, which can have security issues

pedrofb
  • 270
  • 1
  • 9

1 Answers1

1

I would perfer Nr1 due to simplicity, but take Nr2 if:

(a) In your case, Encryption and Decryption really -is- slow for some reason. So slow that its a problem for Usability. Perhaps massive amounts of Data or user machines with very bad processing capacity.

(b) It was not a typo in Option 1 that they use a third party key. In my opinion they could make the public keys available to all system users, then encrypt data with the public key of the intended recipient user when the data is requested (then only he/she can decrypt it with his/her private key).

RSA have a padding issue you might consider reading about, What specific padding weakness does OAEP address in RSA?.

When it comes to these sort of things, SIMPLE is often the wise choice.

With the implementation of every encryption method, every little row of code there exists the possibility of absolute and crushing failure. Thus complexity of solutions should be reduced to as simple as it can possibly be, but not more simple then that.

One encryption method, one crypto library, one process to create one type of keys, few points of failure.

How often are data updated? How much does data storage cost? How is the HMAC generated? Such things needs to be considered.

Community
  • 1
Simply G.
  • 518
  • 3
  • 12
  • be simple is a good recommendation! Data could be updated frecuently, but it is not necessary distribute an instant copy. Thinking about a user with N contacts, solution 1 implies doing N encryptions sometime and send them. With solution 2, the hmac key will be generated on client device and sent to the contacts when they join. So, a data update only implies one copy. – pedrofb Jun 03 '16 at 09:57