What do the files mean that may be in this directory.
[keyid].pub.asc Public ASCII armored primary key [keyid].sec.asc PRIVATE ASCII armored primary key [keyid].rev.crt Revocation certificate for primary key [keyid].ssb.asc PRIVATE ASCII armored Sub keys (should have all public keys, including primary) ssh.pub public authentication subkey exported for ssh
gpg --full-gen-key --expert
- I used RSA with the maximum keysize of 4096
- Only allow certifying, subkeys will do the rest of the work
- Certifying is the signing of other keys (including my sub-keys)
Do this step before creating sub-keys or the output may not fit.
Follow the 3.2 section from here
gpg --export-secret-key key-id | paperkey --output-type raw | qrencode --8bit --output [key-id].qr.png
Attempt to get a higher quality QR image if you can with --level H
. H didn't work for a RSA4096
key, so I ended up going with --level Q
.
I had to transfer the image to pdf for printing.
Now is a good time to update the gpg.conf from useful extras section.
List keys with gpg -k
then use key id to edit.
gpg --edit-key --expert [key-id]
This provides an interactive menu. use ?
to list commands. --expert
mode has a lot going on.
After creating sub-keys, make sure to save
!
Enter interactive menu detailed in create sub-keys
For git signing, I create an ECC key because the result is still secure, but smaller.
gpg --edit-key --expert [key-id]
addkey
10
ECC (sign only)
1
Curve 25519
1y
valid for 1 year
- This is used by github and the like to verify who I am
Enter interactive menu detailed in create sub-keys
I used the RSA with the max keysize of 4096
gpg --edit-key --expert [key-id]
addkey
6
RSA (encrypt only)
4096
RSA bits keysize
1y
valid for 1 year
- This is used for secure messages to me
Enter interactive menu detailed in create sub-keys
I used RSA with the max keysize of 4096
gpg --edit-key --expert [key-id]
addkey
8
RSA (set your own capabilities)
s
turn off sign
e
turn off encryption
a
turn On authenticate
q
finished
4096
RSA bits keysize
1y
valid for 1 year
- This is used by ssh to verify who I am
-
Revocation of the id key
gpg --output [key-id].rev.crt --armor --gen-revoke [key-id]
-
Revocation of subkeys
gpg --edit-key $primary_key_id gpg> list gpg> key $subkey_id #selects subkey gpg> revkey #revokes selected subkey
Export entire keyring
gpg --export-secret-keys --armor [key-id] > [key-id].sec.asc
Export keyring, excluding primary private key
gpg --export-secret-subkeys --armor [key-id] > [key-id].ssb.asc
Copy the [key-id].sec.asc, [key-id].ssb.asc, [key-id].qr.png, and [key-id].rev.crt files to a couple formatted, unused thumb drives, and store them for the once ayear they need to be used. Print the png as an analog copy of the primary private key. Backups of the subkeys should exist on the systems using them. The only backups of the primary private key, which is required to create new subkeys, renew expired keys, and certify other GPG users, will be on these thumb drives and in the analog qrcode image.
List the secret keys with gpg --with-keygrip -K
Then in the gpg home dir, ~/.gnupg/
by default, there will be a private-keys-v1.d
directory. The
primary private key is there named by the keygrip. rm -f [keygrip]
to delete it from the keyring.
Delete the png, sec.asc, and rev.crt files AFTER THEY HAVE BEEN BACKED UP TO THE THUMB DRIVES.
The only file necessary for the daily thumb drive to use is the ssb.asc file. This includes all of the private subkeys and the public primary key. After importing this in other gpg systems, the trust will need to be updated.
Make sure the photo of the QRCode is as straight as you can make it. Angled photos seem to have trouble. Also, get the best quality you can, avoiding shadows. I was able to get this to work, without having to use the blur.
zbarimg -1 --raw -q -Sbinary secret-key-qr.png | paperkey --pubring public-key.gpg | gpg --import
I tested with a temporary gpg directory, and used gpg --export --output public-key.gpg
to use with
the --pubring
file options.
It's useful to add keyid-format long
in ~/.gnupg/gpg.conf
so values from gpg -k
and gpg -K
use the long keyid format.
Optionally add with-fingerprint
as well to always show the key fingerprint, and with-keygrip
to
always show the keygrip
The gpg.conf is my favorite because it gives me everything I may want to see when I use gpg -k
and gpg -K
.
Key-id's are the ones on the same line as the algorithm identifier, those are used by gpg. To explicitly identify a subkey, you generally need ! at the end of the key-id. The fingerprint I think identifies the keyring; makes sense since the key-id of the primary key is the end of the fingerprint.
Keygrip's are meant to be used outside of gpg and is necessary for some of the ssh authentication.
Changing the directory of gpg commands with --homedir
will allow you to test gpg commands from a
separate keyring and avoid spoiling your main keyring.
For instance, mkdir test && gpg --homedir test import [exportedKeys file]
, then
gpg --homedir test -k
or gpg --homedir test -K
For Linux, there's gpg-agent..
For Mac, there's GPG Suite, which should help (instead of gpg-agent?) https://gpgtools.org/
For Windows, there's gpg4win, which should help, (instead of gpg-agent?) https://www.gpg4win.org/
Import private key file into gpg on another machine, then set the trust of the imported keys.
gpg import $private_key_file
gpg --edit-key [key-id]
gpg> trust
Then set trust.
After removing the secret primary key, it's nice to have an easier password for the subkeys.
To see the key-id's use gpg -k
. MAKE SURE THE PRIMARY SECRET KEY HAS BEEN REMOVED
You can test that the primary secret key has been removed with gpg -K
and sec#
showing with the
primary key, that means there's no secret key.
gpg --edit-key [primary-key-id] --expert
gpg> passwd
Then you'll get prompts for the current password, and the new password. Since the secret key has been removed, the UI will show an error. Save anyways, also shows an error, and exit. It actually works, even though the UI will state multiple times it didn't..
I had to reset my shell for the agent to ask for the new password; I like exec zsh
to replace the
running process w/ a new shell.
Using a key with the authentication
option and ssh.
-
Enable ssh support for gpg-agent
echo enable-ssh-support >> ~/.gnupg/gpg-agent.conf
-
Set the SSH authentication sock so SSH uses gpg-agent instead of ssh-agent. Goes in shell profile '.bashrc' or '.zshrc' probably. (.zshrc for me)
unset SSH_AGENT_PID if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)" fi export GPG_TTY=$(tty) gpg-connect-agent updatestartuptty /bye >/dev/null
-
Get subkey keygrip with
gpg --list-keys --with-keygrip
orgpg -k
if with-keygrip is in conf. -
Add keygrip to list of approved keys
echo [authentication keygrip] >> ~/.gnupg/sshcontrol
-
Check if the key is present in ssh's known identities (need to restart shell for profile to run commands)
ssh-add -l
. This lets you know if it's hooked up together. -
gpg --export-ssh-key [subkey-id!]
to get the ssh-rsa key for servers.
Export the ssh authentication public key specifically using gpg --export-ssh-key [subkey-id!] > ssh.pub
Import the ssh public key in github.
ssh -T git@github.com
to test against github (github must be setup first)
Add the ssh.pub
file contents to the authenticated_keys
file in ~/.ssh/authenticated_keys
Make sure the RSA / pubkey settings are enabled in the sshd_config at /etc/ssh/sshd_config
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
Disable password login, if not done so already, editing sshd_config, setting
PasswordAuthentication no
To sign locally, gpg -k --keyid-format-long
to list private keys and grab the signing
key created for git. should be the elliptic curve one, since it'll leave a smaller footprint in
git.
Then, git config --global user.signingkey [subkey-id]!
. The !
is important, otherwise the
primary key will be used (not sure what happens with multiple signing keys)
Finally, turn on signing by default if you'd like git config --global commit.pgpsign true
View global git configuration with git config --global -e
Make sure GPG_TTY is setup in your shell profile, should be already.
Export public gpg keys with gpg --export --armor [keyid] >> [keyid].pub.asc
, then upload it to
github. Ta-da
This verifies signed commits.
another time..
-
Good deep dive on GPG "anatomy" https://davesteele.github.io/gpg/2014/09/20/anatomy-of-a-gpg-key/
-
Really cool lab of GPG. Excellent resource to understand how to use GPG in multiple applicationshttps://grimoire.carcano.ch/blog/a-quick-easy-yet-comprehensive-gpg-tutorial/
-
GNU Privacy Handbook, best reference for GPG specifically https://www.gnupg.org/gph/en/manual/book1.html
-
Great GPG overview https://wiki.archlinux.org/title/GnuPG#Configuration_files
-
Understanding Sub-keys https://wiki.debian.org/Subkeys
-
Section on expirations https://riseup.net/en/security/message-security/openpgp/best-practices#use-an-expiration-date-less-than-two-years
-
Great Digital Ocean quick overview article https://www.digitalocean.com/community/tutorials/how-to-use-gpg-to-encrypt-and-sign-messages#create-a-revocation-certificate
-
Best overview of setting up git to sign commits https://docs.github.com/en/authentication/managing-commit-signature-verification/telling-git-about-your-signing-key
-
signing git commits https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits
-
ditto signing git commits https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work
-
walkthrough setting up SSH with GPG! https://gist.github.com/mcattarinussi/834fc4b641ff4572018d0c665e5a94d3#setup-the-gpg-agent-for-ssh-authentication
-
SSH with GnuPG Agent https://wiki.archlinux.org/title/SSH_keys#ssh-agent
-
ssh server setup https://www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server
-
ssh server setup https://loneidealist.medium.com/enabling-public-key-ssh-authentication-on-your-vps-fe5bfbf94822
b2 cloud storage b2 cloud storage