I am creating a portal where users can send private messages (PMs) for a very large audience. So I want to encrypt the messages and store them in the database. But I do not want to ask the users for new keys. So here's what I have planned:

A randomly generated symmetric key will be allocated to every pair of users, which will be stored in the database using their passwords in an asymmetric scheme. Using this symmetric key, I intend to encrypt all their messages. So, even if either of them changes their password, I won't have to encrypt all the messages using the new pair of keys. Also Alice and Bob will not be notified of their shared symmetric keys.

This solves my problem of changing passwords and users do not have to set new keys. But is this an overkill? Is there a better way to do this?

  • 3
    That means when you have n users, you will have n² public keys in the database. That's quadratic growth. When you have a million users, a million of keys will have to be generated when a new user registers. This might not scale too well. – Philipp Apr 19 '14 at 11:56
  • 3
    What's the attack vector you want to protect against anyway? – Philipp Apr 19 '14 at 12:10
  • 2
    If you're handling all the encryption, you don't even need a key-per-user, you can just encrypt it with a single key. Since otherwise you'd have to control access to the decryption keys, you can simply control access to the message - encrypting the database would be just to prevent disclosure if the db gets stolen. – Clockwork-Muse Apr 19 '14 at 15:03
  • @Clockwork-Muse I am developing it for someone else. So they will have access to the database as well as the source and the server. That's why I am considering this method. – batman Apr 20 '14 at 4:34
  • 1
    er, what? How does that change anything? Beyond being a potentially problematic requirement from a client, I mean. So far, nothing you've described about your system would warrant that kind of effort. At most, if it was required to store the messages encrypted per-user, I'd just assign everybody public/private keys, then encrypt per-destination-user. But you'd have to store the keys securely anyhow, which would best be accomplished by encrypting them with an application key, at which point why not just encrypt the db with the application key... – Clockwork-Muse Apr 20 '14 at 4:42

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.