Implement cryptography

[gdahia]

User session cryptography: When user is created, it send its public key, alongside its username, to the server. They are stored together. To log in, the user sends a signed (using one of the possible schemes) to the server, which checks the authenticity using the public key.

Chat cryptography: Bob sends Alice his public key. Alice generates a symmetric key and creates two encrypted copies of it: one using her public key, and the other using Bob's. She sends both copies to the server, where they are stored in the (Bob, Alice) chat. She also sends the key encrypted by Bob's public key to Bob. The only copy of their message logs stay in the (Bob, Alice) chat, encrypted by the symmetric key.

The interest in this scheme is that there is no need for either Bob nor Alice to have a local copy of the symmetric key nor of the message log and the only requirements are two encrypted copies of the symmetric key (one using Bob's public key and the other Alice's) and a single copy of the message log, ecnrypted by the symmetric key. It is better to have only one symmetric key per chat, than one symmetric key per chat session: non-simultaneous online users are enough of a reason, but it is also reasonable to assume that the encrypted symmetric key is shorter than the message log, so it is better (and faster) to encrypt the message log with it.

When Bob wants to access the message log, he retrieves the encrypted symmetric key from the server, decrypts it using his private key. In possession of the symmetric key, he can decrypt and reencrypt - therefore read and update - the message log.

It is not possible for the server to access the message log because it requires the symmetric key to be decrypted. While the server possess two copies of it, they are either encrypted by Bob or Alice's public key; it is reasonable to assume that to decrypt those copies, the server would require either Bob or Alice's private key.

[gdahia]

Java implementaion of RSA: https://gist.github.com/dmydlarz/32c58f537bb7e0ab9ebf

[gdahia]

It is possible to implement point to point encryption for group chats without generating a symmetric key. The only way I know how to do this is by encrypting each sent message with the public key of each user, and storing every copy of the message log encrypted for each user. In a chat with n users, this would mean n copies of the message log, which is undesirable.

The scheme outlined in the first comment works for chats and for non-simultaneously online users, albeit requiring asymmetric key generation for every user and, to be conciliated with login from multiple devices simultaneously, persistence of both clients and server (i.e. #20 must be implemented first to allow). A detailed explanation for this follows.

The chat creator generates, in his host, a symmetric key, encrypts it with his public key and store it in the chat. Upon entering the chat, the creator decrypts the symmetric key with his private key, granting him/her full access to it and providing an inductive basis. Whenever Alice is added to a chat, at least Bob, the user who added her, is online. Since Bob has access to this chat (as he added Alice to it), by induction he is able to decrypt the symmetric key stored in the server with his public key. He decrypts the symmetric key, encrypts it using Alice's public key (available on the server) and stores this newly encrypted copy of it in the chat. When Alice is online, she can get the copy of the symmetric key encrypted with her public key and decrypt it using her private key, granting her access to the chat.

[gdahia]

Signing messages: https://docs.oracle.com/javase/tutorial/security/apisign/index.html

[gdahia]

Problem with the symmetric key approach above is that when a user leaves the chat, no other user is online and, in order to void his access privileges to the messages, one would have to re-encrypt all the messages with a different key. N copies of the message log does not suffer from this issue.

[gdahia]

Current implementation has a single unsafe message in login protocol: sending the remore reference to Session