How to store AES encryption key?

Question

I am running a DV 3.5 server on MediaTemple using Linux CentOS 5, php and mysql DB and trying to encrypt phone records using AES.

I came across what seems like a good script like PHPAES

but I am not sure of the following:

• Where do I really store the AES encryption key used to encrypt and decrypt a phone number?

• How do I call AES encryption when a user submits their data via a form and stores to our MySQL database?

• When I want to describe this information to our internal customer service agents - how do they in turn call the AES key?

I understand that this is probably very simple, but please do not insult. I am trying to learn best practice how to move forward with any type of encryption in general. Something (up to this point) we did not need.

Answer 1

I really finished this route:

I encrypt the source data using a salt hash, which is stored in the database itself (and is unique to each saved record). Then I take this 256-bit AES encrypted string and run it through RSA encryption using the public key, which is located on the server side.

To decrypt, I have to upload a temporary file using my private key and get the necessary data.

quite safe in my opinion.

Answer 2

I developed a process in which I start with the initial encryption key, which I encode into the SHA1 hash, then encrypt with a combination of username / password and store it in the database. The password (hashed or otherwise) is never stored in the database and is used only for logging in to decrypt the encryption key. Then I use this wizard name / password to create additional users with passwords in which PHP or JavaScript encodes the decryption key with the username / password of the new user and stores the encrypted key in the database. When I try to decrypt the encryption key from the database using a username / password combination, I should expect a SHA1 hash. If I do not receive a valid SHA1 hash file that can decrypt the data, then I know that the password is incorrect and the data is unusable. You must have a valid username and password combination to receive the decryption key and which is transmitted to the client via SSL, decrypted using the JavaScript function, and then stored in a cookie for the SSL session.

To bypass the system, decrypt the data and gain access to the information that you would have to infect using the registrar key or the trojan that looked at your cookies during this registration session, otherwise the server owner or client without a username / password the combination can use the data in the database without a rough push. Using AES 256-bit and strong passwords (12 + characters, AZ, az, 0-9, characters, etc.), and you have a rather complicated solution, or at least one that would be painful to try .

Each account has a lock function, so if you try to log in to the system too many times and fail, the account is locked. All PHP pages encode / decode parameters to prevent SQL injection attacks and verify the PHP session is active and corresponds to the last session being monitored during login, and also checks your encryption key. Each time you log in or visit the login page, the previous session is considered invalid, or if your session does not work, it is also invalid. Even with all these layers, it quickly and prevents people from using PHP scripts that output JSON using fabricated POST scripts and SQL injection attacks. It also limits the ability of the owner / administrator of the server to decrypt and read your information, if it is stored in a common provider, etc.