AES-CTR with PBKDF2 for IV for file archiving at server. Is this ok?

Question

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:

• OpenSSL

• 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..

edit -->

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

Answer 1

AES-128 for encryption because it's faster and supposedly as secure as -256

Yes and no. If you plan on storing your data for a long time, and you're worried about post-quantum attacks, 256-bit might be the better option. Grover's algorithm reduces the time complexity of cracking a 128-bit key down to about 2⁶⁴, which is likely feasible. For 256-bit it reduces the security bound to 2¹²⁸ operations which is still likely infeasible.

CTR-mode because I don't need authentication (as in CGM).

Nitpick: It's GCM (Gallois/Counter Mode).

CTR is a reasonable option, but you really will be open to malleability attacks if someone obtains write access to your device. For example, if you were to encrypt an system disk image with GRUB installed, an attacker could guess the instruction bytes as certain positions in that bootloader area (it's a known position and bootloader code is fairly static across versons) then they could backdoor your bootloader and therefore your OS once you decrypt and restore the backup.

And because (I think) does not need padding which might open up some for vulnerabilities (as CBC)

CBC vulnerabilities are mostly padding oracles, which mostly only apply in an interactive environment. They're almost certainly irrelevant in backup scenarios like this. If you're looking for a good block mode to use for storage, look into something like XTS or XTX. I don't know if OpenSSL supports them though.

All stored files have a database record where I store the IV.

Personally, I'd just prepend or append the IV to the encrypted file data.

I also store the iteration count for the IV so I can go back and recalculate with more iterations if needed.

Hmm. Ok. I don't quite understand why you need PBKDF2 to generate an IV at all.

Encryption password is hardcoded and stored in server software. Same password for all files.

This is massively insecure. Your solution has zero security as anyone who compromises the server can simply decrypt all the files.

IV is calculated with pbkdf2. @100,000 iterations, sha256, random 32bit salt.

Why? IVs are meant to be unique, and don't need to be random or secret. They exist only to ensure that encrypting multiple messages with the same key isn't insecure.

a password is needed for IV calculations as well. Can I use the same password as for encryption?

Irrelevant. Your IV should just be a unique value for each file.

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.

It really is irrelevant. Your IV does not need to be secret, and in many cases don't need to be random either, just unique.

Or have I misunderstood something?

A few things, it seems. You seem to have invented an overly complicated backup encryption scheme where something as simple as the command line openssl tool could be used (see this StackOverflow question). Don't be Dave. You seem to have a reasonable grasp of crypto concepts, but that doesn't mean you should design your own schemes for anything.