Score:0

GPG - Bad Passphrase when using a signing key

ng flag

I'm using duplicity (via duplicity-backup.sh https://github.com/zertrin/duplicity-backup.sh - no longer under development or supported, but it's a convenient wrapper for duplicity), which I've been running for a couple of years for my off-site back-ups.

As of the beginning of Feb 2023 they've been failing with the following message:

===== Begin GnuPG log =====
gpg: WARNING: server 'gpg-agent' is older than us (2.2.4 < 2.2.19)
gpg: Note: Outdated servers may lack important security fixes.
gpg: Note: Use the command "gpgconf --kill all" to restart them.
gpg: encrypted with 4096-bit RSA key, ID XXXXXXXXXXXXXXXX, created 2020-09-16
"duplicity_enc (Key for duplicity encryption)"
gpg: public key decryption failed: Bad passphrase
gpg: decryption failed: No secret key
===== End GnuPG log =====

There seem to be a couple of possible culprits. The first line regarding 'gpg-agent' is older than us may be relevant? Can't get to the bottom of it though. I thought I might have more than one version of gpg-agent running, but the only one I can find is v2.2.4. Might be a red-herring.

Secondly, the script uses --pinentry loopback - though I believe this is the default setting as of gpg2.2.*. The reason I'm thinking about the loopback option is because, if I check my keys so as to be prompted for the password, once I've entered it the script runs without error. However, this is running as a cron task overnight, so I can't be manually entering the password. I'm actually using a signing key which the script has the password for.

I'm using duplicity 1.2.2

Something looks like it's updated late January, but I don't know what. Any help would be hugely appreciated.

Pilot6 avatar
cn flag
Are you using Ubuntu?
Meatychunks avatar
ng flag
@Pilot6 - yes - Ubuntu server 18.04
Score:0
ch flag
ede

duplicity man page has a section "A NOTE ON SYMMETRIC ENCRYPTION AND SIGNING"

Signing and symmetrically encrypt at the same time with the gpg binary on the command line, as used within duplicity, is a specifically challenging issue. Tests showed that the following combinations proved working.

  1. Setup gpg-agent properly. Use the option --use-agent and enter both passphrases (symmetric and sign key) in the gpg-agent's dialog.
  2. Use a PASSPHRASE for symmetric encryption of your choice but the signing key has an empty passphrase.
  3. The used PASSPHRASE for symmetric encryption and the passphrase of the signing key are identical.

these can be 1:1 applied to using an encryption key and a different sign key. key take away is. duplicity can only be provided with one PASSHRASE env var.

if you want to use the gpg-agent, add duplicity option --use-agent, remove --pinentry loopback as it is set when needed by a current duplicity already.

on a side note. you may consider to switch to duply frontend, which is still maintained. by me ;)

good luck.. ede/duply.net

Meatychunks avatar
ng flag
Thanks for your response. Unfortunately, these are unattended backups from a server, so no DE from which to run duply... My current setup is to pass the passphrase of the signing key - which is different to the passphrase of the encryption key, so that doesn't seem to fit any of the three scenarios above. This setup has been working without fault for more than two years - I'm trying to pinpoint what might have changed on my server to upset things.
ch flag
ede
did you get to the bottom of it? as far as i can see using the agent should allow you different passphrases which are then cached in memory.
Meatychunks avatar
ng flag
No - in the end I resorted to using the same password for both keys. Far from ideal and no idea why this worked without issue previously, but needs must...
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.