Hello GnuPG!
We have been experiencing random failed decryption with the message “public key decryption failed: Wrong secret key used”.
Our setup:
- azure Windows server
- Microsoft SQL Server 2019 + SSIS
- gpg4win-4.0.4.exe (gpg.exe 2.3.8)
- Windows “service” user “ssis_user” - user dedicated to run SSIS packages, not meant to be used for regular use
- 1 public-private key-pair imported in kleopatra in user “ssis_user” Windows profile
- running the decryption from SSIS in SQL Server agent job, i.e. SSIS calling a batch file which calls gpg.exe or calling the gpg.exe directly
- the key’s passphrase is passed to gpg.exe each time, to ensure the passphrase cache does not time out on us
- sample of gpg call:
C:\Program Files (x86)\GnuPG\bin\gpg.exe --batch --pinentry-mode=loopback --passphrase *** --output <File.zip> --decrypt <File.zip>.pgp
When the job runs, SSIS loops through a list of files in a directory and decrypts 1 by 1, “<File.zip>” above being a placeholder for each file.
The problem occurs randomly, as in, the decryption could run fine for a set of files, but on the next run, it would break on any of the files!
We have been able to capture the gpg.exe logs at “guru” debug-level (by using options --log-file and --debug-level) and compared the logs between a successful decryption and a failed decryption (in this case, first and second file in the directory!). We’ve noticed that after the DBG: chan_0x00000??? <- INQUIRE CIPHERTEXT, the second sequence of bytes is different - line 261, bytes 35 35 3a 02 13 vs 35 37 3a ff 4b - see in the attached comparison screenshot. Consequently, the DEK frame on line 263 is completely different!
We have not been able to reproduce it on our local dev machines.
Questions: how is that possible when there’s only 1 set of keys, and the same passphrase is being passed? what are we missing?
Thanks in advance for any kind of guidance in troubleshooting this situation.
PFS
Update: after reviewing a few other logs of successful decryption, we’ve realised that the second sets of bytes and the DEK frame changes with every file. But the same random failure keeps happening. This part of the log is common in all the failures:
DBG: internal_keydb_search: searching keybox (resource 0 of 1)
DBG: internal_keydb_search: searched keybox (resource 0 of 1) => EOF
DBG: [no clock] keydb_search leave (not found)
DBG: [no clock] keydb_release
DBG: [no clock] get_session_key leave
public key decryption failed: Wrong secret key used
decryption failed: Wrong secret key used
