I'm writing a client - server model ( client is a script on a server that gathers data and sends it via REST to the server ) and want to encrypt the data that is sent.
At the moment I have a function that generates the a random key, which adds time from a specific timezone - IP-HOSTNAME-YEAR-MONTH-DAY-HOUR-(MINUTE/2)
Each part of the key is ran from 3,000 - 10,000 times trough a SHA256 and finally the 128 bit key is generated. Script all in all takes ~0.8 - 1 second to complete.
Data is encrypted via AES , using parts of the 128 bit key for the key and iv.
The server script, listens for any connections, verifies if the IP address is listed and then proceeds to decrypt the data (using the same method to generate the key and iv )
My question is: - Am I reinventing the wheel ? - Is there a better practice to generate a dynamic, time limited key for data encryption ?
My goal was to have a key that is limited to 60-120 seconds and then discard it, use multiple cycles to generate the keys (thanks to reading the python way for Truecrypt ), so if any data is caught it wouldn't be decrypted "easily" . Also, the server model will have a SSL cert that it will use to encrypt the encrypted.
I was thinking of giving a static key for each client script (RSA generated), that would be used to for AES encryption.
Thank you on your honest answers and any new ideas to improve this.
Using the simplest SSL/TLS (without PKI) as transport protection for REST is probably the most effective way to get the wheel right the first time.
Beside that, you should clarify a few topics. For instance:
Only if you have troubles in setting up SSL you should consider rolling up your own protocol.