3

I am new to GPG so I may be going about this all wrong. I have some files I would like to encrypt symmetrically using AES256, but I want to sign them with my GPG key. I need to automate this process however so I'm using --batch and I pass the symmetric key after --passphrase. Since it needs to be automated, I've disabled passphrase caching by following the steps here. However, this means my script has no way to pass in the passphrase for my GPG private key. My script will be piping the files to gpg so passing the passphrase to gpg via stdin is also not an option.

If there is no reasonable way to pass both the AES password and private key passphrase, I might consider doing this in two steps, with gpg symmetrically encrypting and then a second round of gpg for signing. It seems excessive though, considering gpg can clearly do this in one step if one passes the private key passphrase interactively.

For reference, I'm using gpg2 exclusively and don't care about backwards compatibility with gpg 1.x.

Here is the command I'm currently using for encryption. It encrypts and signs as expected, but I can only pass it the private key's passphrase interactively in the text-based dialog "window".

gpg2 --batch --passphrase <my-long-symmetric-password> --sign --symmetric --cipher-algo AES256 plaintext.txt

2
  • 1
    when i use gpg --passphrase it doesn't prompt me for the password.
    – john doe
    Aug 10 '20 at 19:45
  • @john doe It appears taking advantage of gpg-agent is a good approach to this problem. Your comment was a good clue. Aug 10 '20 at 20:49
1

I found I was going about this all wrong and I found gpg-preset-passphrase, which seems to be for prepopulating passphrases in gpg-agent, meaning gpg2 won't ask for a passphrase as long as I call gpg-preset-passphrase from my script before running the gpg2 encrypt-and-sign I posted in my question. Just make sure to start gpg-agent with a very high --max-cache-ttl to be certain the cache won't expire before the script finishes. After that, running gpg-preset-passphrase --forget is a good idea to make sure the passphrase doesn't stay cached too long.

0

You don't want to pass the password in the command. You want to input the password on stdin, so that the password isn't recorded to disk, which it will be if its passed directly in a command. If its recorded to disk, any program with permissions could dump that passphrase and easily access your private keys. The current configuration where you input the password on stdin is the recommended process.

1
  • 1
    I know passing passwords on the command line is not particularly secure, but this is running on a dedicated VM and the data being encrypted isn't particularly sensitive. In this case, I'd prefer sacrificing a little bit of security in exchange for convenience. If I did care enough about protecting the key, I'd use the --passphrase-file option, with very restrictive permissions. Aug 10 '20 at 19:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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