How do I get gpg to generate a GPG Key public ring rather than a keybox? - gnupg

I'm trying to take a public key and add it to /etc/apt/trusted.gpg.d/, but I'm getting an incompatibility issue.
I run:
gpg --no-default-keyring --keyring /etc/apt/trusted.gpg.d/example.gpg --import file.asc
Which works.
But then when I use apt-key list it says the key is incompatible.
Looking at the file types, my example.gpg is of type GPG keybox database version 1, where as the other apt keys are of type GPG key public ring.
How do I get gpg to generate a GPG key public ring rather than a keybox?

I know that this is old, but since I spent some time finding a solution, I am going to share it.
GnuPG has always been a pain, when it comes to automation and there doesn't seem to be a way, to make it use the old keyring v4 format.
However it can be done by re-exporting the key. Here an ugly one-liner with the MariaDB repo as an example:
# cd /etc/apt/trusted.gpg.d/ && wget -q -O - https://mariadb.org/mariadb_release_signing_key.asc | \
gpg --no-default-keyring --keyring=$(pwd)/mariadb.gpg --batch --import - && \
gpg --no-default-keyring --keyring=$(pwd)/mariadb.gpg --batch --output $(pwd)/mariadb.gpg~ --export --yes && \
mv $(pwd)/mariadb.gpg~ $(pwd)/mariadb.gpg; chmod 644 $(pwd)/mariadb.gpg
This can be done much easier with apt-key and its --keyring option (tested on Debian Buster 10.7).
$ wget -q -O - https://mariadb.org/mariadb_release_signing_key.asc | \
sudo apt-key --keyring /etc/apt/trusted.gpg.d/mariadb.gpg add -
If you look at the apt-key script you will find something similar to the one-liner above (but probably more robust).
Note that apt-key will complain and fail, if you use the suffix .asc instead of .gpg for the trusted file. That seems to be a bug, that can be avoided with a previous touch on the file.

I also recently stumbled across this issue, and after digging into the source code, I found pretty much the perfect solution.
You can just specify the keyring format with a prefix, so gnupg-ring: or gnupg-kbx:. In your case, the command would be:
gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/example.gpg --import file.asc

Related

How to send the password automatically in gpg's symmetric encryption?

I want to make a symmetric encryption for the file /tmp/public.txt.
gpg --symmetric /tmp/public.txt
The command will invoke the enter passphrase window,i want to send the password automatically.
My try here:
echo "mylongpasswordhere" | gpg --passphrase-fd 0 --symmetric /tmp/public.txt
The enter passphrase window still pop up, How to send the password automatically in gpg's symmetric encryption ?
Since I stumbled on this question having the same problem, I'll post the answer that actually helped me (from other SE question). The key options here are --batch --yes:
$ gpg --passphrase hunter2 --batch --yes --symmetric file_to_enc
(Taken from this question )
That way you can actually encrypt a file symmetrically supplying the key as commandline argument, although this might mean that other users of the system might see the passphrase used.
Depending on your GnuPG version (>= 2.1.0 ) you need to add "--pinentry-mode loopback" to the command.
For GnuPG version >= 2.1.0 but < 2.1.12 you also need to add: "allow-loopback-pinentry" to the ~/.gnupg/gpg-agent.conf
Your command would then be:
echo "mylongpasswordhere" | gpg --pinentry-mode loopback --passphrase-fd 0 --symmetric /tmp/public.txt
Alternatively you don't have to use passphrase-fd and the echo but can directly provide the passphrase:
gpg --pinentry-mode loopback --passphrase "somepass" --symmetric /tmp/public.txt
key="it is a long password to encrypt and decrypt my file in symmetric encryption
"
Encypt public.txt.
openssl enc -des3 -a -salt -in public.txt -k ${key} -out public.asc
Decrypt public.asc.
openssl enc -d -des3 -a -salt -k ${key} -in public.asc -out public.out
Can i draw a conclusion that openssl is a more powerful tool for encryption than gpg?

Why can't I run gpg in non-interactive mode successfully?

I'm writing a script that uses gpg to encrypt a file. During testing/experimentation with gpg from the command-line, I found some odd behavior. This works perfectly fine:
$ cat myFile.txt | gpg --encrypt -r 'jdoe#gmail.com'
gpg: B2D17635: There is no assurance this key belongs to the named user
pub 4096R/B2D17635 2016-01-31 John Doe (I am now a real person.) <jdoe#gmail.com>
Primary key fingerprint: B17F 98BA 1DA9 3FE1 A08F 1443 509D 87ED 32AF 2078
Subkey fingerprint: BB63 42DA 8FAD 194A E1C9 1F6D 39BA 73B9 B2D1 7635
It is NOT certain that the key belongs to the person named
in the user ID. If you *really* know what you are doing,
you may answer the next question with yes.
Use this key anyway? (y/N) y
�
Nϴ��[�mDZ.#�Bc���J������z�{p���%
<GIBBERISH SNIPPED>
i�)��/&N��t�Z�8�#�I<�Bq�!�K?�vQ�I�H6&+��(
But I don’t like that because I interactively had to type ‘y’. I would like it to assume “yes” and do the encryption without requiring any interactivity. So I ran the following command with the --batch and --yes switches. Why did it fail?
$ cat myFile.txt | gpg --encrypt --batch --yes -r 'jdoe#gmail.com'
gpg: B2D17635: There is no assurance this key belongs to the named user
gpg: [stdin]: encryption failed: unusable public key
The error you're receiving from GnuPG is because the public key isn't trusted/verified within your keyring. Because your OP stated that your running tests you may want to check out the code within a helper script written for my own experiments, GnuPG_Gen_Key.sh, specifically the functions copied/modded below.
#!/usr/bin/env bash
Var_gnupg_import_key="${1}"
Var_gnupg_import_key_trust="${2}"
Func_import_gnupg_key_edit_trust(){
_gnupg_import_key="${1:-${Var_gnupg_import_key}}"
gpg --no-tty --command-fd 0 --edit-key ${_gnupg_import_key} <<EOF
trust
${Var_gnupg_import_key_trust}
quit
EOF
}
Func_import_gnupg_key(){
_gnupg_import_key="${1:-${Var_gnupg_import_key}}"
if [ -f "${_gnupg_import_key}" ]; then
echo "# ${Var_script_name} reports: importing key file [${_gnupg_import_key}]"
gpg --no-tty --command-fd 0 --import ${_gnupg_import_key} <<EOF
trust
${Var_gnupg_import_key_trust}
quit
EOF
else
_grep_string='not found on keyserver'
gpg --dry-run --batch --search-keys ${_gnupg_import_key} --keyserver ${Var_gnupg_key_server} | grep -qE "${_grep_string}"
_exit_status=$?
if [ "${_exit_status}" != "0" ]; then
_key_fingerprint="$(gpg --no-tty --batch --dry-run --search-keys ${_gnupg_import_key} | awk '/key /{print $5}' | tail -n1)"
_key_fingerprint="${_key_fingerprint//,/}"
if [ "${#_key_fingerprint}" != "0" ]; then
echo "# ${Var_script_name} reports: importing key [${_key_fingerprint}] from keyserver [${Var_gnupg_key_server}]"
gpg --keyserver ${Var_gnupg_key_server} --recv-keys ${_key_fingerprint}
Func_import_gnupg_key_edit_trust "${_gnupg_import_key}"
else
echo "# ${Var_script_name} reports: error no public key [${_gnupg_import_key}] as file or on key server [${Var_gnupg_key_server}]"
fi
else
echo "# ${Var_script_name} reports: error no public key [${_gnupg_import_key}] as file or on key server [${Var_gnupg_key_server}]"
fi
fi
}
One can either trust the public key with above or use the following command to have GnuPG ignore trust issues.
gpg --armor --always-trust -r 'jdoe#gmail.com' -e myFile.txt -o myFile.txt.gpg
Note I've added the --armor option because the output in the OP looks to have missed that based off the snipped output.
You have to add --always-trust to your command:
echo "test" | gpg --batch --yes --always-trust --encrypt --armor -r "mail#example.com"
Probably better than using --always-trust is to sign the keys your are relying on once with your private key.
Then gpg won't ask again.
Also you encrypted standard input, so the ciphertext will be sent to standard output.
In most cases you want to use option --armor to produce ASCII output.

GPG key exists in the list?

I want to create a shell script and I haven't worked with it before.
There is a command for gpg:
gpg --keyserver SERVER --recv-keys KEY
The problem is that I don't want to run this command if key has been already added. Is there any method to check that key exists in keys list?
Thank you!
Run gpg --list-keys [key-id] (or the abbreviated command -k), which will have a return code of 0 (success) if a matching key exists, or something else (failure) otherwise. Don't list all keys and grep afterwards as proposed by others in the comments, this will get horribly slow for larger numbers of keys in the keyring. Run
gpg --list-keys [key-id] || gpg --keyserver [server] --recv-keys [key-id]
to fetch missing keys, possibly discarding the first gpg call's output (gpg --list-keys [key-id] >/dev/null 2>&1 || ...), as you're only interested in the return code.
Be aware that
updating keys from time to time might be a reasonable thing to do to fetch revocations
especially short key IDs should never be used, use the whole fingerprint if possible.
You can do:
[[ $(gpg --list-keys | grep -w KEY) ]] && echo "Key exists" ||
gpg --keyserver SERVER --recv-keys KEY
Additional (for apt keyring):
[[ $(apt-key list | grep -w KEY) ]] && echo "Key exists" ||
gpg --keyserver SERVER --recv-keys KEY
If apt-key is available
The correct way to do it is running the following command
gpg --keyserver hkp://keyserver.ubuntu.com -k [your-key-id]

Unattended GPG command script hangs at GPG command

I want to create an auto GnuPG key generation script for one person atm who, although they run ubuntu, does not feel comfortable using the CLI. In addition, someone else manages their computer, keeping it up to date and in good running order, so they do not have root/sudo access either. And I would really like to try and avoid doing as much as possible with instructions over the phone... been there too many times to know what a PITA that can be!
So I whipped up this script borrowing heavily from an example I found on the gnupg.org forums (I think?). But it does not seem to do anything once the gpg --gen-key --batch command is run no matter how much mouse activity is generated in 3 or 4 minutes. All the echo statements btw are just a temporary means to indicate script progress, which isn't very far atm.
#!/bin/bash
# First run give your server some work, otherwise gpg won't be able to generator random bytes.
#sudo rngd -r /dev/urandom
#no sudo so:
echo -e "\nYou need to begin moving your mouse continuously and in random patterns for as long as it takes to generate a new key. This could take a minute or two, so be patient and just keep moving the mouse.\n"
echo -e "\ngpg --gen-key --batch\n"
gpg --batch --gen-key
%echo Generating a default key
Key-Type: default
Key-Length: 2048
Subkey-Type: default
Name-Real: Firstname Lastname
Name-Comment: No comment
Name-Email: user#domain.com
Expire-Date: 0
Passphrase: abcde
%pubring foo.pub
%secring foo.sec
# Do a commit here, so that we can later print "done" :-)
%commit
%echo done
# kill the rngd task.
#sudo service rng-tools stop
echo -e "\ngpg -k\n"
gpg -k
# get key id for newly created passkey
echo -e "\nkId=$(gpg -k Firstname|grep pub|sed -r 's/^pub[ ]*2048R\/([A-Z0-9]{8,})[ ]*.*$/\1/')\n" #; echo "\$kId: ${kId}"
kId=$(gpg -k Firstname|grep pub|sed -r 's/^pub[ ]*2048R\/([A-Z0-9]{8,})[ ]*.*$/\1/') ; echo -e "\n\$kId: ${kId}\n"
# set key as the default key (if desired) by entering this line in your ~/.bashrc
echo -e "\nexport GPGKEY=$kId\n"
export GPGKEY="$kId"
# restart the gpg-agent and source your .bashrc again
echo -e "\nkillall -q gpg-agent\n"
killall -q gpg-agent
eval $(gpg-agent --daemon)
source ~/.bashrc
#create revocation cert
echo -e "\ngpg --output revoke.asc --gen-revoke $GPGKEY\n"
gpg --output revoke.asc --gen-revoke $GPGKEY
# send public key to keyserver
echo -e "\ngpg --send-keys --keyserver keyserver.ubuntu.com $GPGKEY\n"
#gpg --send-keys --keyserver keyserver.ubuntu.com $GPGKEY
I wonder if anyone can see any obvious problems or omissions feeding 'gpg' required key details?
I get the same thing even if I run the script with the sudo rngd -r /dev/random command that I need to bypass for the intended user (no sudo access).
So I guess the prob is in the key params I want to pass to gpg, but I have cross referenced them with the man page and can't seem to find what the problem might be. It is funny though that gpg does not return the error.
With batch key generation, GnuPG expects the creation commands in a file, compare with the GnuPG manual page on batch key generation.
cat <<EOT >batch-cmds
%echo Generating a default key
Key-Type: default
Key-Length: 2048
Subkey-Type: default
Name-Real: Firstname Lastname
Name-Comment: No comment
Name-Email: user#domain.com
Expire-Date: 0
Passphrase: abcde
%pubring foo.pub
%secring foo.sec
# Do a commit here, so that we can later print "done" :-)
%commit
%echo done
EOT
gpg --batch --gen-key batch-cmds
Consider the security implications of storing the passwords in a file on the hard disk. I'm not sure if you can also pipe the contents directly into GnuPG instead of storing them to a file. Try something like this:
gpg --batch --gen-key <<EOT
%echo Generating a default key
Key-Type: default
Key-Length: 2048
Subkey-Type: default
Name-Real: Firstname Lastname
Name-Comment: No comment
Name-Email: user#domain.com
Expire-Date: 0
Passphrase: abcde
%pubring foo.pub
%secring foo.sec
# Do a commit here, so that we can later print "done" :-)
%commit
%echo done
EOT

Writing gpg decrypted file to a specified outfile

I attempted to decrypt an encrypted gpg file using:
gpg -d <encrypted file> --output <outfile>
and just get a message:
usage: gpg [options] --decrypt [filename]
In contrast, if I use
gpg -d <encrypted file>
the file is decrypted, but it's written to a default file and displayed to the terminal screen. The former isn't a big issue, but the latter (display in terminal screen while decrypting) is a real nuisance. What, if anything, can be done about it?
Try gpg --output <outfile> -d <encrypted file>
The "-d" is unnecessary, this is fine:
gpg -o plaintext.txt ciphertext.asc
As for printing the decypted data to stdout, that usually only happens when the sender uses the old "for-your-eyes-only" flag. To determine exactly what is happening there, though, I'd need more detail on the version of GPG in use and possibly some information on the ciphertext.

Resources