Technical Details about EasyGPG

Custom Actions are discussed in the built-in Help. Here’s how custom Actions actually work.

When you create a custom Action, a folder named egpgdesk is created in the easygpgkeyrings folder. This folder will contain text files.

The first line of these text files is the name of the custom Action as it will appear in your GUI file manager, and the second line is the command-line arguments passed to EasyGPG when the Action is double-clicked.

The third line will contain the long key ID of the key used to sign the message or encrypted tar archive.

All the lines after the third line will contain the long key IDs of the recipients, and, in the case of a message encrypt Action, the names and addresses of the recipients.

The file name of the file in egpgdesk will be identical to the command line option for custom Actions created with Create a custom encrypt and copy message Action and Create a custom encrypt file or folder Action, but without the -- at the beginning. The name of the actual Desktop file will be the same as the file in egpgdesk with the suffix .desktop appended.

To help anyone who wants to fork EasyGPG, I will give you a copy of the asciidoc source code for EasyGPG’s built-in help. It is here. I compile it with this command:

asciidoc -b html4 built-in-help.adoc

I then remove the “last updated” note at the end, and the meta in the header that identifies the asciidoc version.

When I change the text of the About EasyGPG window, I just edit the HTML. Note that all of this from the line containing “GNU GENERAL PUBLIC LICENSE” to the end is copyrighted by the Free Software Foundation. You may reproduce it, but you may not change it.

To view and copy the content of all three of the PGP messages in easygpg.sh, just drag and drop easygpg.sh onto EasyGPG’s Desktop file. Three windows will pop up. None of these messages are encrypted; they are simply signed. I sign them with EasyGPG’s Sign a message and copy it to the clipboard Action.

I have not registered my icon as a trademark, but you might want to use your own icon in a fork to avoid confusing your fork with my EasyGPG. I converted my icon into a signed PGP message with this command:

cat easygpg.png | gpg -a --no-emit-version -s -u A6BDBF5757B731E9 -

You will, of course, use the file name of your own icon, and the key ID of your own signing key.

As I have mentioned on Diaspora, it is possible to “back-door” EasyGPG. An altered version could be made that would encrypt every message with the public key of the intended recipient, but also with another public key belonging, for example, to a government agency. A government agency could argue that this would not be a systemic weakness, as only the government would be able to read the messages not intended for it.

This is much more likely now, after the passage of new legislation in Australia near the end of 2018.

You don’t have to simply trust me when I say that EasyGPG is not back-doored. EasyGPG is the shell script easygpg.sh, and shell scripts are human-readable text files. You can check it for yourself.

As you can see, there is no file in the keyrings folder called gpg.conf. If there were, this could cause GPG always to encrypt for two recipients: the one you intended and another. You can inspect every encryption command. All these commands will include gpg and either --encrypt or -e. As you can see, there are seven such commands. None of the encryption commands uses --encrypt-to, and all of them use --no-encrypt-to. Finally, you can see that there are no public keys which you didn’t add to your keyrings, except, perhaps, my key used to verify your update to the latest version.

Australia’s new law could require a back-door. The law doesn’t allow the government to create “systemic” weaknesses, but it might not consider a back door that only works for it to be a “systemic” weakness.

The Australian government could email me at the address mentioned in EasyGPG’s built-in Help to demand such a back door. However, it’s difficult to see how they could force me to comply, or punish me when I don’t comply. They do not have a practical way to discover who or where I am. My accounts, at Nerdpol and the Internet Archive, were created using Tor, and have only ever been accessed using Tor. What’s more, my eepsite runs on a device that is completely under my physical control. In theory, the Internet Archive could give in and change the files I have uploaded there, but any back-doored update would have to be signed by me with my key. The next section explains how EasyGPG prevents such bogus updates.

A person who develops software should be very, very careful not to make any assumptions that undermine security. One of the things I worry about is an attack on EasyGPG’s three web sites. If someone can alter the files on the sites (including the Internet Archive item for EasyGPG), she or he could try to distribute a back-doored version of the software. This happened a few years ago with Linux Mint.

EasyGPG contains the public key of the key pair used to sign updates to it. EasyGPG will not accept an update that wasn’t signed with the same key it was signed with. The full fingerprint, not just the key ID, is verified.

Initial installation of EasyGPG presents another opportunity for an attacker. This one is more difficult to deal with. The EasyGPG installer also contains the public key EasyGPG is signed with, but if it’s possible to replace all my files, this key can also be changed. I will automatically detect changes to the I2P eepsite and the ZeroNet zite, but only periodic checks of the Internet Archive can detect changes made there.

I strongly urge you not to download the easygpg.sh file, mark it as executable, and just start using it. Please use the installer. It’s safer.

Deniable authentication is usually defined as a way that Bob can prove to himself that the message he received was, in fact, encrypted by Alice, but he is unable to prove this to anyone else. In this way, Bob is able to protect Alice. Because he is unable to prove to others that Alice is the author, he can’t be forced to do so. If no one can prove that Alice is the owner of the account from which the message was sent, no one can prove the message came from Alice. This is especially true if Bob’s email address and public key are well known.

Ordinary cryptograhic signatures are not deniable. They are intended to be undeniable. Using ordinary signatures allows Bob to prove to others that Alice is the author as easily as he proves it to himself.

Deniable authentication might be useful if Bob is a journalist and Alice is a potential source. Bob already has a reputation as an investigative journalist, and he’s published his email address and public key. Alice somehow manages to meet unobserved for a few minutes with Bob. She tells him that she wants to send him information later. Bob and Alice agree on a shared secret (a memorizable phrase) to use for authentication.

Later, Alice starts her Tor Browser and creates a free email account on Mailfence or a similar service. She creates this account with Tor and only uses it with Tor. She creates email attachments with EasyGPG’s Save a file or folder as an encrypted, unsigned tar archive Action, and composes her message to Bob with Encrypt a message with deniable authentication and copy it to the clipboard. She uses the shared secret she and Bob agreed to in their brief meeting.

When Bob receives the message, he doesn’t recognize the email address it’s sent from, but he suspects it may be from Alice. When he decrypts the message with EasyGPG, he’s prompted for the shared secret. He tries the secret he and Alice shared. The message is authenticated, so Bob believes the message came from Alice, but, as noted above, he can’t prove it to anyone else because he can’t prove that the address is Alice’s or that the secret that authenticated it was agreed to by Alice.

Here’s how EasyGPG implements deniable authentication. When Alice enters the shared secret, EasyGPG prepends it to the unencrypted message and calculates the SHA512 hash of the combination. It then prepends this hash (and not the shared secret) to the unencrypted message and encrypts it without signing it. When Bob gets the message he decrypts it. EasyGPG notices that the message is unsigned, and that it begins with the hash. It prompts Bob for the secret, and tests it by hashing it along with the message. If the hash matches, the message is authenticated.

Alice should not try to save the encrypted message she sent to Bob. Even if she did, she couldn’t read it. She should also delete the attachments she created (which she is also unable to decrypt). She should probably even close her new email account after giving the message time to arrive. If she needs to communicate with Bob again, she can always create a new account. When Alice imports Bob’s key, from Bob’s newspaper’s website, she should also do this using Tor. Alice might also want to use a newly-downloaded copy of EasyGPG, and create no personal key pair. This way, she can’t accidentally sign her message or attachments. The biggest threat to Alice will probably be possible forensic examination of the devices on which she stored the leaked documents and encrypted email attachments.

It may be useful for Bob and Alice to agree on an extra shared secret to use if Alice is forced to send a message to Bob. This will tell Bob not to trust the message from Alice, and thereby implicate himself in Alice’s whistle-blowing. Bob could report that he received an unsigned, unauthenticated message from an unknown source.

It is possible for someone to send messages to Bob using random secrets, in the hope she might hit upon a secret that Bob has agreed to with a potential source. However, a flurry of messages he can’t authenticate is going to tell Bob that this is happening.

EasyGPG was designed for portability. That’s one reason it’s a shell script (easygpg.sh). That’s also why it uses Zenity to put up windows. Zenity comes installed on many people’s GNU/Linux distros.

Access to the clipboard is through XClip. This seemed like a good choice because it is also widely installed, though not as widely as Zenity. Notably, it’s included with Tails.

EasyGPG is built around its command-line interface. It constantly calls itself. I hope that the command-line interface will encourage others to include EasyGPG as a part of larger projects. I’d like to do this, myself, in the future.

Here is the command-line help for EasyGPG.

Zenity has a disadvantage that has annoyed me since I started this project: once you click on a button in a Zenity window, the window will close. This was OK with me in most cases, but not for EasyGPG’s main menu. When you selected something in the menu window, the window disappeared. It quickly reappeared, but this behavior was always an annoyance. This is what motivated the move to the Actions folder, starting with version 4.0.

All the files in the Actions folder are just standard Desktop files. Each one calls easygpg.sh with the appropriate command-line option. Some of them—the ones that operate on files and folders—can operate on files or folders dropped onto them.

Set Up EasyGPG is also a Desktop file, though it is unusual. It’s based on the file used by the Tor Browser. It will work regardless of changes in the pathname of easygpg.sh. This is important because, as noted above, portability is an important design goal of EasyGPG.

GPG provides a sort of API for software like EasyGPG that wants to call it. This is facilitated by the --with-colons, --fixed-list-mode, and --status-file options of GPG.

Using these options produces somewhat different results in different versions of GPG, and compatibility with both versions 1.x and 2.x presented some challenges. It will probably produce more challenges in the future.

The ability of GPG to use a folder other than .gnupg to store its keyrings helped to make the portability of EasyGPG possible. EasyGPG also uses its keyrings folder to store the icon for its Desktop files, including all the Actions.

Portability, as mentioned above, was an important goal of EasyGPG development. I wanted to emulate the design of ZeroNet and the Tor Browser, in so far as they keep the executable files, all other resources needed by the executables, and all configuration and settings files in the same folder. This makes it easy to move or copy EasyGPG to a different computer, and it makes it easy to keep it on an encrypted flash drive.

Moving to a different computer can be difficult if, on that computer, your user ID (the number you see when you type id -u) is not the same. GPG will not work if its keyrings folder is not owned by the account using GPG, and accessible only by that account. Ownership can be a problem for any software that tries to be portable.

The ability to use EasyGPG from an encrypted (perhaps LUKS-encrypted) flash drive is helpful because this can make it more difficult for an attacker to get access to your keyrings.

Access to your keyrings is a problem because

To make it more difficult to brute-force your password, EasyGPG, when it creates new keypairs, does so with the --s2k-digest-algo "SHA512" --s2k-mode 3 --s2k-count 32000000 options. The default value for --s2k-count is 65536 (in GPG version 1.x), so the value of 32000000 dramatically slows down an attempt to brute-force the password. This certainly helps, but there’s no substitute for preventing access to your keys, altogether.

What’s more, if EasyGPG is kept on an encrypted flash drive, all the files saved by EasyGPG can also be kept on the flash drive. You could even keep an encrypted file there that contains your email/Diaspora usernames and passwords. This is actually what the Encrypt a message to me and save it as a text file Action is for. With your copy of the Tor Browser on the same drive, you’d be ready to communicate securely.

You’ll notice, if you use EasyGPG enough, that it gives you (within itself) no way to save unencrypted text. This is deliberate.

EasyGPG will let you edit unencrypted text, but it doesn’t give you a way to save it unencrypted. If someone, somehow, gets access to my EasyGPG folder, I want to make that person’s life as difficult as possible.

When you encrypt text to yourself, you can always view that text unencrypted, and even edit it, but when you save your edits, you’ll save them encrypted.

Many people who use GPG from the command line (and other utilities that call GPG) designate the public key used to encrypt with the -r or --recipient option. EasyGPG does not do this! Instead, EasyGPG uses the -R option. The difference is that using -r stores the key ID of the public key of the recipient in the message in a way that can be read without first decrypting the message. This is seen as an advantage by some, because it means that you never have to type more than one secret key’s password to decrypt the message.

I’m sure you can guess why I see this as a problem. If I encrypt a message, I want that encrypted message to reveal no information at all, other than the fact that it is a PGP encrypted message. If I send the message by email, I’ve already given up (to the email service providers involved) the two email addresses. That’s bad enough. Why also give up key IDs?

You can encrypt for yourself, along with others, but this is not done automatically or by default.

If you don’t include yourself among the recipients, you won’t be able to read the message that you encrypted. In fact, only those for whom it was encrypted can tell who wrote it. Not even you will be able to tell what you wrote or whom you encrypted it for.

By looking carefully at the message, you will be able to tell how many people it was encrypted for.