Comprehensive Yet Simple Guide for GPG Key/Subkey Encryption, Signing, Verification & Other Common Operations

Soon Hin Khor, Ph.D.
Code Oil
Published in
15 min readOct 3, 2024

This article simplifies the complexity of GPG by presenting concepts in sequence with the next one building on the previous one seamlessly. It reads well whether you read from start to finish or skip to the section of interest. There is an active list of ‘interesting GPG questions’ maintained at the end.

Brief Introduction of GPG

GPG stands for Gnu Privacy Guard.

GPG is critical to the security of the web. Specifically GPG covers 3 things:

  • Authenticity — signing a piece of digital content to attest its origin & content
  • Confidentiality — encrypting a piece of digital content so only the intended audience can view it
  • Trust — creating a network of people/entity/cryptographic keys you trust through ‘trust transitivity’

This guide explains how GPG achieves these 3 security properties by covering:

  • Top 10 GPG fundamental concepts
  • Top 10 GPG advanced concepts
  • Top GPG common use-cases with commands
  • Interesting GPG questions

Top 10 GPG Fundamental Concepts

  • Public/private key cryptography a.k.a asymmetric key cryptography consists of a public key, which can be shared, and a private key, which must be kept secret
  • A private key is used to create a digital signature for a piece of digital content to attest that the content ‘originated’ from the private key owner and the content has not been tempered with; anyone with the corresponding public key can verify a digital signature to attest the content origin and integrity
  • A public key can be used by anyone to encrypt digital content, which can only be decrypted by the corresponding private key
  • When you verify a digital signature or decrypt encrypted content, you don’t have to specify the key to use as information embedded in the digital signature/encrypted content tells GPG which public/private key/subkey is required (if available in your keyring)
  • Upon creation of a new main public/private key, it is best practice to generate a key revocation certificate, which you can apply to your public key should your private key be compromised or lost
  • To share public keys or to backup/transfer private keys, you can export them and then importing them into ‘keyrings’ on different media/systems. Furthermore, for public keys you can share them with independently-operated, distributed GPG key servers, for others to download.
  • When you export/import public keys, you only get public keys and subkeys (see the ‘Advanced’ section), and the digital signatures of people who “certified” (vouched) for your public key (see ‘Web of Trust’ below)
  • When you export/import private keys, you get both public and private keys and subkeys
  • GPG is a distributed security concept, i.e., there are no central authorities who vouch, blacklist, revoke keys, etc. This improves scalability and removes single-point-of-failure/trust.
  • Vouching GPG public keys (‘certification’) involves confirming the association of a person with a public key, e.g., through in-person meeting, and creating a digital signature with your private key on that person’s public key. This process is not scalable if done alone, thus one can ‘select’ a group of people whose ‘certification’ you trust, which implies trusting their ‘certifications’, and so on (trust transitivity), thus creating a large ‘web of trust’. You can limit transitivity trust by setting the ‘maximum depth’ of trust level.

Top 10 Advanced GPG Concepts

  • You can create sub keys; each for a different security purpose — encryption, signing, certifying trust of other people’s keys (listed in order of decreasing frequency of use, and increasing order of security exposure in case of key theft), the low usage frequency/high security exposure keys, e.g., certifying keys, are stored in hardware with the intent of making theft/accidental exposure less likely, while the higher usage frequency/lower security exposure keys are stored on conveniently accessible hard disks but rotated more frequently
  • When you create a subkey be it for signing, or encrypting, GPG creates a new public and private subkey pair, and associate them with the main public key with a self-signed digital signature created from your main private key [ref]. This association can be attested by verifying the digital signature using the main public key
  • You do not need to create a new revocation certificate after creating new subkeys because the certificate is related only to your main GPG public key, which holds the associations with the subkeys
  • When creating keys, set expiration to be “short” (~1 year); you can extend the expiration anytime. The “short” expiration balances the cons (people needing to get an update for your expired key constantly), and pros (people will be aware of your key being stolen/revoked sooner due to constant update).
  • Due to GPG’s distributed nature, if you modify your public GPG keys/subkeys, e.g., add sub keys, extend expiration, revoke, you need to re-export your GPG keys and send it to others or at least to the GPG key servers that others use to update keys in their keyrings. You also need to re-export your private key/subkeys for backup/safekeeping.
  • When you apply your revocation certificate, only your main GPG public key is marked ‘revoked’. Until a user requests for an update to your updated public GPG key, he/she will continue to use your ‘old’ GPG keys (including subkeys) and those will continue to “work”, i.e., he/she can continue to use the public key to encrypt/verify. The owner of the private key (an attacker who stole the key, or you, if you are still in possession of it) can still use it to decrypt and sign.
  • Even though you can specify the GPG subkey fingerprint in GPG commands, GPG will operate on the main key, as the main key has all the subkeys’ info. E.g., whether you export the main public/private key or its subkey, you get the same output; an export of both the main public/private key and its subkeys.
  • All keys from GPG key servers are considered NOT trustworthy, the key server could be malicious and hand you a key it claims to belong to someone but is not
  • You bootstrap trust by ‘directly’ verifying the association between the public key and its owner (personally ‘certify’ a public key), or assigning a ‘trust’ level to public keys belonging to people whom you trust to perform public key ‘certification’ rigorously, and in turn implying trusting the ‘certifications’ performed by keys of this group of people (trust transitivity).
  • You can also bootstrap ‘trust’ through other non-GPG trusted channels, e.g., Certification Authority (CA) for Transport Layer Security (TLS)/ Secure Sockets Layer (SSL) certificates. As CAs perform rigorous identity verification before issuing TLS/SSL certificates, you can safely ‘trust’ information published on those websites with TLS/SSL certification, such as their GPG public keys.

Top GPG Common Use-cases with Commands

  • MUST READ (applies to all GPG commands): Ensure you have modern GPG versions
  • MUST READ (applies to all GPG commands): Specify GPG keyring location
  • Prepare disposable GPG key-pair for “temporary” use encryption/decryption
  • Prepare fresh set of GPG key-pair for your long-term GPG identity
  • View GPG key-pairs
  • View GPG key-pair in file without import
  • Export GPG key-pairs: public only (for sharing), both public/private (for backup/safekeeping), only public/private subkeys (for ease of use)
  • Import GPG key: import public key (for encryption/signature verification), import private/public key (for signing/decryption)
  • Send public GPG key to key servers for sharing
  • Receive public GPG key from key servers for encrypting/signature verification
  • Modifying Keys (GPG console mode)
  • Create GPG subkey pair
  • Extend GPG key expiration
  • Delete GPG public or private key
  • Delete GPG subkey
  • Create GPG key revocation certificate
  • Revoke GPG public key
  • Encrypt file
  • Decrypt file
  • Create digital signature
  • Verify digital signature
  • Specify trust level of GPG public keys in keyring
  • Check GPG Key Details (timestamp, algo, digest-algo, etc.)

MUST READ (applies to all GPG commands): Confirm GPG Version

Run:

gpg --version

If you get an error saying gpg command not found, or your gpg is older than 2.1.17 (released in Dec 2016), upgrade. Download GPG software from official sources.

MUST READ (applies to all GPG commands): Setting the location of your GPG keyring

The GPG keyring is a file with .pbx extension. It holds your public and private keys. You can have multiple keyrings. The default is located in .gnupg/ directory of your home directory.

To select a non-default keyring when running GPG command, set the environment variable GNUPGHOME using export, which applies to all subsequent gpg commands you run:

export GNUPGHOME=<GPG_HOME_DIRECTORY>

OR

You can specify the keyring in each GPG command execution with --homedir option, which often is specified with --no-default-keyring (to avoid using keys in the default keyring)

gpg --no-default-keyring --homedir <GPG_HOME_DIRECTORY> <GPG_COMMAND> 

OR with --keyring option (not recommended because its behavior can be confusing. See CAVEATS):

gpg --keyring <GPG_KEYRING_FULLPATH> <GPG_COMMAND>

NOTE (for--keyring ):

  • You can specify multiple --keyring options

CAVEATS (for--keyring ):

  • It returns keys without private key-pair even when specifically listing key with--list-secret-keys
  • Keyrings specified inGNUPGHOME or --homedir is also passed to the GPG_COMMAND

Prepare a disposable GPG keypair for “temporary” encryption/decryption

Generate a GPG public/private key-pair by running:

gpg --full-generate-key

Best keys, at least RSA4096 (more widely supported), but preferably ECDSA (more secure).
Password (optional, since disposing key after temporary use)
Expiration (optional, since disposing key after temporary use)

Share the public key (see Export GPG Keys) for the other party to encrypt contents that you can decrypt using this private key.

Delete (see Delete GPG Keys) when done

Prepare a fresh set of GPG key-pair (for your long-term GPG identity)

Generate a GPG public/private key-pair by running:

gpg --full-generate-key

Best keys, at least RSA4096 (more widely supported), but preferably ECDSA (more secure)

Add password (store in password manager). Lose this and your GPG identity is lost FOREVER.

Set expiration (not more than 2 years since you can easily renew, see Extend GPG Keypair Expiration)

Create revocation certificate (see Create GPG Key Revocation Certificate)

Once create, check your keys (also see View GPG Keys)

# gpg --list-keys

------------------------
pub rsa4096 2024-08-27 [SC] [expires: <YOUR_EXPIRATION_DATE>]
B0D5A03D06E5CB8A1678872FE7A333F2C1D81D5B
uid [ultimate] YOUR_ID <YOUR_EMAIL>
sub rsa4096 2024-08-27 [E] [expires: <YOUR_EXPIRATION_DATE>]

Super paranoid mode

You will notice:

  • sub key for [E] , i.e., encryption
  • [SC] , i.e., sign & certify key main key

Separate your [S] and [C] keys, store the [C] key in external store, and delete [C] from local store

  • Create a sub key for [S] (see Create GPG subkey pair)
  • Export out the main key for [C] and store it in external store (see Export GPG public/private key-pair)
  • Export out the public/private GPG sub keys [S] and [E] (see Export GPG public/private sub key-pair)
  • Delete the main key, which should delete the sub keys (see Delete GPG key-pair)
  • Import back the sub keys only (see Import GPG public/private key-pair)

View GPG Key-Pairs

Use --list-keys option.

# gpg --keyring /gpg/pubring.kbx --list-keys --with-subkey-fingerprint
/root/.gnupg/pubring.kbx
------------------------
pub rsa4096 2024-08-27 [SC] [expires: 2026-08-27]
B0D5A03D06E5CB8A1678872FE7A333F2C1D81D5B
uid [ultimate] testo <testo@gmail.com>
sub rsa4096 2024-08-27 [E] [expires: 2026-08-27]
D35A0AA3C4DC76507E3AEFF8EA5356D2FCA907ED


/gpg/pubring.kbx
----------------
pub rsa4096 2024-08-29 [SC] [expires: 2026-08-29]
503A4A4692DC72170E1A3BD7052F6BCC5F9F2634
uid [ unknown] second <second@gmail.com>
sub rsa4096 2024-08-29 [E] [expires: 2026-08-29]
22BF8829DD64641C2BAD552E0CABA4A5E23AC58A

Things to note:

  • Keys appear as pub (main public key) and sub (public subkey)
  • --keyring specifies the additional keyring to use on top of default
  • You can see the keyring names /root/.gnugp/pubring.kbx (default) and /gpg/pubring.kbx and the keys/subkeys in each
  • [SC] beside the pubmeans the main key is for [S]ign and [C]ertify
  • [E] besides the submeans the sub key is for [E]ncrypt
  • For security practices, users often create a separate sub key for [S], leaving the main pub key for [C]
  • The long 40 character string associated with each pub and sub are the key fingerprints. You use them with GPG command to select the key, e.g., to show a specific key given the fingerprint. Example:
# gpg --keyring /gpg/pubring.kbx --list-keys --with-subkey-fingerprint D35A0AA3C4DC76507E3AEFF8EA5356D2FCA907ED

pub rsa4096 2024-08-27 [SC] [expires: 2026-08-27]
B0D5A03D06E5CB8A1678872FE7A333F2C1D81D5B
uid [ultimate] testo <testo@gmail.com>
sub rsa4096 2024-08-27 [E] [expires: 2026-08-27]
D35A0AA3C4DC76507E3AEFF8EA5356D2FCA907ED

To just view secret keys, use --list-secret-keys

# gpg --list-secret-keys --with-subkey-fingerprint

sec rsa4096 2024-08-27 [SC] [expires: 2026-08-27]
B0D5A03D06E5CB8A1678872FE7A333F2C1D81D5B
uid [ultimate] testo <testo@gmail.com>
ssb rsa4096 2024-08-27 [E] [expires: 2026-08-27]
D35A0AA3C4DC76507E3AEFF8EA5356D2FCA907ED

Things to note:

  • --list-secret-keys will show even non-private keys if you use --keyring option
  • --list-secret-keys will show key types sec (main secret key), ssb (secret subkey)

View GPG Key In File Without Import Into Keyring

Common use-case: You downloaded a key and wants to check its details without importing. For details about the listing see View GPG Key-pairs.

# gpg <GPG_KEY_FILENAME>
gpg: WARNING: no command supplied. Trying to guess what you mean ...
pub rsa4096 2024-09-03 [SC] [expires: 2026-09-03]
B70DFB42233E414C8DE96E3FC206FAD09FD6EE9B
uid test-0 <test-0@gmail.com>
sub rsa4096 2024-09-03 [E] [expires: 2026-09-03]

Export GPG Key-Pairs

Export public GPG keys/subkeys

Common use-case: Share the public key over email, etc.

gpg --armor --export <GPG_KEY_FINGERPRINT>

The --armor makes the output ASCII-armored. Without --armor the output is binary.

The output looks like below (the values are sample values)

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBGbNyVkBEADwfu3Q422kN7LaLWJrnhWQy3l1dY9iP8mjqH0id8d8JRzacuyq
...
...
...
=8OsT
-----END PGP PUBLIC KEY BLOCK-----

Export public/private GPG keys/subkeys

Common use-case: Move your GPG key to another computer or external storage

WARNING: Never share exports of your private GPG key

gpg --armor --export-secret-key <GPG_KEY_FINGERPRINT>

The --armor makes the output ASCII-armored. Without --armor the output is binary.

The output looks like below (the values are sample values)

-----BEGIN PGP PRIVATE KEY BLOCK-----                           

lQcXBGbNyVkBEADwfu3Q422kN7LaLWJrnhWQy3l1dY9iP8mjqH0id8d8JRzacuyq
...
...
...
=Jri2
-----END PGP PRIVATE KEY BLOCK-----

Export GPG ONLY Public/Private Subkeys

Common use-case: Export subkeys, which are less critical, and import them into more accessible media/systems, for ease of use

# gpg --armor - export-secret-subkeys john.doe@example.com

The output looks like below (the values are sample values)

-----BEGIN PGP PRIVATE KEY BLOCK-----                           

lQcXBGbNyVkBEADwfu3Q422kN7LaLWJrnhWQy3l1dY9iP8mjqH0id8d8JRzacuyq
...
...
...
=Jri2
-----END PGP PRIVATE KEY BLOCK-----

Import GPG Keys

Common use-case: Someone gives you a key through a secure ‘channel’, e.g. a website with valid certificate, a meeting with someone in person, etc.

gpg --import <GPG_KEY_FILENAME>

Note:

  • Import public or public/private GPG key-pair uses the same GPG command

Send Public GPG Key To Keyserver

Common use-case: Make your public key available through key server

gpg --send-key <GPG_KEY_FINGERPRINT>

Receive Public GPG Key From Keyserver

Common use-case: Receive public key available from key server, e.g., to update an expired key, to verify the signature of a signed digital content, etc.

gpg --recv-key <GPG_KEY_FINGERPRINT>

Optionally use --keyserver <KEYSERVER_PROTOCOL>://<KEYSERVER_DOMAIN_NAME>

<KEYSERVER_PROTOCOL> can be https or hkps

You need to get <GPG_KEY_FINGERPRING> from trusted source, e.g., from a person directly, from a website with certificate.

Example of getting GPG key fingerprint from a website with certificate that you trust

Modifying Keys (GPG console mode)

gpg --edit-key <GPG_KEY_FINGERPRINT>

Do help for a list of commands, e.g., addkey , expire , etc. Example:

gpg> help
quit quit this menu
save save and quit
help show this help
fpr show key fingerprint
grip show the keygrip
list list key and user IDs
uid select user ID N
key select subkey N
check check signatures
...

Create GPG Subkey-Pairs

# gpg --edit-key <GPG_KEY_FINGERPRINT> addkey

You’ll be prompted the type of key/algo, size, and expiration. Example:

gpg> addkey                                                                
Please select what kind of key you want:
(3) DSA (sign only)
(4) RSA (sign only)
(5) Elgamal (encrypt only)
(6) RSA (encrypt only)
(14) Existing key from card
Your selection? 3
DSA keys may be between 1024 and 3072 bits long.
What keysize do you want? (2048) 3072
Requested keysize is 3072 bits
Please specify how long the key should be valid.

Do save

Extend GPG Key Expiration

# gpg --edit-key <GPG_KEY_FINGERPRINT>

Do list-keys to see list of keys

Select key with key <KEY_NUMBER>

Do expire to change key expiry

You’ll be prompted on the expiration period. Example:

gpg> expire                                                                
Changing expiration time for a subkey.
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years

Do save

Remember to send-key (see Send public GPG key to key servers for sharing) and others have to recv-key (see Receive public GPG key from key servers for encrypting/signature verification)

Delete GPG Key

Delete GPG Public Key

# gpg --delete-key <GPG_KEY_FINGERPRINT>

You will be prompted whether you want each key/subkey to be deleted

Delete GPG Private Key

# gpg --delete-secret-key <GPG_KEY_FINGERPRINT>

You will be prompted whether you want each key/subkey to be deleted

If you delete the main secret key, when you --list-secret-keys you will see a # beside the key

# (hf1) root@orbstack:/hf1# gpg --list-secret-keys --with-subkey-fingerprint

/root/.gnupg/pubring.kbx
------------------------
sec# rsa3072 2024-09-14 [SC]
932151464E4E6667D821BF98F08980161B890C48
uid [ultimate] testo <testo@gmail.com>
ssb rsa3072 2024-09-14 [E]
5078F6933FE307D9B33C516493808AF7848537A9
ssb dsa2048 2024-09-14 [S]
3648116C52E9965346049B324AADDA641F8582FD

Delete GPG Subkeys

gpg --edit-key <GPG_KEY_FINGERPRINT>

Do list-keys to see list of keys

Select key with key <KEY_NUMBER> . You should see an ‘*’ on the selected key. Example:

gpg> key 2                                                                 

sec rsa4096/2C1E6ACBDEB7EBE3
created: 2024-09-03 expires: 2029-09-03 usage: SC
trust: unknown validity: unknown
ssb rsa4096/14A9F0ADA665F408
created: 2024-09-03 expires: never usage: E
ssb* dsa3072/D09DA15ECF9513DE
created: 2024-09-04 expires: 2024-09-25 usage: S
[ unknown] (1). test-1 <test-1@gmail.com>

Things to note:

  • To select the first key, dokey 0
  • If we do key 2 (as shown) the third key has a * beside it indicating it has been chosen

Do delkey to delete the key

gpg> delkey                      
Do you really want to delete this key? (y/N)

Do save

Create GPG Key Revocation Cert

Common use-case: Revoke public key if your private key is compromised or lost

gpg --armor --output revoke.asc --gen-revoke <GPG_KEY_FINGERPRINT>

Store this safely in a secure medium or even print it out. Caution: If stolen someone can revoke your key preventing further use.

Example

-----BEGIN PGP PUBLIC KEY BLOCK-----
Comment: This is a revocation certificate

iQI2BCABCgAgFiEEbhDyPqo0pVCOEfFAob2ZdMgE050FAmbYMn8CHQMACgkQob2Z
...
...
...
=9mPk
-----END PGP PUBLIC KEY BLOCK-----

Revoke GPG Public Key

gpg --import <GPG_REVOCATION_CERTIFICATE>

Check to confirm the pub key has been revoked

# gpg --list-keys
/root/.gnupg/pubring.kbx
------------------------

...

pub rsa4096 2024-09-03 [SC] [revoked: 2024-09-04]
6E10F23EAA34A5508E11F140A1BD9974C804D39D
uid [ revoked] test-3 <test-3@gmail.com>

Remember to send-key so others who update your key with recv-key will know about your key revocation.

Encrypt File

# gpg --output <ENCRYPTED_OUTPUT_FILENAME> --encrypt --recipient <RECIPIENT_EMAIL> <FILE_TO_ENCRYPT> 

Decrypt File

# gpg --output <DECRYPTED_FILE> --decrypt <ENCRYPTED_FILE>

Create Digital Signature

Clear Signature

# gpg --clear-sig --output <FILE_WITH_CONTENT_AND_SIGNATURE> --local-user <GPG_KEY_FINGERPRINT> --armor --sign <FILE_TO_SIGN>

Example

# cat hello.sig
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

hello world!
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEtw37QiM+QUyN6W4/wgb60J/W7psFAmbYQPwACgkQwgb60J/W
7psruw/6ArhsLzLE7j6v8b8TbQiAfPwsjCQ+606GruwP2+jipgf8sEjxsbMiegHW
orwEbhlt8faevdyJDaOGoarrS+AzoXMHv1GDUwZD4ghFoNRggHVR5nRG2rWwNT+8
r4j06uXna40wiRPVF9cNsJaLlbkzGOF8p5pjMfMVNeywfZDo8uj0BRJxgJnHH4rS
0Fe9ka3RcqW26/m+kAabvDcQWKqU9PQoGRvoq1Cau17x+vX+gV4lwtDzxFD+ypi9
5qwqRLn+PtRqmw5HC1JWXWYtJtzP77NnB4upLKw7vejCG/bteuHNIoF2wShObVs3
MuR73LK7ph5SxTSipygvqyBlpO18WqUSzNkKiUSltuRbG6MM4bJ+k5jx7MxOFucm
3PWIA4s/1eQ8bQFsB3ZMhmJk2ncwTHWz0P0cpuNlFNIFj+/LCjK08KLqjsUrguao
yfdpTbbNdqfEfWIuvw1m26sp/2GPjtpv99VvnS8rx+eqwVFKjxckYwCgWeU74fjZ
cUTMRz4q+SZcUcATO6i9dS+Ev2ToCkxH/W2sizHoMA3oFwk1UhSQ8UiHpa45l7YU
QbIs6FylSY3kUvN4e3trRpiFS6NeE8t60QXi9YFgFuhJ6gksDo5+dHJeO+1Vgtro
Ls4kZxHHwIA9i1sSQ7xLJo9ObcmuCfXYvOYYNbbNjVcMwStc6W8=
=ufFX
-----END PGP SIGNATURE-----

Detached Signature

# gpg --detach-sig --output <SIGNATURE_OF_FILE> --local-user <GPG_KEY_FINGERPRINT> --armor --sign <FILE_TO_SIGN>

Example

root@8b96e60d3f86:/# cat hello.asc 
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtw37QiM+QUyN6W4/wgb60J/W7psFAmbYQRIACgkQwgb60J/W
7pvymBAAhr75gqMu3AYv/K1EEqmaI8JGUHg+25jP8MMhtmW5QERFpitvlwCFhzBf
6I3djtKpdOTr2sldDDv/PcFlwmjS0lrWFX4AD+sVnewPYc4e14U51ftROoj09pcG
dpMDC4htsAyweBG/omhEodbRLezi25nJSO0LP/KGgA25pAasHaQqKCvIsMrepqa7
dGNPzG50q5k6y6yxyH1w58UyuYZ/uYRRs1P77IQQOB0CStccI6Sgp/5/BnFdZdVF
BrHXKbry6Qmuq96A409Ew4LHCLbZ99bM1zZ0JipV+SIa+Gf5IEtAPGV7mqEaWhv1
xXdNQ9KiGlhUo3WfmPrifxDk3AhbOYAFMr13kXnaG/nXdnbzZHsM4d3CmccUz0uC
ScRkoteL/liuOly+9R18Z0tuXsPrDanWMrwMXTR+vruViFESZPKNqpIPYBgqdsJM
FpAiEqDsJdlIWqWpTvmbGHVk0elOgbWoyhY5S1FeuGkocQdF8Iy1igCK8Yucsvp1
58bi/UlHxLZzX8lS1AFlJot+E3dOFCIKyAQDzCjQqBYdQEdhrqdzzgm4sV731fUf
xalGrMEba547BKtwPa9/0LwdZ30ZYAQgRqKZ5NLxSdQZAx++23/KRHFS3N6gM5mg
s6GiC3KZXofXaG2C7pHbqZ3x7/VWT//TWCvO1QQQfQ/Nu/1tIEo=
=0fDy
-----END PGP SIGNATURE-----

Verify Digital Signature

Clear Signature

# gpg --verify <FILE_WITH_SIGNATURE_AND_CONTENT>
gpg: Signature made Wed Sep 4 11:14:04 2024 UTC
gpg: using RSA key B70DFB42233E414C8DE96E3FC206FAD09FD6EE9B
gpg: Good signature from "test-0 <test-0@gmail.com>" [ultimate]

Detached Signature

# gpg --verify <SIGNATURE_OF_CONTENT_FILE> <CONTENT_FILE> 
gpg: Signature made Wed Sep 4 11:14:26 2024 UTC
gpg: using RSA key B70DFB42233E414C8DE96E3FC206FAD09FD6EE9B
gpg: Good signature from "test-0 <test-0@gmail.com>" [ultimate]

Set Trust Level of GPG Public Keys

gpg --edit-key <GPG_KEY_FINGERPRINT>

Once you are in the GPG console

trust

Select one of these levels:

  • 1 = I don’t know
  • 2 = I do NOT trust
  • 3 = I trust marginally
  • 4 = I trust fully
  • 5 = I trust ultimately

Once done, confirm changes and quit

Check GPG Key Details (timestamp, algo, digest-algo, etc.)

Whe you list GPG key details, they are in numeric form, to cross-reference th numbers to a list of algorithms, and digest-algorithms, see https://www.rfc-editor.org/rfc/rfc4880#section-9.1

Key in file

# gpg --list-packets <GPG_KEY_FILE> 
# off=0 ctb=89 tag=2 hlen=3 plen=563
:signature packet: algo 1, keyid 8BE1102F3A280DD7
version 4, created 1717196172, md5len 0, sigclass 0x00
digest algo 8, begin of digest 3d c6
hashed subpkt 33 len 21 (issuer fpr v4 0829993CB50BEC0EE4CE32A48BE1102F3A280DD7)
hashed subpkt 2 len 4 (sig created 2024-05-31)
subpkt 16 len 8 (issuer key ID 8BE1102F3A280DD7)
data: [4096 bits]

Key in keyring

# gpg --list-sigs
pub rsa4096 2018-10-08 [SCEA]
01038B4121AD9696550374FEC5A51742DB6249A1
uid [ unknown] https://packagecloud.io/sigsci/stable (https://packagecloud.io/docs#gpg_signing) <support@packagecloud.io>
sig 3 C5A51742DB6249A1 2018-10-08 https://packagecloud.io/sigsci/stable (https://packagecloud.io/docs#gpg_signing) <support@packagecloud.io>
sub rsa4096 2018-10-08 [SEA]
sig C5A51742DB6249A1 2018-10-08 https://packagecloud.io/sigsci/stable (https://packagecloud.io/docs#gpg_signing) <support@packagecloud.io>

Interesting questions

Q. Does expiration “increase” security?

No, if your private GPG key is compromised; the attacker can extend the expiration. Yes, because it helps other to request update for your key more frequently to realize faster that you have revoked your public GPG key.

Q. Can someone with your main public key verify the signature from your private subkey?

Subkeys are associated with main public keys, the only way the person cannot verify a signature created by your private subkey is if she/he received a version of your public key prior creation of that subkey. That can be resolved by exporting the public GPG key (with that public GPG subkey) and passing to her/him.

Q. Can you create a subkey for ‘Certification’?

No

Q. I get this error `NO_PUBKEY 6DCEB5B477160A1C`?

Whatever command you are running, it cannot find the GPG key. First, get the key, see Receive public GPG key from key servers. Next, export the public GPG key to a file, see Export GPG key-pairs into a file, nothing whether the ASCII or binary format is required. Finally, move the public GPG key file to the location where the command expects to find it.

Q. Is there a cheatsheet on the web?

https://gock.net/blog/2020/gpg-cheat-sheet/

--

--

Code Oil
Code Oil

Published in Code Oil

Attempts to find better ways to help myself, and others, understand software technology

Soon Hin Khor, Ph.D.
Soon Hin Khor, Ph.D.

Written by Soon Hin Khor, Ph.D.

Use tech to make the world more caring, and responsible. Nat. Univ. Singapore, Carnegie Mellon Univ, Univ. of Tokyo. IBM, 500Startups & Y-Combinator companies

No responses yet