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:


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

My dark secret is, that even though I do use modern, sophisticated GUIs such as ‘Kleopatra’ and ‘Enigmail’, I also delve into the low-level configurations of my software from time to time, and have the additional utility installed, which is named “KGpg”.

KGpg has a simpler GUI than Kleopatra and allows lower-level manipulation of the GnuPG software. And it has the ability to revoke keys, set the default (signature) key, set always to encrypt (a message) to a certain key…

Now, It used to be that Enigmail had a check-box, which stated, ‘Always encrypt messages to self.’ It no longer does. And at some point in the past, I probably felt I needed to set that with KGpg.

The only real failing of KGpg was, that after I had used it to revoke the other key, it gave no warning, that the configuration file it has generated, was still telling all the ‘GnuPG’ clients to encrypt everything to that key.


(Edit 06/15/2017 : )

There are some people who accept public-key cryptography, more or less, but who feel that even to give out their public key, is already a risk to be avoided.

The way I see this is, that if it was easy just to crack the public key, I might as well just revoke all my keys and stop using public-key cryptography. I need to be able to rely, on the public key not getting cracked. And so contrarily to how some people see this, I do not mind if the reader knows the ID of my public key.

That information can just as easily be found on public key-servers, so that if we have uploaded our public keys, trying to withhold them as well, would make no sense. Maybe the people who do not trust their security, have also taken the measure, not to upload them to the key-servers? But then, the only way in which other people will be able to use or verify them, is if these users have specifically sent their public keys, to people who they meant to be able to use them?


Print Friendly, PDF & Email

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>