I have tried to grasp enough of encryption/hashing to be able to implement a secure storage for files, server side. Once I have it down to reasonably safe I'll go over it with an expert. There is no point in calling in the expert before I understand it at a reasonable level.
Please could someone tell me if I'm doing it right, and also if there are redundant parts that I don't need.
Here is my current setup:
AES-128 for encryption because it's faster and supposedly as secure as -256
CTR-mode because I don't need authentication (as in CGM). And because (I think) does not need padding which might open up some for vulnerabilities (as CBC)
All stored files have a database record where I store the IV.
I also store the iteration count for the IV so I can go back and recalculate with more iterations if needed.
IV is 16 bytes to match 128 bit block size
Encryption password is hardcoded and stored in server software. Same password for all files.
- How long should this random password be?
IV is calculated with pbkdf2. @100,000 iterations, sha256, random 32bit salt.
- a password is needed for IV calculations as well. Can I use the same password as for encryption?
But I do wonder if pbkdf is really needed in my use case. Encryption/Decryption of files are done at the server in a queue-based manner, i.e. no user interaction is involved. So the need to slow down the hashing process doesn't seem to apply here. Or have I misunderstood something? I just need a random and unique IV, I don't need it to take time, though..
A simpler solution would be to not use an IV (i.e. IV = 0) and instead use pbkdf to create a unique encryption password for each file. The only drawback I can see with this is that my files would be in the open if someone got to the database.
With the solution described above an attacher would need booth the IV from the database and the password from the server (and of course the file to decrypt).
Would it be considered stupid to omit the IV and just use unique, random passwords instead.
edit again --->>
After contemplating a bit on Polynomials answer and comments I realize that I have to back off.
The biggest problem with the above is that it gets unsecure the moment I store the password somewhere. Only some of the files are actually sensitive. When sensible files needs encryption I'll ask the user for a password via an app both for locking and unlocking the files. The password will only be stored in memory and I'll leave it to the user to remember the password.
I'll get into some problem when more than one server can serve the app. I might solve it by not load balancing the route for the password api, so this small task is only handled by one server. Otherwise I'd have to communicate the password between the servers so all would have it in memory.
Phew.. This security thing really takes some thinking for a regular database/server/app-kind of guy. I'd better get back to some productive coding for a while and revisit this later..
Thanks in advance, //Michael