I am writing an application, running on a server, where multiple users access data from a database which is AES encrypted with a master secret. The master secret itself is initially randomly generated, and then AES encrypted with a user-secret to yield a 'user-hash'. The master secret is never stored, but the user-hash is stored in a database. When a user enters his user-secret, the user-hash is decrypted to temporarily (on the fly) yield the master-secret which is used to decrypt the data. The data is then send to the user.

If a user is deleted, the user-hash is deleted. He may have saved decrypted data, but cannot decrypt further data.

The question is: How safe is the master-secret in this constellation? If the database is compromised, an attacker has access to the user-hash and the encrypted data. If the attacker was a user, he may also have decrypted data. Will he then be able to break the master-secret?

  • $\begingroup$ (I don't see what this has to do with transparent encryption.) $\;$ $\endgroup$ – user991 May 30 '13 at 21:52
  • $\begingroup$ @fgrieu I tried to rephrase the question. Hope it is clearer now. -Paamand $\endgroup$ – Paamand Jun 2 '13 at 11:48

If a user has a copy of both the encrypted and decrypted data, he is in a position to perform at least a known-plaintext attack. If users can submit arbitrary plaintexts for encryption, they can conduct a chosen-plaintext attack, which is stronger. In a chosen-plaintext attack, the attacker can submit any number of plaintexts and can retrieve the corresponding ciphertext.

All reasonable encryption algorithms are resistant to chosen-plaintext attacks, and AES is considered a reasonable encryption algorithm. Someone in possession of some (plaintext, ciphertext) pairs cannot encrypt or decrypt other messages (except sometimes messages derived from the known messages if a bad mode is used). In particular, no matter how many known plaintexts and ciphertexts the attacker is, he has no method to obtain the key that is better than brute force (trying all possible $2^{128}$ keys).

Do note that deleting the private secret does not delete the master secret. The master secret can still be recovered from backup copies of the private secret that weren't deleted, from other users' private secret, or from extant copies of the master secret.

|improve this answer|||||
  • $\begingroup$ @fgrieu True, my wording was sloppy. I've rearranged the paragraph to make more sense. $\endgroup$ – Gilles 'SO- stop being evil' May 31 '13 at 14:14

Your master secret is never secure, at least not as you have described it. As a user, I know my private secret. When I use your application, my private secret decrypts the master secret right there in the application. With modest technical skills, I can examine the memory of the process or machine and read the master secret in plaintext any time I wish. I can retain that master secret forever, and the administrator will never know.

To solve this, I expect you are relying on the master secret being secured on a different platform than the one the users are logged into. Your problem has now expanded and shifted to securely communicating the users' secrets to the secure platform. To accomplish that, you need an authentication mechanism. Once you have solved that, there becomes less need for the double encryption as you have defined it - simply authenticate user access to the platform, and revoke it as needed. The platform can own the master secret if on-disk encryption is desired. The user never has to access it directly.

A different approach is that you can allow users to encrypt data locally (using public key cryptography to encrypt a random AES key) but they can never decrypt it themselves. That job is performed only on the server.

|improve this answer|||||
  • $\begingroup$ Thanks for the inputs! The application is indeed running on a remote server. My question was more principal and was, retrospectively, related to chosen plaintext attacks. $\endgroup$ – Paamand Jun 2 '13 at 12:07

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.