I am encrypting a string using:
$gpg = new gnupg();
putenv("GNUPGHOME=/var/www/.gnupg");
$gpg->seterrormode(gnupg::ERROR_EXCEPTION);
$gpg->addencryptkey($fingerprint);
$encrypted = $gpg->encrypt($data);
echo "Encrypted text: \n<pre>$encrypted</pre>\n";
The output of which works correctly, but I am having problems decrypting this output back to a string.
In order to decrypt this in CLI I have to use
gpg-agent --daemon --verbose gpg --homedir /var/www/.gnupg
(I get a socket connection error if I don't include the gpg-agent stuff before gpg)
I then enter my passphrase and and CTRL+D for end of file, and the text string is correctly decrypted.
When I try the same decryption in php using gnupg_decrypt I just get decrypt failed. Is there something I can do to disable the gpg-agent as I've tried adding no-agent etc to the conf file but it appears to have no effect but I think this may be the problem.
All files are set to match the owner of the process that is run from the php file, and permissions seem correct as everything else is working okay except for interaction with gpg-agent.
This decryption needs to happen silently as a php function as it forms part of an overnight automatic update system.
Any help much appreciated.
Related
I will be receiving PGP encrypted files from a customer through sFTP - I already have a process to automate pulling of files. Once I receive the encrypted file, I'd like to automate decryption.
I created a key pair with GoAnywhere OpenPGP Studio (public key will go to customer). I want to use the private key along with the secret passphrase in a batch file script that will run as a scheduled task in Windows Task Scheduler. This is my script:
gpg --keyring "C:\UserFolder\.openpgpstudio\keys\pubring.pkr" --secret-keyring "C:\UserFolder\.openpgpstudio\keys\secring.skr" --batch --yes --passphrase-fd "secretPassPhrase" -o "D:\FilePath\testPGP.txt" -d "D:\FilePath\testPGP.txt.pgp"
exit
When I try to run my script, there are still some manual steps needed to decrypt files - there are a couple issues I faced:
When executing the batch file, a command prompt window opens with the same script I have in my batch file. For decryption to occur and output a text file, I have to hit Enter. This is not automatic and would cause the scheduled task to get stuck.
Even though I am using the --passphrase-fd option, there are times when I am still prompted for the passphrase - this passphrase popup would also cause the scheduled task to get stuck running.
Is there a way to bypass these two manual steps so that my script is fully automated?
Follow up question: Does the -d option accept wildcard characters so that I can just decrypt any found file with a .pgp extension, and am I able to use the -o option to output a .txt file of the same name as the .pgp file?
--passphrase-fd option should be used with file descriptor (i.e. number like 3, 4, 5 and so on), not the password string. You should use --passphrase option, adding --pinentry-mode=loopback. Currently most likely it works since password is asked via popup and cached.
-d with wildcards doesn't work, however you may use simple script to iterate over all files with pgp extension
I do sign commits with git, and it's a big problem that I can't enter gpg key passphprase from anywhere except CLI. If I'll do commit in vscode for example, it will fail. So I've came up with idea to just simply input passphrase from CLI, and cache it for some period of time.
I'm using fish shell in here so here's a config:
set -x GPG_TTY (tty)
eval (gpg-agent --daemon --allow-preset-passphrase --default-cache-ttl 43200)
As I understand I need to enable to preset the passhprase for the agent. So now what's next?
I've tried to preset a key like this, but it fails:
$ echo mypassphrase | /usr/lib/gnupg2/gpg-preset-passphrase -c E2AB66331DA5CA780B7B1FA5D4BF11DA1E39EDFF
gpg-preset-passphrase: caching passphrase failed: Not supported
I've googled everything I could, but no one is answering this question anywhere. Would be nice to have something like ssh-add, you just add a private key, and enter password, wonder why gpg-agent haven't adopted this nice design.
Seems to be solved. There's a need to add couple of things to ~/.gnupg/gpg-agent.conf:
default-cache-ttl 46000
pinentry-program /usr/bin/pinentry-gtk-2
allow-preset-passphrase
Reload gpg-agent
gpg-connect-agent reloadagent /bye
We recently switched over to Ubuntu 16.04 and there for php 7.0
No i run in to problem with one of our php scripts, this script updates ripe using the mail interface of ripe and send GPG signed mail to them, witch they use for authentication. But now the php cli starts to prompt for a password to use with the key. How can i prevent this passphrase question i tryed to remove the passphrase from the key but this didn't help.
my php code looks like this:
$gpgkey = "some thubprint of a key";
$gpgpwd = "Secret";
$res = gnupg_init();
gnupg_addsignkey($res,$gpgkey,$gpgpwd);
$updatemessages = "test";
$signedupdatemessages = gnupg_sign($res, $updatemessages);
Hope some knows the sollution
With kind regards,
Bas van den Dikkenberg
Ubuntu 16.04 ships a rather recent version of GnuPG, which does not allow setting a passphrase without pinentry without further hassles. This is because the rather large (and thus prone to security issues) GnuPG application should not be able to access private keys and passphrases, thus these operations are extracted to the smaller gpg-agent (which is now querying for the passphrase).
Removing the passphrase/setting it to an empty one should work out well, be sure to set the passphrase for the proper user (GnuPG has per-system-user keystores).
The "GnuPG-2.0-way" of setting a passphrase is using the gpg-preset-passphrase utility, which is usually installed in /usr/lib/gnupg2/gpg-preset-passphrase for Debian and derived distributions. You need to allow this operation by adding allow-preset-passphrase to ~/.gnupg/gpg-agent.conf, and run
/usr/lib/gnupg2/gpg-preset-passphrase -c [keygrip]
while providing the passphrase on STDIN (do not use echo or the -P option, using both ways all other system users can read the passphrase!). The keygrip can be obtained by running gpg2 --with-keygrip --list-secret-keys.
I'm trying to decrypt a file using gpg and getting this error:
$ gpg --no-tty --batch --verbose --decrypt --passphrase foo file.enc
Version: GnuPG v1.4.11 (GNU/Linux)
gpg: armor header:
gpg: CAST5 encrypted data
gpg: encrypted with 1 passphrase
gpg: decryption failed: Bad session key
I tried to reload the gpg agent, no luck:
$ gpgconf --reload gpg-agent
How to solve that?
For the record, if somebody will encounter this problem, too:
The problem was, that the encryption was done using gpg version 1.4.11 and the decryption was using gpg version 2.0.22.
After upgrading the encryption to gpg2 (2.0.17), everything worked fine.
I found this, which seems to be the magic that I could not find anywhere else:
Try adding --pinentry-mode loopback to your command. Maybe there is a
problem with your installation / pinentry program so that it does not start or
you are accidentally using a dummy / test pinentry which provides the wrong
passphrase.
I encrypted my file with a passphrase file in batch mode. When I tried to decrypt my file I got the dreaded "bad session key" message.
I created a passphrase file with Vim for Windows, and Vim left \r\n at the end of the text line even though I did not hit carriage return. gpg ignored the \n but retained the \r as part of the passphrase!
Vim for Windows can be induced to not leave \r\n, but it is easier to just use Notepad without a carriage return at the end of line. Best to check your passphrase file with a hexdump to be sure. There are other ways to get hurt by \r\n issues when supplying the passphrase using the command line, so be alert to it.
I would like to use GnuPG´s decrypt command without any user interation. The script's --passphrase-fd argument seems exactly what I need. But I don't know how it works - haven't found examples.
Could anyone give me an example of such a command, on both Windows and UNIX environments?
(FYI, I'm using GnuPG 2).
Thanks already :)
In order to use the gpg option --passphrase-fd in GnuPG v2, you must specify the --batch parameter. I will first explain how --passphrase-fd works, and then get to the examples.
--passphrase-fd tells GnuPG which file descriptor (-fd) to expect the passphrase to come from. The standard file descriptors are STDIN (0), STDOUT (1) and STDERR (2). For the context of this question, you would normally only be concerned about STDIN (0).
You didn't specify where you want the passphrase to come from, so I will demonstrate the usage of STDIN (standard in) in a variety of ways.
--passphrase-fd 0 tells GnuPG to retrieve the passphrase from input into the current shell; so for example if you want GnuPG to get the passphrase data in the very next line of console input, the command and output would be like so:
gpg2 --batch --passphrase-fd 0 --armor --decrypt /path/to/encrypted_file.pgp
<next line of input is passphrase followed by hitting enter>
gpg: encrypted with 1024-bit RSA key, ID EC18C175, created 2013-10-26
"testkey4321 (4321) <test#4321.com>"
this is a test... this is only a test...
In the above example, the passphrase was provided via file descriptor 0 (STDIN) - which we provided by entering it on the shells current standard input.
In the next example, we will tell GnuPG to retrieve the passphrase from input into the current shell that is actually the output of another command (echo, in this case, which merely "echos" what you tell it to):
echo "mypassphrase" | gpg2 --batch --passphrase-fd 0 --armor --decrypt /path/to/encrypted_file.pgp
gpg: encrypted with 1024-bit RSA key, ID EC18C175, created 2013-10-26
"testkey4321 (4321) <test#4321.com>"
this is a test... this is only a test...
Another example that dumps the contents of a file that contains the passphrase to STDIN -
cat /path/to/file_with_passphrase | gpg2 --batch --passphrase-fd 0 --armor --decrypt /path/to/encrypted_file.pgp
gpg: encrypted with 1024-bit RSA key, ID EC18C175, created 2013-10-26
"testkey4321 (4321) <test#4321.com>"
this is a test... this is only a test...
In summary, --passphrase-fd just tells GnuPG that you want to feed it the requisite passphrase via a standard file descriptor; the difference between GnuPG v2 and GnuPG is merely the --batch parameter.
The above examples should work the same in Windows and *nix environments, with the only difference being that in Windows - depending on your configuration and version - you will have to replace cat with type in order to dump the contents of a file to STDIN.
kylehuff's answer still wouldn't work for me, with gpupg still popping up a password prompt.
According to https://wiki.archlinux.org/index.php/GnuPG#Unattended_passphrase with gnupg version 2.1.0 and higher, you need to do additional steps to support --passphrase-fd
First, edit the gpg-agent configuration to allow loopback pinentry mode:
~/.gnupg/gpg-agent.conf
allow-loopback-pinentry
Restart the gpg-agent process if it is running to let the change take effect.
Second, either the application needs to be updated to include a commandline parameter to use loopback mode like so:
$ gpg --pinentry-mode loopback ...
Using GPG4win/gpg 2.2.3: to use the passphrase-fd 0 and bypass the prompt, I can confirm that the following works:
--pinentry-mode loopback
As I've had to recently figure this out myself I thought it might be worth chiming in.
The answer by kylehuff is very good if you're decryping files, however, if you've need of input/output redirection, such as piping, here's an example of using a non-0 file descriptor to pass the passphrase.
#!/usr/bin/env bash
# Set some variables for easy modding
Var_fd='9'
Var_pass_location="/path/to/passphrase.file"
Var_gpg_decrypt_opts="--passphrase-fd ${Var_fd} --decrypt"
Var_output_location="out.txt"
Arr_string=( "$#" )
# Open file descriptor and shove the passphrase file into it
exec ${Var_fd}<${Var_pass_location}
# Pipe input array though gpg and append to output file
cat <<<"${Arr_string[*]}" | $(which gpg) ${Var_gpg_decrypt_opts} >> ${Var_output_location}
# Do not forget to close the file descriptor
exec ${Var_fd}>&-
Do be warned, outside of special use cases, that saving your private keys passphrase is generally seen as a bad idea or bad security practice. -Also please don't forget to close the descriptor when finished so that your passphrase isn't accessible via that method anymore.- Often I've seen advised in these use cases to use specifically non-passphrase protected keys but that's totally your choose. If you like the above code then you may want to also checkout the script I debugged for key generation either unattended or attended because it covers even less commonly used gpg file descriptor options.
Edits/updates
So I've been debugging the bulk decryption operations and have evidence to show that file descriptors seem to close automatically or perhaps it's auto closed by GnuPG. Check build 152 all the way at the bottom of the raw logs, just before diff checks, you'll find that the first block of encrypted data ate the passphrase leaving the next two blocks of data without a valid passphrase. The related scripts in this operation are ; first the script_decrypt.sh build script sets the test key's passphrase to file descriptor 9 as shown in above examples, then the Helper script is called such that it'll make use of that file descriptor... it's a funky use case but the moral of the story seems to be that what ever bulk decryption operations you plan to implement with GnuPG file descriptors will likely need to follow the steps outlined above as a whole function to properly have the file descriptors reopened. I'll be rewriting the helper script over the next few pushes so check the Travis-CI build logs greater than 152 to find if I've a solution to where file descriptors get closed...
... so that only took two tries to get things working, see the difference in build 154 both the encrypted file and raw input log match. As hypothesised the file descriptors get dumped after first usage by either GnuPG or a sub shell, thus the passphrase needs to be assigned before every decrypt command for bulk decryption to happen.
Hope this was valuable to y'all.