I've written a few times about GPG before. It is an extremely useful tool for both keeping secrets and for creating strong signatures. Tools don't exist in isolation though. Often to accomplish a task you need to complete several different sub tasks to get to your desired outcome. Let's break down the task of sending an encrypted message into several smaller tasks.
- Compose a message
- Encrypt the Message
- Send the message
Depending on the tools you use to accomplish these subtasks the end user's perception of the work flow can vary considerably, but that isn't very important. What is much more important is how these tools themselves go about facilitating these subtasks or carrying them out themselves. Generally in computing automation is good. The labor saving applications of computers are a large part of what drives their utility. For applications of cryptography though, automation on its own becomes dangerous unless it is coupled with transparency.
This brings us to a coupling of tools that fails in its intended purpose. It has recently become widely know that using the combination of GPGTools,1 OS X's integrated email client Mail.app, and Gmail fails to accomplish this secure messaging business because of failings related to the way Mail.app and Gmail behave together. The specific failing is that unencrypted drafts of messages get autosaved to Gmail's drafts folder in the cloud.
Why is this such a bad thing? Well, at least beyond the matter where communication intended for your and the recipient's eyes only is released into the wild2 there is the problem wherein private services can play rent-a-cop on their own initiative, with warrants and due process being unnecessary. Now PandoDaily bemoans this state when really begging and pleading along with producing some mythical "pressure" for providers to act otherwise are non-solutions. Solutions include things like using strong cryptographic tools. Non solutions depend on assumptions of goodwill and honesty on the part of providers, basically their working depends on the powers of wishes and magic to change reality into something else. Actual solutions on the other hand work within reality.
There is actually a measure with some prophylactic strength against this tool chain failure that has afflicted Mac users who though they were using cryptographic protection on their messages. It consists of simply separating the tools you use for composing and generating ciphertext from the tools you use to send messages. Composing and encrypting messages in a text editor like Geany and then sending the messages with an email client or webmail tool is a weak form of this separation. A strong form of this separation involves composing and generating ciphertext on dedicated hardware like an airgapped machine or Cardano and then passing the ciphertext to an online machine for transmission.
- The popular package consisting of a port of GNU Privacy Guard along with other tools for the OS X platform [↩]
- Yes, anything saved into the could in plain text is in the wild. Despite any claims cloud providers make to the contrary, the cloud is open for exploitation. [↩]
I wonder if this affects Thunderbird/Enigmail. Actually... yes it probably does depending on your configuration. At least if I set auto-save and don't enable encryption, the draft will be saved unencrypted, so you have either to disable auto-save or enable encryption before writing anything.
The moral being that "always work locally". The cloud is for the birds.
Pretty much, unless like in the case of Mail.app Thunderbird/Enigmail say fuck it to the settings you have supplied.