0
$\begingroup$

I am in the design phase of a secure chat application at the moment. I am trying to make this as secure as possible.

The Serverprovider should not have access to the messagedata. So my idea was the following:

  • I have two base keys, one AES and one RSA Key.
  • The AES Key is derived from a password the user enters. The RSA Key is generated randomly and stored on the server. Public key normal, Private key encrypted using the AES Key. This is mainly to allow users to login from everywhere without having to transfer the privatekeyfile.
  • When a new Chat group is formed, a random AES Key is generated and encrypted using each users public key. Since this encryption happens on the device of the group creator, the provider of the server storing all keys never knows them. These encrypted keys are then uploaded to the server and therefore each Client can decrypt and use it.
  • When sending a message, a random IV is generated and stored together with the message.

So far so good, what makes me unsure is that the server knows multiple encrypted versions of the same data as well as the corresponding public keys.

Is there any way to recover the chat AES key using the combination of the encrypted keys and the public keys?

Improve this question
$\endgroup$
2
  • $\begingroup$ What is your threat model? How do you feel that your protocol improves upon from existing ones like OTR or TextSecure, and what are the tradeoffs? $\endgroup$
    – Stephen Touset
    Oct 6, 2014 at 8:42
  • $\begingroup$ There are several reasons that made me decide to implement my own protocol. The most importent is that both of them lack some features. TextSecure lacks (as far as i understod) the feature of group chats with more than two persons. OTR does add plausible deniability what I don't want to have. $\endgroup$
    – Thalhammer
    Oct 6, 2014 at 8:56

1 Answer 1

Reset to default
1
$\begingroup$

Some observations, though I would recommend against inventing your own protocol, at least for real world use:

When a new Chat group is formed, a random AES Key is generated and encrypted using each users public key.

This means the protocol lacks forward secrecy. Anyone who compromises the private key of a chat participant can decrypt any previous chats they've been a part of. (Perhaps aside from ones where they've created the group.)

Since this encryption happens on the device of the group creator, the provider of the server storing all keys never knows them.

Where does the group creator get the public keys? If the answer is "from the server", the server could swap one public key for another for which it has the private key. The server would then know the session key and could encrypt it for the real public key of the participant, with neither the group creator nor the spoofed participant noticing.

Is there any way to recover the chat AES key using the combination of the encrypted keys and the public keys?

Other than the above, the server is also in a privileged position to decrypt the private keys. Since they are randomly generated, no one will be able to generate the same key and compare to the public key (assuming a secure RNG), but the server can try to brute force or dictionary attack the encryption password.

So you'll probably want to require strong passwords, include unique salts and use a password hash.

Improve this answer
$\endgroup$
4
  • $\begingroup$ Do you have any idea how to fix this issues ? $\endgroup$
    – Thalhammer
    Oct 6, 2014 at 10:45
  • $\begingroup$ Thinking some more about this: The second problem looks like a classic MITM Attack. As far as I know there is no way to establish a save connection in such an environment without any key exchange by another system, is there ? Especially if the server performs the MITM. So it seems like i have to provide at least one trusted Server. $\endgroup$
    – Thalhammer
    Oct 6, 2014 at 10:59
  • 1
    $\begingroup$ It would probably help if you studied existing protocols like the ones I mentioned above, to understand how they provide things like forward security and authentication of chat participants. You can't (in general) simply bolt security features on to a protocol — they have to be designed in from the outset. Design of a secure protocol can easily take longer than the actual implementation. $\endgroup$
    – Stephen Touset
    Oct 6, 2014 at 11:01
  • $\begingroup$ Yep, also, if OTR matches your other requirements, you could remove deniability by signing each plaintext message with authentication keys. Not sure why you'd want that, but it should be doable. $\endgroup$
    – otus
    Oct 6, 2014 at 11:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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