2

I want to make a messaging social network but am worried about the NSA wiretapping all my members at once without merit like they wanted to do with Lavabit.

I've found a way to encrypt messages using multiple keys (one key for each user, so that multiple users can see the same message), and thought the best way to do so is to use the user's typed in password as a key which I salt and hash to compare to the salted and hashed version in the database to see if they match, as I don't have access to the password and it's personal to the user.

But what if someone changes their password? Then their password key won't be able to access their encrypted messages. What's the best way to go about this? It's not like I can store the key in the database.

  • 3
    Have you looked at technologies like PGP? – Neil Smithline Dec 9 '15 at 21:10
  • 2
    There's even multi-recipient support in that standard. – Natanael Dec 10 '15 at 8:27
  • I can't use PGP because the encrypted private messages have multiple recipients. The messages are a part of chat rooms where multiple members will get to view it, so I need to encrypt the message with multiple keys at once, something PGP cannot do with one-two-one communication. – desbest Dec 10 '15 at 12:09
1

But what if someone changes their password? Then their password key won't be able to access their encrypted messages. What's the best way to go about this?

When someone changes their password, every system I am familiar with requires the user to type in both the old password and the new password.

simple

If there is only a small amount of encrypted data, and you want your user to be able to access that data with only the new password, the simplest approach is to decrypt all that data with the old password to recover the plaintext, and then encrypt the plaintext using the new password.

indirection

My understanding is that many systems have several levels of indirection. When someone wants to read the plaintext of one document, behind the scenes what really happens is the typed-in password is used to decrypt a keyring that stores (in encrypted form) a master key. (typically the "~/.ssh/id_rsa" file or the "~/Library/Keychains/" file).

The encrypted document is typically stored in RFC 4880 OpenPGP Message Format or something similar. The master key is used to decrypt one of the blocks in the header corresponding to that master key, giving the unique symmetric key used only for the body of this one document. Then that symmetric key is used to decrypt the body of the encrypted document, producing the plaintext.

When someone changes to a new password, generally the old password is used decrypt the entire keyring, and then the system encrypts the keyring with the new password. All the files are still accessible to that user, because the exact same master key is used to decrypt that file.

Alternatively, for each document the user has permission to access, one could add another block to the header of that encrypted file that contains an encrypted version of the same document-unique symmetric key, encrypted by a fresh new master key.

Ideally the user would carry around his own keyring and no one else would ever have access to it. In practice, many systems store an (encrypted) keyring for each user.

  • I asked my friend how to do it before you posted your answer, and he said a much similar thing to what you said. – desbest Dec 12 '15 at 14:46
0

I would recommend two keys. Since all messages are encrypted with key A and therefore, if a user changes his key, all messages have to be re-encrypted (possibly a high workload) a different solution makes sense.

I would let the server generate an encryption-key A for each user which can be accessed by the users custom encryption-key key B. So if you choose your A strong enough all messages stay intact when the user changes his key. In this way all you need to do is update the has value to the encryption key and have a very low complexity.

Is this of use to you? If not, please let me know :)

John

  • Is key B different of every user or is it universal? – desbest Dec 9 '15 at 12:00
  • 2
    The server shouldn't ever have the encryption key so it can't generate it. – Neil Smithline Dec 9 '15 at 14:48
  • If the server shouldn't have the encryption key, do I decrypt the user's messages when they login? The private key has to be stored somewhere so that the user's messages are decrypted when they login. I can't use the password because the user might change it, and I can't expect the user to enter a PIN each time they login, as it's not good UX. – desbest Dec 9 '15 at 14:58
  • 1
    @desbest - you need to decide whether you really want to be NSA-proof or not. If you have the keys server side, it means that the NSA can hack you to get the data. Even if you have a panic button to delete all keys, doing it successfully is very hard. – Neil Smithline Dec 9 '15 at 21:10
  • 1
    then I would suggest to share your information and maybe help others who experience the same question. – JRsz Dec 10 '15 at 12:34

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.