How should I store a AES Encryption Key?

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

I came across what seems to be good script as PHPAES

but I am not sure of the following:

1. Where do I actually store the AES Encryption key used to encrypt and decrypt the phone number?

2. How do I call on the AES encryption key when a user submits their data via form and stores into our MySQL database?

3. When I want to descrypt that information for our internal customer service agents - how do they in turn call on the AES key?

I realize this is probably very simple but please don't insult. I am trying to learn best practice for how to move forward with any type of encryption whatsoever. Something (to this point) we have not had need for.

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

To circumvent the system, decrypt the data and access the information you'd have to be infected with a key-logger or trojan that scoured you cookies during that login session, otherwise the server owner nor a client without the username/password combination can use the data in the database without brute forcing it. Using AES 256-bit and strong passwords (12+ characters, A-Z, a-z, 0-9, symbols, etc) and you've got yourself a fairly difficult to breach solution, or at least one that would be painful to attempt.

Each account has a lockout feature, so if you try to login via the web too many times and fail, the account is locked out. All PHP pages encode/decode parameters to prevent SQL injection attacks and validate a PHP session is active and matches the last session tracked during you login, and also validates your encryption key works. Each time you login or visit the login page, the previous session is invalidated or if your session times out it is also invalidated. Even with all those layers its fast and prevents people from using PHP scripts that output JSON using fabricated POSTs to scripts and SQL injection attacks. It also limits the ability for the server owner/administrator to decrypt and read your information if its stored on a shared provider, etc.

I actually ended up going this route:

I encrypt the initial data with a salted hash which is stored in the database itself (and is unique to every record stored). I then take that 256bit AES encrypted string and run it through RSA encryption with my public key which sits server side.

in order to decrypt, I have to upload a temporary file with my private key and retrieve the necessary data.

quite secure in my opinion.