问题
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.
回答1:
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:
- Is it important that the client does not get deceived by an attacker which may be impersonating the server? If it is, then you have to properly setup PKI so that the client can authenticate the server with a certificate. Alternatively you can use TLS-SRP.
- Is it important that the server does not get deceived by an attacker which may be impersonating a real user? If it is, then you have to setup an authentication scheme: for instance HTTP Digest, SSL client certificates, TLS-SRP, etc.
- Is it important that a compromise at the client or server does not jeopardize data exchanged in previous sessions? If it is, then you have to restrict the cipher suite to cipher that offer perfect forward secrecy (DHE).
Only if you have troubles in setting up SSL you should consider rolling up your own protocol.
回答2:
Yes, and don't! Cryptographic technologies take years to develop and test for a reason, they're extremely hard to get right. It sounds like you might want to look at using RSA or some other PKI infrastructure. If I were you I would look into PyCrypto https://www.dlitz.net/software/pycrypto/. Either way, don't implement your own cartographic system it will be broken and insecure!
来源：https://stackoverflow.com/questions/10083291/encrypting-data-in-python