This is more of a software engineering question than a programming one. I tried to make the title as relevant as possible, if someone feels they can word it more appropriately please let me know.
So, I have been developing an instant chat web service using asynch. javascript and PHP. The main selling point behind the application is utmost secrecy. There are many instant chat apps out there, from Live Messenger, Yahoo Messenger, IRC and Skype, to name a few. However – call me paranoid – but I felt like I could never trust the companies behind the software as very little control is exposed to the user and most seem to neglect privacy issues altogether. I’m aware there are many other secure/private IM apps, but decided to create my own, it uses SSL to encrypt communication between all points of use (user->database->user), the to/from properties within the message table are SHA256 hashed with a salt and as a further precaution messages are automatically deleted from the database as soon as the recipient receives (or requests I should say) the message.
At the moment the messages themselves are left plain text. I could use PHP’s various encryption libraries but how would I do so in a way that would remove the potential for myself, the owner, to decrypt messages thus compromising privacy?
I would by no means do this of course, I would just like to prove privacy to this extent. If I were to encrypt with a password, I would know the password. If I were to encrypt with a programmatic password, I would know where PHP would store the password.
Is there a way to solve this? Or does this just end with trust?
UPDATE: As far as I’m aware PHP is stateless, but sessions for example force the server to store data in memory, could this be a solution to have the key/password stored in the memory?
Thanks for any ideas or advice.
The typical way this type of problem is solved is with public key encryption. You can read here for an overview: http://en.wikipedia.org/wiki/Public-key_cryptography.
In a nutshell, every user is issued a public key/private key combination. The public key is public so you can get anyone’s public key. The private key is kept only by the user that it belongs to. The key to public key cryptography is the math that allows one to encrypt something using the public key, but only decrypt it with the private key. So you can obtain someone’s public key, encrypt a message destined for them and they are the only ones that can decrypt it with their private key.
In your scheme, public keys can be kept on your server and requested by the client. Public keys are available to anyone. In a browser-only environment, it’s a challenge to store a private key. It could be stored in local storage, but then it can only be used from that particular computer. If you allow it to be stored on your server so the user can retrieve their private key no matter where they are, then you’re back to the same problem you originally have (you have to trust the server and the server author that they aren’t accessing the private key themselves).
There’s a more complicated algorithm that tries to cache the public key/private key (probably in local storage), but anytime it is not available any more (like when the user switches computers), you simply coin a new one and store that locally and update the directory with the new public key. This has the advantage that you can continue to use the system from a new computer, but the disadvantage that you won’t be able to read messages encrypted with a prior public key unless you somehow have the private key that corresponds with that public key. So, this could work in a live instant messaging scenario where messages are never saved on the server for you, but not work if the server holds messages for you and you are expected to be able to read them from any location, each with their own key pair.
SSL solves this issue by using dynamically generated public key / private key pairs but they are negotiated and exchanged in a direct end-to-end connection (so there is no node in the middle that gets to see or store unencrypted data) so another possibility would be to use peer-to-peer gaming technology (which has it’s own warts and may not be possible in only a browser) to create a peer-to-peer connection and use SSL over that connection to either exchange security credentials (outside the view of you and your server) or to just directly exchange the messages. Your server would be used to facilitate two endpoints connection and communicating that desire, but not used for the exchange of security information.