## How to verify the signatures, within GnuPG Certificates, from the command-line.

I found this to be a very specific question, with inadequate documentation elsewhere on the Web, and so I’m writing my own observations on it here. First of all, the reader should know what a certifiicate is, as opposed to just, ‘a public key’. A public key goes together Mathematically with a private key, so that either will decrypt what the other enrcypted, but in such a way that, if the public is made aware of the public key alone, they are unable to derive the private key.

This does not just get used for encryption, but also to sign documents or other electronic assets. In fact, if the RSA algorithm is being used for encryption, it may already be somewhat out-of-date, because many Web sites that have an ‘httpS://’ URL, use TLS by now, instead of SSL, the latter being insecure by today’s knowledge. However, while Diffie-Hellman key exchange is suitable for encryption, creating a shared secret between the server and client, that in turn can be used as a strong, symmetrical key for a connection, the actual verification of Web-sites still uses RSA. But, that’s a bit of an aside comment, because we’re not interested in this posting, in certifying Web-sites with an X.509 certificate. This posting is about ‘GnuPG’, which is an alternative to ‘X.509′.

A certificate is what one obtains, when a public key belonging to one person, together with certain mandatory information, is signed, using the private key of another, so that the public key of the other person can be used to validate that signature. This is important because, if there were only a public and private key, the recipient of a (signed) document would have no way of knowing, whether a public key he’s been given, actually belongs to the correct author. He’d just know, that it’s the public key associated with an arbitrary private key, where the two are supposedly already matched as they should be.

Conversely, if a person wanted to encrypt a document being sent to another, then he’d have no way of knowing, that he’s encrypting it using the correct public key. The person who has the corresponding private key, might not be the intended recipient.

Because of the signature of the public key with another person’s key-pair, that person’s attestation to the fact that it belongs to its rightful owner, can add trust in the public key, for the recipient of a signed document, or the sender of a document to be encrypted, the latter so that only the holder of the correct private key will be able to decrypt it.

So, it can happen to users of GnuPG, that they’ve been using GUIs such as ‘Kleopatra’ or ‘KGPG’, that these GUIs have not displayed any messages, but that they’d like to verify the signatures of their public keys, belonging to other people anyway. And from the command-line, there is a way to do that…

(Updated 5/24/2020, 8h35 … )

## Misidentified Problem, Was: Latest ‘libgcrypt’ Update breaks ‘Enigmail’.

This morning, an update installed itself on my Linux computer ‘Phoenix’, that brought the version of my ‘libgcrypt‘ libraries to ‘1.6.3-2+deb8u3‘. This is under Debian / Jessie, a version of Linux. These libraries are supposed to give access to GnuPG encryption capabilities, to certain applications.

Within my ‘Thunderbird’ email client, I have an add-on installed from the package manager, called ‘Enigmail’ (version ‘2:1.8.2-4~deb8u1‘), which gives a full suite of encryption capabilities to my email.

The latest ‘libgcrypt‘ update has broken Enigmail, which was working fine before today.

More specifically, it is no longer possible to encrypt an email to oneself. Being able to do so, is essential for two purposes:

1. When we send an encrypted email to the public key of a contact, we are also asking the software to encrypt the same email to ourselves,
2. The way we may sometimes configure our Drafts folder, is to encrypt any Draft emails saved there, so that we need to enter the passphrase to unlock our Private Key, before we can reopen our Saved, Draft emails. This is a nifty capability, to secure the emails on our hard-drive, before we’ve made the decision to Send them.

(Edit : )

I have identified the true cause of my problem. In order to make this explanation more clear, I should also add that I’ve recently revoked some keys, and created a new, main email-key.

There exists a configuration file for GnuPG, which under Linux systems is stored at:

~/.gnupg/gpg.conf

What can happen is that settings in this file, override whatever settings we choose in our GUI-application, such as with Enigmail, in Thunderbird. More specifically, I had entries which went something like this:


default-key  586A6C0052A087C0
###+++--- GPGConf ---+++###
utf8-strings
encrypt-to 586A6C0052A087C0
keyserver hkp://pool.sks-keyservers.net
###+++--- GPGConf ---+++### Tue 16 Aug 2016 01:42:05 PM EDT
# GPGConf edited this configuration file.
# It will disable options before this marked block, but it will
# never change anything below these lines.



The problem was, that the encrypt-to entry did not at first match my default-key entry, and referred to an old, revoked key. The encrypt-to entry has as effect, that GnuPG will always try to encrypt any messages that are meant for use with hybrid encryption, also to the specified key.

I edited this file manually, to make the two entries equal. I suppose that another way to solve this problem could have been, just to remove the encrypt-to entry…

The reader might wonder, by what sort of black magic that setting got into the configuration file, and, It’s usually not advised for users to edit this file directly, with a text-editor

## How I typically Solve my Kleopatra Start-Up Delay Problem

Both under Linux and under Windows, I use “Kleopatra”, which is a GUI for the ‘GnuPG’ system – the “GNU Privacy Guard”. In case the reader does not know, GnuPG or ‘GPG’ is one software alternative for providing ‘Public Key Cryptography’, which can be used in practice to sign and/or encrypt emails, as well as to validate digital signatures made by other people’s computers.

Using GPG does not strictly require that we use Kleopatra, because there exists the capability which some power-users have, to use GPG from the command-line, and Kleopatra is a distinctly KDE-based front-end, even though there exist Windows ports of it.

One problem which I eventually run in to, and which has been reported elsewhere on the Internet, is that at first after installation, Kleopatra seems to run fine, but that after some point in time we encounter a strange delay, when we start up this program, which can last for several minutes or even longer, during which the program does not respond properly to user commands. Our GPG installation does not seem to be compromised.

In my case, this seems to take place entirely, because Kleopatra has been instructed to check the revocation status of some certificates, but no ‘OCSP Server’ has been specified in its settings. According to some other reports on the Web, this is a problem specific to “CACert” certificates, and in my case also, the problem seems to set in, after I’ve added a CACert certificate to my key-ring. Yet, AFAIK, this problem could just as easily occur after we’ve added other certificates.

The way I eventually solve this problem – on every computer I own – is to open Kleopatra somehow, and then to go into Settings -> Configure Kleopatra -> S/MIME Validation , and then to look at the field which says “OCSP responder URL”. By default, this field will be blank.

Since in my case the problem starts after I’ve added my CACert certificate, I actually add the OCSP Server which is provided by CACert there, which is currently “http://ocsp.cacert.org/”. After that, I find that when I open Kleopatra, a narrow and subtle progress-bar in the lower right of the application window, sweeps to completion within one second, and the program opens fine.

I need to explain why this solution works for me, so that anybody who may be having the same problem, but not with a CACert certificate, can also solve this problem.

Certificates which are not self-signed, are signed by a ‘Certificate Authority’, such as CACert. When Kleopatra starts, one of the functions which it automatically performs is to check its certificates against a ‘Revocation List’, in case the Certificate Authority has decided to revoke it.

The actual certificate which I received from CACert, has the detail encoded into its plain-text data, that its revocation status must always be checked. But what I’ve found happens with Kleopatra specifically, is that if no OCSP Server has been specified, instead of somehow recognizing the fact that it cannot check the revocation status, this program goes into some type of infinite loop, never actually connecting to any server, but also never seeming to exit this state.

I choose to put this OCSP, because in my case, I know that it is the CACert certificate which has this need set with a high priority. It should be possible to put some other OCSP Server into the same field, because ultimately they should all be synchronized. But finally, the OCSP Server provided by the same Certificate Authority, also provides the fastest response time, for validating its own certificates.

As I see it, there was a problem in priorities somewhere, in programming this application. There was the bureaucratic priority, which states that the status of this certificate must always be checked. but then there was also the programming priority, which states that an attempt to connect to a server, without any specification of which server, will lead to some sort of malfunction eventually. And between these two, the bureaucratic priority won out.

There are some people on the Web who choose to solve this problem, by simply deactivating the feature, of online revocation checking. This can be done within the same settings tab, by unchecking the first check-box in that tab. This check-box is located directly before the setting, to “Check certificate validity every Hour” (on my setup, with a drop-down window set to “hour”). I prefer to let my software do everything it’s supposed to do, including to check the revocation status of my certificates. And the way to do the latter is to specify an OCSP Server. The fact that this problem can apparently be solved both ways, affirms the quality of the programming.

Dirk