I would like to know your opinion about the following:

I´m developing an Android messenger, where all communication goes from the app -> php -> mysql, from where it will pulled by the receiver in opposite order. So I´ve been thinking about how to make it secure, and thought about the following:

First time the app is installed, a key is generated by the server, and sent to the user. The key is then used to encrypt (maybe with AES256) the next communication to the server. Then in the next communication FROM the server, a new key is received in the package encrypted by the previous key, and this way every message is encrypted by a new key. Then if you´re sniffing packets, you need to have been there the first time the app was installed to have a chance of breaking the security. On the PHP side, I have several scripts, but I´m considering to have one "entrance" script, that receives an identifier of which of the other scripts that communication is ment for, but not the real name of the other script to be addressed. This way hackers won´t know the name of any of the scripts except for the "entrance" script. I´ve already set up all code in the PHP scripts with PDO/prepared statements. I read somewhere that mysql databases are encrypted by default. Is there any reason that I should take further steps to secure the data in the mysql database?

Other ideas?


The complete encryption scheme you proposed is not at all secure by today's definition; users of a messenger will expect "FORWARD SECRECY" - which means your server must not ever be able to read/decrypt any message-content that is sent from one client to another.

  • "I read somewhere" is not a valid source for anything security related
  • mysql is not capable of saving it's backend encrypted directly, you can keep the backend on an encrypted disk but 99.99% of possible attacks will happen when the system is up and running, when disk encryption is useless
  • encrypting the database backend will not help against attackers who gained access to privileged mysql-login data (like the ones used in your php script)
  • even encrypting individual fields of the database as opposed of the whole database does not help against attackers who gained access to your php code unless proper forward secrecy of all messages is maintained

Symmetric encryption ("maybe with AES256") is only secure when the keys are exchanged and kept private, you propose to transfer the initial key in plain-text thus relying on the first connection attempt to be secure. This is horrible design for secure applications / data exchange. Why not use SSL/TLS for securing the connection with the server? It basically does what you wanted to do, except the "initial" package is transmitted over a secure connection using an asymmetric encryption method to deliver the symmetric keys used for the rest of the connection. And now you only need to worry about implementing proper forward secrecy.

For more details and proper implementation of SSL/TLS and forward secrecy I recommend reading the openSSL documentation. OpenSSL offers all cryptographic functions required to implement a secure messenger over the internet.

  • Thanks markus-nm, ssl is the way to go then and forget all about my own constant key renewal idea? – Corey Hart Jul 7 '17 at 13:03
  • Since openSSL's TLS encryption / secure key exchange have already implemented a key-renewal process along with all the tools required (and that is open-source free software) I see no reason not to use it. Even if you were to add a completely new encryption-scheme it will be easier to implement it into openSSL first and then use it than doing it all by yourself. And that's not even considering the security issue; an insane amount of work has gone into testing openSSL's security to get it where it's at now, even if you're 100 times smarter than these people you would never catch up by yourself. – markus-nm Jul 7 '17 at 13:17
  • So then I´d need an SSL certificate, and nothing less than OrganizationSSL would be required to ensure safety, am I right? – Corey Hart Jul 7 '17 at 14:07

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.