I am working on a tool that sends out automated reports to our clients. This specific client wants the file to be encrypted and then signed. I have tried several different methods, with hours of searching, and have not had much luck. I know GPG signs then encrypts, but does anyone know if it is possible to swap the order? And if not does anyone know of any command line alternatives that can be run in a Linux container?
Example:
gpg --always-trust --batch --yes -s -u 'signee#email.com' -r 'receiver#email.com' -o 'test.txt.pgp' -e 'test.txt'
On verify :
gpg: verify signatures failed: Unexpected error
GPG doesn't seem to allow this in a single pass.
You have two options:
use a detached signing, then you'll need to send two files: one with encrypted data and second with the signature
encrypt data in first pass and then sign it in the second. However that would also need two steps on the receiving side: first verify signatures/unwrap data, then decrypt it.
Also it could be useful to ask client what exact format he expects to receive. Just example of gpg --list-packets report-file should be helpful.
Related
I have been following the steps of the courses pre-work, including:
checking for, generating, copy/paste, and
saving the SSH keys to GitHub.
But when I am instructed to check the matching fingerprints using "ssh -T git#github.com", the prints don't match.
I've even started from the beginning clear through, but they still don't match.
Thought I'd reach out here before using my 1 tutoring.
Hopefully the screenshot showing what I see helps(link).
EDIT- I understand there's some stuff in there that shouldn't be, I was just trying things for diff results. I would just like to know where I went wrong and how to avoid it.
What you ssh is the remote site SSH key fingerprint, not you registered SSH key fingerprint.
You see (or should see if you are contacting the correct github.com) the fingerprints exposed with api.github.com/meta as explained here.
Using jq, you can add them to your ~/.ssh/known_hosts with:
curl --silent https://api.github.com/meta \
| jq --raw-output '"github.com "+.ssh_keys[]' >> ~/.ssh/known_hosts
From there, you can test your connection with ssh -Tv github.com, and check if you see a welcome message:
Hi username!
You've successfully authenticated, but GitHub does not provide shell access
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 am writing a bash script on a machine without expect.
The script automates the build of a helm (v2.9.1) chart.
I've got to the part in the script where it runs a
helm package --sign --key 'mykey' --keyring 'path/to/keyring' -d chartdir chart
and because helm prompts for the passphrase of the gpg key I created in order to use provenance files (a requirement), I cannot script around the soliciting of the passphrase, which I would like to prompt for separately as the script is part of a CI/CD build chain.
I have tried using
yes $promptedPassPhrase | helm package --sign...
and I got
xrealloc: cannot allocate 18446744071562067968 bytes (237568 bytes allocated)
I also tried plain old
echo $promptedPassPhrase | helm package --sign...
and I got
Error: inappropriate ioctl for device
I also tried script and got the same response. As I do not have expect on the server, I cannot expect my way round it, so I'm stumped as to how to automate the helm package command and am not going to use a key without a passphrase as it is bad practice.
I don't know how long this has been the case, or exactly which versions this works on, but this doc page says:
If your PGP private key has a passphrase, [...] You can set the HELM_KEY_PASSPHRASE environment variable to that passphrase in case you don't want to be prompted to enter the passphrase.
This works for me on v2.13.1. It looks like it was added in October of 2018, so my guess is that it was first available in v2.12.0-rc.1.
Although this doesn't directly answer the OP's question (since they asked about v2.9.1), it will hopefully help anyone who ends up here because they (like me the first time round) missed that line in the doc.
The gpg software supports symmetric encryption out of the box. That means, it works with a password. But apart from protecting the content it is also important to ensure the Authentication of a message. The idea is to create a hashsum of the file itself together with the password used for encryption. According to [1] a popular “Message Authentication Code” is HMAC. After entering:
gpg --hmac --armor --symmetric --passphrase pwd1 file.txt
gpg: Invalid option "--hmac"
an error message occurs that the switch is not known by the software. How can i use the MAC authentication the right way?
You can't. The reason for the error message is that type of signature is not available with GPG. You'd be better off simply signing and encrypting the file with the standard GPG method. Even if you wanted to use symmetric encryption only, then the recipient would still need to use GPG to decrypt the file. The correct command would be:
gpg -o filename.txt.asc -sear $recipient_key filename.txt
This assumes you also always encrypt to your own key, otherwise the command would be:
gpg -o filename.txt.asc -sear $recipient_key -r $your_key filename.txt
If they don't have a key, you could still sign and encrypt to your own key only and then extract the session key so you could provide that for them to decrypt the file with it:
gpg -o filename.txt --show-session-key -d filename.txt.asc
Then the recipient would be able to decrypt with:
gpg -o filename.txt --override-session-key $session_key -d filename.txt.asc
If you really must use symmetric encryption only, however, you can do it in two setps.
First sign the file:
gpg -o filename.txt.asc -sa filename.txt
Then symmetrically encrypt that file:
gpg -o newfilename.asc -a -c filename.txt.asc
The recipient would then need to run the decryption command twice; first on the symmetrically encrypted file and then a second time on the file it decrypts.
The normal --verify option is only used for checking clearsigned files or files with detached signatures.
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.