Securely storing AES key with public key cryptography

Question

Security newbie here

I have a bash script that recursively enumerates all files and directories from a given path (say /home/user) and encrypts individual files and stores them into another directory (say /media/backup) maintaining the directory structure. I'm using GPG's symmetric key (AES 128) encryption for the purpose.

Now the problem is that GPG prompts me to enter a password for every file that is to be encrypted. Since there are multiple files, this isn't feasible. So the solutions I could think of are -

1. Prompt user to enter the key, and store it in a variable, and use that variable in the script for password (with the echo $password | gpg ... --passphrase-fd 0 --batch option). The user has to memorize the password.
2. Create a new public/private key identity with GPG. Create a new text file containing the password and encrypt it with the public key of this new identity and store it locally. Now in the script, decrypt this password file and use the password thus decrypted. Again in this case, the user enters the (memorized) private key password once.

To me, both the solutions seem similar (user has the final piece required to decrypt the files). I would like to know if one solution is better than the other, or even if they both are insecure; and in that case what should be the ideal solution.

The threat model here is, if my encrypted files & my system is compromised and an adversary gets user/root access to my system, they shouldn't be able to decrypt the files without the memorized password.

Edit: The person posting this question (https://stackoverflow.com/questions/3491481/encrypting-large-files-using-a-public-key) claims that symmetric encryption of files and then asymmetric encryption of the key is the proper way to do it. Does that imply #2 is the preferred way?

Answer 1

Overall, the better solution of the two is #2, but not just because of its security properties. More so because of user convenience. Let's go over why.

Option #1: The user's (potentially weak) password is stored in a variable and used n times, where n is the number of files that you're dealing with. Storing it in memory for such a long time could potentially increase the risk of it being leaked or compromised.

Option #2: Assuming you use a relatively fast asymmetric encryption algorithm (ECC), there should be really no time penalty for using this option. For encryption, the user's input is not needed as the public key is used. The private key is stored encrypted, so for decryption, the user enters a key once to unlock the private key. Of course, in this case, the private key has the potential of being compromised from memory, but the risk only exists when decrypting.

The main question is this. Do you want your user to be entering his key more, or less? The obvious answer is of course, less, and so scheme #2 is the better option.

(Also, consider running the user's password through a key-derivation function (e.g. scrypt or argon2) before using it as an encryption key.)

EDIT:

Apparently, I had misread your second option and assumed that you were using asymmetric encryption to encrypt the files. In that case, I would recommend using what I assumed you had meant.

1. Generate an elliptic-curve public-private key-pair.
2. Encrypt the private-key (symmetrically) with a user-defined password that has been run through a key-derivation function.
3. On encryption, use the public-key to automatically encrypt the user files without needing user input.
4. On decryption, the user-password is needed to derive the key to decrypt the private-key that would subsequently be used to decrypt the data.

To ensure proper confidentiality, authenticity, and integrity, I would use something like NaCl's crypto_box to implement my encryption.