On an instance of GPG 1.4.10, find ways to run basic GPG commands statelessly. "Statelessly" means that commands will always produce the same output regardless of the state of GPG's internal database.







- Goal
- Contents
- Project Log









In a previous project, I installed GPG 1.4.10 on CentOS 7.6 on my computer Shovel.

Link:
Installing GPG 1.4.10 on CentOS 7.6

System details:
- Name: Shovel
- Specifications: HP 6005 Pro SFF. 3 GHz x86_64 processor (AMD II x4 B95 Quad Core), 4 GB RAM, 1 TB hard drive. Running CentOS 7.6.1810 (Core).
- More information: New computer: Shovel
- Installed items: GCC 4.8.5, Make 3.82.


In another project, I assembled and tested a list of basic GPG commands.
Link:
Testing GPG 1.4.10

I extracted, edited, and re-published the results in a separate article for convenient reference:
Basic GPG Commands







As far as I can tell, GPG is not designed to be used statelessly. However, it does have some options that allow a different home directory and keyring file to be specified in the command.

Examples:






This means that I can create a temporary home directory (containing a temporary keyring file), import a public or private key, perform an operation, and then delete the temporary home directory. This is a hacky way of achieving stateless functionality.

I recall from previous work that GPG will automatically create the keyring file, if this file is specified in the command but does not exist.


Create new project directory:
using_gpg_1410_statelessly

Within new project directory, create new work directory:
work


Open a terminal and change directory to the work directory.









I'm going to go through the commands listed in Basic GPG Commands and get them to work in a stateless manner, using a temporary directory as a gpg home directory.


Excerpt from the linked article:

List Of Commands

1) Create key
2) Display key
2a) Display public key details
2b) Display private key details
3) Display details of all keys
3a) Display details of all public keys
3b) Display details of all private keys
4) Export key
4a) Export public key
4b) Export private key
5) Delete key
5a) Delete public key
5b) Delete private key
6) Import key
6a) Import public key
6b) Import private key
7) Sign a file using a specific key, producing a detached signature file
8) Verify the detached signature of a file, checking that the signature was made by a specific key
9) Encrypt a message file to a specific public key
10) Decrypt an encrypted message file, checking that the decryption was performed using a specific private key.

The actual GPG commands are listed in the next section (Basic GPG Commands) in the linked article. I won't copy the entire section here verbatim, but I'll use its material as a starting point.







1) Create key

Existing command:


New version:


Interactive steps during key generation:
- 1) key type = "1" (RSA and RSA)
- 2) key size = "4096"
- 3) expiry period = "0" (never)
- 4) confirm expiry period = "y"
- 5) real name = "Test Key 1"
- 6) email address = ""
- 7) comment = ""
- 8) confirm real name, email address, and comment = "o"
- 9) passphrase = ""
- 10) confirm passphrase = ""
- 11) [wait for random bytes to be generated - GPG said that it would create a passphrase anyway]



Output:







Ok.






So: GPG created all the database files itself.


Compare with:










2) Display key


2a) Display public key details


Existing command:


where [key] is any of the following: real name, short key ID, email address, or fingerprint. The fingerprint should not include spaces.

Add to the command to also display the key fingerprint.


New version:



Let's see:








Hm. Ok. The

approach appears to work fine.



For actual statelessness, need to re-create the temporary home directory from scratch every time.

I'll try creating the temporary home directory, setting its permissions, importing the public key, then displaying its details.

For this, I will first need to export Test Key 1.






4) Export key


4a) Export public key

Existing command:


where [key] is any of the following: real name, short key ID, email address, or fingerprint. The fingerprint should not include spaces.

Redirect the output to a file to save the key.

New version:








4b) Export private key

Existing command:


where [key] is any of the following: real name, short key ID, email address, or fingerprint. The fingerprint should not include spaces.

Redirect the output to a file to save the key.

New version:











Cool.




Now, remove the temporary home directory.







Let's try the fully stateless approach:
- create the temporary home directory
- set its permissions
- import the public key
- display the public key's details
- delete the temporary home directory













Cool.





I'll try suppressing the output of the import command.








Good.








Ok. I'll start from the beginning again, this time focusing much more on pure statelessness (or as pure as possible).











1) Create key


Existing command:



New sequence:





Important choice (because it's used in commands later in the sequence): real name

Interactive steps during key generation:
- 1) key type = "1" (RSA and RSA)
- 2) key size = "4096"
- 3) expiry period = "0" (never)
- 4) confirm expiry period = "y"
- 5) real name = "Test Key 2"
- 6) email address = ""
- 7) comment = ""
- 8) confirm real name, email address, and comment = "o"
- 9) passphrase = ""
- 10) confirm passphrase = ""
- 11) [wait for random bytes to be generated - GPG said that it would create a passphrase anyway]









Output:














2) Display key


2a) Display public key details

Existing command:


where [key] is any of the following: real name, short key ID, email address, or fingerprint. The fingerprint should not include spaces.

Add to the command to also display the key fingerprint.



New sequence:












Output:







Further experimentation: There is an option to show the long key IDs, rather than the short ones.








2b) Display private key details

Existing command:


where [key] is any of the following: real name, short key ID, email address, or fingerprint. The fingerprint should not include spaces.



New sequence:











After some experimentation, I find that including the option causes GPG to not derive the public key from the private key. This would not be a problem, except that this then causes GPG to not display details for the private key when the command is run (although works by itself.


Example output:








Hm. Let's try not using the option.



Output:






Good.


New sequence:












Hm. Strange. The long key ID, the fingerprint, and the long key ID of the subkey are the same in the output of the and the command.

Perhaps the short key ID, the long key ID, and the fingerprint are only derived from the public key.

I had previously thought that both the public and private keys had key IDs and fingerprints. Looking back at Basic GPG Commands, in the Basic GPG Commands With Example Output section, item 3) Display details of all keys, I can see that the keyIDs are the same when either the public key details or the private key details are displayed.











3) Display details of all keys


3a) Display details of all public keys

Existing command:


Add to the command to also display the key fingerprint.


The possibility that concerns me is:
- Key A is already in the temporary gpg keyring. It has key ID A.
- I import a new key B. It has key ID B.
- Key ID A == key ID B.
- GPG overwrites key A with key B, and key A will then be missing from the list of keys.


So, I'm going to treat this command as a repeated version of command 2a) Display public key details.



New sequence:





This sequence will cause GPG to attempt to list public key details for all file in this directory that end in "public_key.txt".

Note: I've removed the option.



Output:






3b) Display details of all private keys

Existing command:


Add to the command to also display the key fingerprint.



Same approach as for 3a.


New sequence:






This sequence will cause GPG to attempt to list private key details for all file in this directory that end in "private_key.txt".



Output:







I'm going to skip 4) Export key (public, private) because, in my stateless approach, this operation is only used within 1) Create key in order to get the key out of the GPG data store.




Next is 5) Delete key (public, private), which is also no longer useful, because this operation can be accomplished by deleting the relevant key file on the filesystem.

Example key files:






Next: 6) Import key (public, private). This is somewhat useful, in the sense that it is now a preparatory step in these commands:
2) Display key
3) Display details of all keys


It will also be a preparatory step in later commands. It's probably worth explicitly documenting it.




6) Import key


6a) Import public key

Existing command:


where [file_name] is the name of the file containing a GPG public key.



New sequence:









can be used in the second command to suppress its output.

Example:





Output:






Output with suppression:







6b) Import private key

Existing command:


where [file_name] is the name of the file containing a GPG private key.

Note: Importing a private key causes GPG to construct and store the corresponding public key.




New sequence:









can be used in the second command to suppress its output.

Example:





Output:






Output with suppression:






















7) Sign a file using a specific key, producing a detached signature file

Existing command:


where [key] is any of the following: real name, short key ID, email address, or fingerprint. The fingerprint should not include spaces.

and where [file_name] is the name of the file-to-be-signed.

Notes:
- The detached signature file will have the name .
- The option allows you to specify the name of the detached signature file. I have not tested this.


This time, there's no need to specify the local user (i.e. a specific key) for signing. I'm only importing a single key.



New sequence:

A file-to-be-signed should already be prepared.












Output:
















8) Verify the detached signature of a file, checking that the signature was made by a specific key



where [file_name].asc is the name of the detached signature file and [file_name] is the name of the original file.

Add to the command to also display the fingerprint of the key that made the signature.

Use to filter the output for a specific fingerprint and to turn this into a binary result (0 or 1). This works only because the fingerprint (without spaces) will be included on only 1 line of the output.

Note: I found that the GPG output is sent to stderr. Redirecting it to stdout using stops it being printed to the terminal when using + .




Hm. No need to use this time. I can instead import a single key and see if the signature can be verified.






New sequence:

A file and a corresponding detached signature file must already be present.












Output:

hello.txt and hello.txt.asc are already present.















What if I want to test all public keys in sequence and see which one signed the file?



Hm. Need to stop if a verification attempt is successful.



Well, let's see what an unsuccessful attempt looks like. I'll use Test Key 1.




hello.txt and hello.txt.asc are already present.








Ok.

Hm.

The string "Good signature from" in the output indicates success.

The string "Can't check signature" indicates failure.





New sequence:




Note the use of semicolons around the verification command (it can fail).




Output:





Excellent.




Note: Using the , the long key ID of the signing key can be viewed.







Comparing

with

I can see that the expected long key ID is present at the end of the fingerprint.


Update:
- The long key ID is displayed in the output of . Using a lookup table that maps long key IDs to keys, the correct key could be chosen for verifying the signature, instead of attempting to use every key in a loop.













9) Encrypt a message file to a specific public key



where [key] is any of the following: real name, short key ID, email address, or fingerprint. The fingerprint should not include spaces.

and where [file_name] is the name of the file-to-be-encrypted.

Notes:
- The encrypted file will be called .
- The option allows you to specify the name of the encrypted file. I have not tested this.






New sequence:

A file-to-be-encrypted should already be prepared.











Some experimentation showed me that the option is required.



Output:





Hm. Interesting. This is the first time that I've ever seen the subkey's entire fingerprint.


How do I automatically answer "y" (yes) to the interactive prompt?

The man page says that I can use .


Hm. I was unable to get to work. I tried it in several positions within the command.



Ah well. A solution probably involves either patching GPG or using .

















10) Decrypt an encrypted message file, checking that the decryption was performed using a specific private key.



where [file_name] is the name of the decrypted file (to be created by this command) and [file_name].asc is the name of the detached signature file.

Notes:
- A GPG key contains a primary keypair and a subkeypair. The primary keypair is used for signing. The subkeypair is used for encryption. Other people's encrypted messages are encrypted to the public subkey. The private subkey is used to decrypt messages.
- You will be able to see that the short key ID in the decryption output is not that of the main public key. This short key ID will be visible in the output of as the short key ID of the subkey of the main public key.



Decryption requires the private key, so that's what we'll import.



New sequence:

The encrypted file should already be present.













Output:





Note that the long key ID that appears in the decryption output is the same as the subkey's long key ID in the key details output.





What does an unsuccessful decryption attempt look like?

Let's try with Test Key 1.










Ok.


Let's see the output of .







The long key ID is displayed. This means that, using a lookup table, the long key ID could be used to check which key to use for decryption.




What if I prefer to just try all keys and see which one works?




Here, the option allows GPG to overwrite the decrypted file if it already exists.



New sequence:





Note the use of semicolons around the decryption command (it can fail).

The OUTPUT variable doesn't appear to have preserved the newlines in the output of the decryption command.




Output:





Good.







Hm.



I'll go over the first few commands again, and see if they work without the option.


Reading back over the log, I see that I just need to do 2a) Display public key details.






2) Display key


2a) Display public key details

Existing command:


where [key] is any of the following: real name, short key ID, email address, or fingerprint. The fingerprint should not include spaces.

Add to the command to also display the key fingerprint.



New sequence:











Output:






Good.






That's the end of this project.















If you don't set permissions to 700 on the temporary gpg home directory, you will probably see this warning in the output from importing a key:



Approach for using GPG statelessly:
- store all private keys as text files in a directory.
- store all public keys as text files in a second directory.
- maintain a text file that stores records of key details: key file name, real name, fingerprint, long key ID, corresponding public / private key, long key ID of the public subkey.
- to turn the real name into a text file name, decapitalise and replace spaces with underscores. Example: "Test Key 2" becomes test_key_2_private_key.txt.


When creating a key, the email address can be an empty string.


can be used to find the long key ID of the relevant key from a detached signature file and from an encrypted file. If the file is signed, the relevant key will be the public key. If the file is encrypted, the relevant key will be the public subkey. This long key ID can be looked up in the key details text file, in order to select the correct private key for signature verification or for decryption. Alternative: Loop over all keys in storage and see if one produces a "success" message for signature verification or for decryption.

Note:
- A GPG key contains a primary keypair and a subkeypair. The primary keypair is used for signing. The subkeypair is used for encryption. Other people's encrypted messages are encrypted to the public subkey. The private subkey is used to decrypt messages.


could be used for automating responses to interactive prompts.


The short key ID, the long key ID, and the fingerprint are only derived from the public key. When GPG displays details concerning the private key, such as short key ID, long key ID, and fingerprint, these are the same as the details for the corresponding public key.


The encryption command displayed the entire fingerprint of the public subkey.


Changes from the original text:
- I have not always preserved the format of any computer output (e.g. from running bash commands). Examples: Setting input lines in bold text, adding/removing newlines in order to make a sequence of commands easier to read, using hyphens for lists and sublists instead of indentation, breaking wide tables into consecutive sections.