Test an instance of GPG 1.4.10. Assemble a list of basic GPG commands.







- Goal
- Contents
- Brief Summary
- Summary
- Basic GPG Commands
- Notes
- Project Log









I assembled and tested a list of basic GPG commands. They are shown with examples in the Basic GPG Commands section.









I wrote a list of commands and operations that I considered to be basic necessary functionality for an RSA software implementation.

Here is the list:
- create key
- display key
- display all keys
- delete key
- export key
- import key
- export ASCII-encoded key
- import ASCII-encoded key
- sign using a specific key, producing a detached signature
- verify a detached signature, using a specific key
- verify an ASCII-encoded detached signature, using a specific key
- sign using a specific key, producing an ASCII-encoded detached signature
- encrypt a message to a specific public key
- decode an encrypted message, using a specific private key
- display fingerprint for a specific key
- display fingerprints for all keys
- use a fingerprint to retrieve the corresponding key

Notes:
- A GPG 'key' is really a keypair - a private key and a public key.
- 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.

I was able to use GPG to achieve most of this functionality. See the Basic GPG Commands section for details (and an improved list). I focused on finding workflows that relied on a key fingerprint (the best available uniqueness constraint, hard to counterfeit) and that produced readable results (i.e. printable ASCII output).

Exception: I was unable to specify a key by fingerprint when decrypting an encrypted file. I found that the public key appears to contain a subkey, to which messages are encrypted. Also, I couldn't find a way to get a key fingerprint to appear in the output of the decryption command.

In some cases, I found workarounds. I was unable to specify a key by fingerprint for verifying a signature. GPG will attempt to use all public keys in its internal database to verify a signature. However, in the event of a successful signature verification, I was able to get GPG to produce output containing the fingerprint of the relevant key. This output can then be piped and grepped for the fingerprint.




Notes section:

The Notes section contains the following parts:

- Necessary functionality for an RSA software implementation
- GPG data storage location
- GPG example output
- Signing an encrypted file
- Some notes concerning GPG key IDs













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.


Notes:
- These commands emphasise the use of real names, fingerprints, and ASCII armor.
- A GPG 'key' is really a keypair - a private key and a public key.
- 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.






1) Create key



See the "GPG example output" part of the Notes section for example output of this command.

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 = "[your name or handle]"
- 6) email address = "[your email address]"
- 7) comment = "[comment or empty string]"
- 8) confirm real name, email address, and comment = "o"
- 9) passphrase = "[passphrase or empty string]"
- 10) confirm passphrase = "[passphrase or empty string]"
- 11) [wait for random bytes to be generated]

Might be possible to use an empty string "" for email address. Haven't tested.
I didn't perform any action while random bytes were being generated. Don't know how much this helps or hinders.

Note: GPG insisted on generating a passphrase even though I chose not to. Not sure if a passphrase was actually generated or if GPG only reported that it was.

Warning: If you input a passphrase, you must record / remember it, else later you will not be able to access your key (GPG uses the passphrase to encrypt the key data).






2) Display key details




a) Display public key details



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

Example:



479D9006 is the short key ID.

Add to the command to also display the key fingerprint.

Example:



Note that the fingerprint is displayed with spaces, but is not used with spaces in commands.




b) Display private key details.



where [key] is any of the following: real name, short key ID, email address, or fingerprint. I have tested: real name.

Example:



Note "sec" instead of "pub" in the output in the first row.






3) Display details of all keys




a) Display details of all public keys



Example:



Add to the command to also display the key fingerprint.

Example:






b) Display details of all private keys



Example:



Add to the command to also display the key fingerprint.

Example:








4) Export key




a) Export public key



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

See the "GPG example output" part of the Notes section for example output of this command.

Redirect the output to a file to save the key.

Example:






b) Export private key



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

See the "GPG example output" part of the Notes section for example output of this command.

Redirect the output to a file to save the key.

Example:








5) Delete key




a) Delete public key



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

Note: This command won't work if an associated private key is stored in the GPG internal database. You have to delete the private key first.

Example:






b) Delete private key



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

Example:








6) Import key




a) Import public key



where [file_name] is the name of the file containing a GPG public key. I have only tested this command with a public key that was in GPG's binary format.

Example:



Note: It may be possible to use a file path instead of only a file name. I have not tested this.




a) Import private key



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

Example:



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






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



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

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

Notes:
- The detached signature file will have the name .
- It may be possible to use a file path instead of only a file name. I have not tested this.
- The option allows you to specify the name of the detached signature file. I have not tested this.

Example:



Note: The command can be used to view the long key ID of the public key that signed the file. Perhaps the fingerprint is not included in the signature file (ideally, it would be).

Example:








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.

Notes:
- It may be possible to use a file path instead of only a file name. I have not tested this.

Example:



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

Example:



Note: In the previous example, I think that GPG took the signature file name "foo.txt.asc" and checked for the implied presence of an original file "foo.txt", which did actually exist.

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.

Example:



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 + .






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. I have tested: real name, fingerprint.

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

Notes:
- It may be possible to use a file path instead of only a file name. I have not tested this.
- The encrypted file will be called .
- The option allows you to specify the name of the encrypted file. I have not tested this.

Example:








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:
- It may be possible to use a file path instead of only a file name. I have not tested this.

Example:



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.
- 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.

The previous part "8) Verify the detached signature of a file, checking that the signature was made by a specific key" demonstrated how to use the tools and to produce a binary result for checking that a particular fingerprint is present in the output. A similar approach can be used here to check that a specific short key ID is present in the output, although this is not as good as using a fingerprint.

Note: The command can be used to view the long key ID of the public subkey of the main public key to which the file is encrypted.

Example:






















Parts


- Necessary functionality for an RSA software implementation
- GPG data storage location
- GPG example output
- Signing an encrypted file
- Some notes concerning GPG key IDs




Necessary functionality for an RSA software implementation


I wrote a list of commands and operations that I considered to be basic necessary functionality for an RSA software implementation.

Here is the list:
- create key
- display key
- display all keys
- delete key
- export key
- import key
- export ASCII-encoded key
- import ASCII-encoded key
- sign using a specific key, producing a detached signature
- verify a detached signature, using a specific key
- verify an ASCII-encoded detached signature, using a specific key
- sign using a specific key, producing an ASCII-encoded detached signature
- encrypt a message to a specific public key
- decode an encrypted message, using a specific private key
- display fingerprint for a specific key
- display fingerprints for all keys
- use a fingerprint to retrieve the corresponding key

I was able to use GPG to achieve most of this functionality. An example: "Display key" is achieved via exporting the key.

A key fingerprint is (or should be) derived in some way from the hash of a public key. It is a shorthand way to reference the key in a manner that has a good uniqueness guarantee but is shorter than the entire key. User-assigned names can always be duplicated by a third party, who might wish to create a counterfeit key. A short key ID (the last 8 characters of the fingerprint) is insecure because it is feasible for a third party to attempt to generate another key with the same short key ID. Sadly, GPG appears to rely internally much more on the short key ID than on the fingerprint. I have attempted during this project (as much as possible) to choose GPG workflows that rely on the fingerprint.

Having finished this project and gained some experience, I think I will revise the list.

Necessary functionality: An RSA implementation should be able to do these things:
- Create RSA keypair. The user should be able to specify a file that contains entropy for use as the private key. The function "create public key from private key" should be available as a separate function. The keypair should be assigned a unique ID (e.g. an incrementing integer) that is for internal use only. It should have a user-assigned name (alterable) and a fingerprint (not alterable, derived from a hash). The name is not stored within the key - it should be assigned by the RSA software user, not by the key's creator.
- Output RSA public key. Can specify key by unique ID, name, or fingerprint. Output must be printable ASCII.
- Output RSA private key. Can specify key by unique ID, name, or fingerprint. Output must be printable ASCII.
- Import RSA public key from file. Ask for confirmation if this key has a fingerprint that is already used by another key in the internal database.
- Import RSA private key from file. Generate the corresponding RSA public key and import that as well.
- Some people may have a reason to use many private keys. Private keys should also have fingerprints for internal use.
- Sign a file using a specified RSA private key, producing a detached signature file. Can specify key by unique ID, name, or fingerprint. Output must be printable ASCII.
- Verify a detached signature file (the original file is of course needed as well). File format can optionally specify the fingerprint of the public key of the keypair that signed it. Can specify public key by unique ID, name, or fingerprint. If no key is specified, attempt verification using all public keys in the internal database.
- Encrypt a file to a specific public key. Can specify key by unique ID, name, or fingerprint.
- Decrypt an encrypted file. File format can optionally specify the fingerprint of the public key to which it is encrypted (this can obviously be altered in transit). Can specify a private key to use for verification by unique ID, name, or fingerprint. If no key is specified, attempt verification using all private keys in the internal database.
- Use a fingerprint to look up a name. Need some way to distinguish the fingerprint of a private key from the fingerprint of a public key.
- Use a name to look up a fingerprint. Need some way to specify whether the fingerprint is the fingerprint of a private key or of a public key.
- Output the list of public keys. This list should include: unique ID, name, fingerprint.
- Output the list of private keys. This list should include: unique ID, name, fingerprint.
- Delete RSA public key. Can specify key by unique ID, name, or fingerprint.
- Delete RSA private key. Can specify key by unique ID, name, or fingerprint.
- Delete RSA keypair. Can specify key by unique ID, name, or fingerprint. Need some way to specify whether the fingerprint is the fingerprint of a private key or of a public key.

Notes:
- "Output" is equivalent to "Display" and to "Export". To export, direct the output into a file.
- When importing a key (public or private), the program should ask for confirmation if this key has a fingerprint that is already used by another key in the internal database. If confirmation is granted, then the new key should not overwrite the old key. Instead, a query for this fingerprint should return both keys.
- When importing a key (public or private), the user should be able to assign a name to it. The program should ask for confirmation if this key has already been used within the internal database. If confirmation is granted, then the new key should not overwrite the old key. Instead, a query for this fingerprint should return both keys. The user should be able to alter this name later.
- A public key does not need to contain: A name, a date of creation, an email address, photo, self-signature, other people's signatures of this key, subkeys, or a comment. All of these should be handled by external systems. Simple approach: A directory for every contact that you have, which contains each of these items and their signatures.
- Subkeys should be manually created. Simple approach: Create a new keypair, publish a signed statement that states that external messages should be encrypted to this new keypair.
- The trust database should also be external. Simple approach: A text file for every contact that you have, containing their name, their key fingerprint, and any other details that you think are relevant.
- The internal database should ideally contain only printable ASCII bytes. (e.g. a text file in JSON format), so that it can be read and written using a text editor.




GPG data storage location


These are the results from this project. On your system, "/home/spiano" will instead be your home directory.

GPG stores its data in the directory:


Public keys are stored in:


Private keys are stored in:












GPG example output




Create key:






Display / output text representation of public key:






Display / output text representation of private key:










Signing an encrypted file


During this project, I tested a particular combined operation:
1) Encrypt a message to key A
2) Sign the encrypted message file using key B

An example of its use: B encrypts a message to A's public key. B then signs this message. A knows that the message comes from B, but cannot prove this to a third party without sharing A's private key. B's authorship is therefore plausibly deniable.

This could be used for a chat channel. It would allow recipients to be sure of a statement's authorship, but the author does not have to worry so much that absolutely everything he says might be held against him in the future.

Exception: One of the recipients is willing to burn his private key (or rather, this particular private key - he might have several), by publishing it along with a set of messages from the sender, in order to incriminate the sender in some way.

Alternative approach for assuring authorship in a chat channel:
- Create a new key to be used for chat.
- Delegate chat authority to it via a signed statement (which should clarify the noisier nature of whatever is signed by this key - people should e.g. trust that your published articles carry greater weight than a chat statement).
- Never type anything for which you aren't willing to take responsibility (this means not breaking the taboos or attacking the sacred cows of your culture unless you can defend yourself effectively from that culture via e.g. lawyers and/or bodyguards).

Example of using GPG to perform this combined operation:








Some notes concerning GPG key IDs


The following excerpt comes from the previous article Offline installation of a C compiler on Centos 6.9 Minimal on Kalkin. It is the "4) OpenPGP Keys" part of the Discoveries section.

4) OPENPGP KEYS

Key formats:
- There are two versions of key-material packets. Version 3 packets were first generated by PGP 2.6. Version 4 keys first appeared in PGP 5.0 and are the preferred key version for OpenPGP.
- V3 == Version 3
- V4 == Version 4
- V3 keys are deprecated.
- The key ID of a V3 key is the last section of its public modulus.
- The fingerprint of a V3 key is the last section of a hash of several pieces of information, one of which is the key.
- The fingerprint of a V4 key is the last section of a hash of several pieces of information, one of which is the key.
- The key ID of a V4 key is the last section of its fingerprint.
- If V3 and V4 format keys share the same RSA key material, they will have different fingerprints and different Key IDs.
- An implementation of RFC 4880 (e.g. GPG) should only create V4 keys. It may accept V3 keys.
- Older combinations of rpm and gpg expect V3 keys and signatures.
- For V4 keys, the short key ID is the last half of the long key ID.

Key IDs:
- Key IDs are short "names" for keys, shorter than the fingerprint or the modulus. They are used for convenience, as less typing/reading is required and they are more human-intelligible. However, they are less secure, because another key with the same key ID can be generated (on purpose or by accident).
- A short key ID, e.g. A4FF 2279, is 8 hex characters. Each pair of hex characters represents one octet (8 bits), so the short key ID consists of 4 octets (32 bits).
- A long key ID, e.g. 4E1F 799A A4FF 2279, is 16 hex characters. It therefore consists of 8 octets (64 bits).
- GPG has trouble handling two keys that have the same key ID.

The short key ID can be viewed by running:

gpg /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6

The long key ID and the fingerprint of a key can be viewed by running:

gpg --with-fingerprint --keyid-format long /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6

User IDs:
- A user ID is some text that is a human-readable identifier for a key's user.
Example: Heinrich Heine <heinrichh@duesseldorf.de>
It is of course easily forged (someone else can simply create a key or a message with the same user ID text). Digital signatures should be used to prove that a user ID is attached to a particular key/message.

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.








List of commands / operations that I consider basic:
- create key
- display key
- display all keys
- delete key
- export key
- import key
- export ASCII-encoded key
- import ASCII-encoded key
- sign using a specific key, producing a detached signature
- verify a detached signature, using a specific key
- verify an ASCII-encoded detached signature, using a specific key
- sign using a specific key, producing an ASCII-encoded detached signature
- encrypt a message to a specific public key
- decode an encrypted message, using a specific private key
- display fingerprint for a specific key
- display fingerprints for all keys
- use a fingerprint to retrieve the corresponding key

Note: Also, find out where GPG stores data i.e. the keys.


During a previous project, I learned that GPG fingerprints are not necessarily unique. Nonetheless, as a first pass, they can be useful for distinguishing between keys or looking up a particular key.

Link to previous project:
Offline installation of a C compiler on Centos 6.9 Minimal on Kalkin
- See the Discoveries section, part 4) OpenPGP Keys.



I'm going to see if I can find ways to perform all these basic operations. I'll search and read about GPG in the course of this project, in order to find possibilities for testing, but I'm not going to cite every source.

There's a particular combined operation I'm interested in:
- Is it possible for 1) a message to be encrypted to key A, and 2) the encrypted message to be signed by key B?
This would allow key B to send a secure message to key A, where A could be sure that it came from B, but B could plausibly deny (plausible to third parties) sending the message to A. A could not prove to other parties that B signed the message without revealing A's private key.
I know this operation is theoretically possible (all messages are byte strings), but is it possible using GPG 1.4.10?




Ok, number 1: create a key.

Note: A GPG 'key' is really a keypair: A private key and a public key.







Let's summarise my choices 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 = "n@a"
- 7) comment = ""
- 8) confirm real name, email address, and comment = "o"
- 9) passphrase = ""
- 10) confirm passphrase = ""

I didn't perform any action while random bytes were being generated.

Note: GPG insisted on generating a passphrase even though I chose not to.
Question: If I (the user spiano, presumably) can change the passphrase at any time, what protection does it provide (right now)?
Question: Will the passphrase prevent me viewing / exporting the key?

In the output, the words "pub" and "sub" suggest "public key" and "subordinate key". I recall that I have read something about a GPG key actually containing two keypairs, one for signing and one to which encrypted messages are sent.

In the output, "479D9006" and "36BDD5FA" should be short key IDs. Note that the public key's short key ID is the last 8 characters of the fingerprint.


Test Key 1 fingerprint:




Next: How to display keys.







Aha. Looks like GPG stores in data in:
/home/spiano/.gnupg
and stores the public keys in:
/home/spiano/.gnupg/pubring.gpg










Some reading indicates that, in GPG commands, I can use a key ID, fingerprint, real name, or email address to refer to a key.

It's best to use the fingerprint, as this has the least chance of being counterfeited. The fingerprint is a hash of several pieces of information, including the key. I note that the list-keys output includes the short key ID, but not the fingerprint. I wonder if this preference runs through the entire structure of GPG.

Some reading indicates that the fingerprint can be used with spaces (i.e. as it is printed by GPG).










Hm. Evidently, the fingerprint should be used without spaces.

The "edit key" subsystem has many options. Are all these properties stored within the text representation of a public key?

I can't see an option for "show text representation of key".


Let's test a few of these edit commands.







I entered a blank passphrase, by pressing Enter.
I was not prompted for the auto-generated passphrase. It's possible that although GPG reported generating a passphrase automatically earlier, it actually didn't.


Well, perhaps the only way to "display key" for the entire key (rather than view GPG's display of various properties of the key) is to export it as a text file and view that.



Let's take that approach.


Test Key 1 fingerprint without spaces:



Test Key 1 short key ID without spaces:



Test Key 1 long key ID without spaces:



Note: I know from prior work that the long key ID is the last 16 characters of the fingerprint.







I have a project directory named "testing_GPG_1.4.10".

Within it, make a new work directory named "work".

In the terminal, change directory to this new work directory.







So: The command that performs "display key" is , where [key] can be the real name, the email address, the short key ID, the long key ID, or the fingerprint. The email address can be used directly without quotation marks.








Hm. I find that running allows me to display keys and see all of these properties.






I assume that it displays all keys. I should create another key and confirm that this command displays both keys.



Ok: Create a second key.






Let's summarise my choices 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 = "n@a2"
- 7) comment = ""
- 8) confirm real name, email address, and comment = "o"
- 9) passphrase = ""
- 10) confirm passphrase = ""

I didn't perform any action while random bytes were being generated.



Test Key 2 fingerprint:



Test Key 2 fingerprint without spaces:



Test Key 2 short key ID without spaces:



Test Key 2 long key ID without spaces:




Test that displays multiple keys.





Yes, it does.



Next: Sign a file with Test Key 1, producing a detached signature. Then verify the signature.


I'll need something to sign. Create a new file.






Hm. Next: How to specify that a particular key should be used in the verification attempt?


[some reading occurs here]





Hm. I had expected the second verification attempt to fail.


I'll try with an absolute path.





Nope.


Hm. I can't find a GPG command or option that lets me specify a key for verification.


A hacky way to do this would be:





Note: I found that the GPG output is sent to stderr. I redirected it to stdout using , so that it isn't printed to the terminal.

Well, this approach allows me to ask GPG if a specific key (or rather key's real name) made a particular signature, and it produces a binary result (0 for failure, 1 for success).


I'd prefer to be able to specify the key by fingerprint.



[some reading occurs here]


Test Key 1 fingerprint without spaces:


Test Key 2 fingerprint without spaces:






Excellent.


I'll test with the Test Key 2 fingerprint without spaces. This should produce "0".





Good.




Clean up a bit.






Next:

- sign using a specific key, producing an ASCII-encoded detached signature
- verify an ASCII-encoded detached signature, using a specific key

[later update: realised that I didn't specify a particular key to use when signing. did this later in the project.]







Good.






Next: Export key, delete key, import key. Verify foo.txt.sig to confirm successful import.







Notes:
- I had to do some reading to find out how to export the secret key.
- The signature file foo.txt.sig appears to contain only the short and long key IDs (but not the key fingerprint, which would have been preferable).
- The exported binary key files (test_key_1.gpg and test_key_1.gpg.secret) are encoded in a format that specifies whether they are public or private GPG keys. The same command () is used to import both types of file.



Comparing the last command and its output with this earlier command and its output:




I see that GPG now adds a warning. I suspect that when a private key is deleted, its entries within GPG's trust database are removed, and that when it is imported again, the lack of these entries causes a warning to be printed when verifying a signature made by this key.







Next:
- import ASCII-encoded key


Hm.





test_key_1.txt contains the ASCII-armored public key of Test Key 1.

Planned sequence:
- Export ASCII-armored private key of Test Key 1 to test_key_1.txt.secret.
- Delete private and public keys of Test Key 1
- Attempt verification of foo.txt.sig.
- Import ASCII-armored private key and ASCII-armored public key of Test Key 1.
- Attempt verification of foo.txt.sig. Successful verification will confirm that the import has worked properly.







Interesting. I hadn't imported the public key, but the verification worked. Perhaps, if a private key is imported, GPG generates the corresponding public key.







Yup. Public key is present.


Hm. I'd like to double-check this.







Notes:
- If a private key also exists, GPG requires that the private key must be deleted before the public key is deleted.
- To verify a signature, only the public key is needed.
- Importing a private key causes GPG to construct and store the corresponding public key.




I'm going to go through the export key / delete key / import key / verify_signature sequence again, but using fingerprints instead. I'm also going to use ASCII armoring throughout, as I prefer to use workflows in which the intermediate results are readable.



Test Key 1 fingerprint without spaces:








Excellent. All worked as expected.




Let's see if I can get the fingerprint for a specific key real name.






Yup, I can.

Note: Because of the word "pub" in the output, I think that the command is a shortcut for the command .





Next:
- encrypt a message to a specific public key
- decode an encrypted message, using a specific private key


In each case, I want to be able to specify the key by real name or by fingerprint. I'll use ASCII armoring.


[some reading occurs here]






Good. Decryption successful.


Hm. Haven't found a way to see the key fingerprint in the output of the decryption.

The decryption command doesn't automatically produce an output file.

Let's see if the --output option, used with the decryption command, will produce a file containing only the message.





Yup, it does.


[some reading about fingerprints and decryption occurs here]




Test Key 1 fingerprint without spaces:


Test Key 2 fingerprint without spaces:






Notes:
- Specifying the to be Test Key 1 doesn't cause the decryption to fail. The --help message indicates that this option applies to both signing and decryption. The man page indicates that this option only applies to signing.
- The line indicates that the message is actually encrypted to a subkey.


For comparison:



I see "4F6DFEEC" in the last line there.



From earlier:






I see that 479D9006 is the key ID of the the primary key, and that this primary key was used to make the signature.


So, I think that:
1) A GPG keypair 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.










Well, that seems to be the best result I can get at the moment. The command will show the long key ID (but not the fingerprint). Note that this is the long key ID of the public subkey.




Now let's test that I can encrypt a message to a key, specifying the key by fingerprint.








Only one problem left. Need to be able to specific a particular key to use when signing. The man page indicates that the default key is the first key found in the secret keyring, and that the --local-user option can be used to specify a key. Will --local-user work, and if so, will it work with a fingerprint?







After exporting, deleting, and importing Test Key 1, it is now in second place in the secret keyring.



So: I'll specify that Test Key 1 should be used in the signing operation.





Yup, --local-user works.



Let's test the result against fingerprints.


Test Key 1 fingerprint without spaces:


Test Key 2 fingerprint without spaces:






Excellent.





Next: Test that Test Key 1 can be specified by fingerprint when signing.









Good.





I'll also test that I can specify Test Key 2 for signing.








Good.


I note that the signature file contains the long key ID, not the fingerprint.





Ah, there is one other problem.



From earlier in the log:

There's a particular combined operation I'm interested in:
- Is it possible for 1) a message to be encrypted to key A, and 2) the encrypted message to be signed by key B?
This would allow key B to send a secure message to key A, where A could be sure that it came from B, but B could plausibly deny (plausible to third parties) sending the message to A. A could not prove to other parties that B signed the message without revealing A's private key.
I know this operation is theoretically possible (all messages are byte strings), but is it possible using GPG 1.4.10?

Hm. Let's have a go. I'll encrypt a message to Test Key 2, specifying the key by fingerprint. Then I'll sign this encrypted file using Test Key 1, specifying the key by fingerprint, and producing a detached signature file.








Excellent. It works. A (in this case Test Key 2) can receive a message from B (in this case Test Key 1) that is encrypted to A's public key. Additionally, the encrypted message is signed by B. A now knows that the message comes from B, but B has plausible deniability about his authorship, as long as A is unwilling to share his private key.


This could be useful for e.g. a chat channel, or rather a chat channel where attribution of chat statements to public keys is important.

Details:
- A sender can encrypt a chat message to all registered recipients in a channel. The sender signs the encrypted message, so all the recipients can be confident that secure transit has been achieved.
- However, the sender doesn't have to worry so much that absolutely everything he says might be held against him in the future.
-- Exception: One of the recipients is willing to burn his private key (or rather, this particular private key - he might have several), by publishing it along with a set of messages from the sender, in order to incriminate the sender in some way.


Alternative approach: Create a new key to be used for chat, delegate chat authority to it via a signed statement (which should clarify the more ephemeral nature of whatever is signed by this key - people should e.g. trust that your published articles carry greater weight than a chat line), and never type anything for which you aren't willing to take responsibility (this means not breaking the taboos or attacking the sacred cows of your culture unless you can defend yourself effectively from that culture via e.g. lawyers and/or bodyguards).





Clean up:










That's the end of this project.


















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.