3
$\begingroup$

I am writing a PHP application that requires files to encrypted using AES-256-CBC.

I have two options:

Option #1

  1. Generate a totally random AES key => User Key
  2. Generate another totally random AES Key => File Key
  3. Use File Key to encrypt the file.
  4. Use the User Key to encrypt the File Key and store the File Key also in the encrypted file.
  5. Send the File and User Key to the user (User Key encrypted using the user's Public Key)

Option #2

  1. Use a KDF function to derive a AES key from user input password => User Key
  2. Generate another totally random AES Key => File Key
  3. Use File Key to encrypt the file.
  4. Use the User Key to encrypt the File Key and store the File Key also in the encrypted file.
  5. Send the File to the user. User already knows the password. Else if user didn't enter a password but would like a KDF based key, we generate a password and use it to derive the User Key and when sending the file we send this password also (encrypted with their public key).
  • Though not mentioned here, I am adding HMACs to the file to validate authenticity too. But it's irrelevant for this question.

Is using KDF insecure compared to directly generating key?

(I'm worried coz the File Key is stored in the file, if a hacker knows the KDF algorithm I use, they may be able to identify the password using brute force).

Also on another note, is there any standard file format to store AES encrypted files? Currently it seems like openssl encrypted files can be opened only by openssl, and AESCrypt encrypted files can only be opened by AESCrypt.

We would like these encrypted files to be decryptable by the client and if there was some common tool out there, it would make life for the client much easier.

$\endgroup$
2
  • 1
    $\begingroup$ You miss the point that user passwords are generally bad and can create weak points, to countermeasure one uses Password-based KDFs. KDFs are usually preferred to increase the quality of random like HKDF's extract and derive multiple keys from a single one. Storing encrypted keys together with the file is a common practice in encrypted file systems where the security mainly relies on the user's password. $\endgroup$
    – kelalaka
    Commented May 1 at 9:02
  • $\begingroup$ If you know the format you can write your library for decrypting openssl encryption and it had already python ports. $\endgroup$
    – kelalaka
    Commented May 1 at 9:20

1 Answer 1

2
$\begingroup$

KDF's aren't inherently insecure. However, password based encryption is generally thought to be insecure within many situations. Users do generally not enter passwords that have enough bits to avoid dictionary attacks. When performing password based encryption is it therefore very important to use a good password based key derivation function (PBKDF) such as Argon2 with a large work factor and ample amount of memory. Furthermore, I would certainly have something that tries to guess the security in bits of the password and report that to the user.

In case you can rely on a previously established and trusted public key then simply wrapping a random key and sending it to the other party should probably be preferred. The other party can then use a password to access their own private key. However, it is important to remember that this allows anybody to send encrypted files to the user; the public key should not be considered a secret for obvious reasons. So this kind of encryption is generally combined with signing. This is a pretty big difference between the two strategies that you are proposing.

Known protocols that already implement a sign & encrypt strategy are the CMS and PGP container formats. For a more modern format you could take a look at NaCL or something similar. PGP also allows for password based encryption and there is some support for that in OpenSSL as well. However, you should consult the documentation for setting up the PBKDF correctly and making sure that the files are indeed authenticated.

$\endgroup$
3
  • $\begingroup$ Well written, thank you. Also is there any point rotating keys in the file if each file is encrypted using a different key? $\endgroup$ Commented May 2 at 2:14
  • 1
    $\begingroup$ @MathewParet No, I would not say so. The main issue is that some modes of operation, and GCM in particular do have relatively low (security) limits on message size. But even then you could just use another nonce. And yes, you can of course also rotate the key rather than changing the nonce, but I don't see how that would add any kind of security. Using different keys for each file makes much more sense. $\endgroup$
    – Maarten Bodewes
    Commented May 2 at 11:13
  • 1
    $\begingroup$ I would argue option #2 should be preferred unless option #1 is referring to ECDH rather than RSA. Then you can avoid signatures like Noise. Option #1 is also more complicated if you want post-quantum security. $\endgroup$ Commented May 2 at 17:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.