sq feature comparison with gpg

By Lars | May 11, 2022

The GnuPG command line tool gpg is the most popular implementation of the OpenPGP specification. The Sequoia PGP project produces the corresponding sq tool, and that tool is very much in its early stages. In the long run, we want sq to become so capable it has a comparable feature set to gpg. This blog post is a comparison of what the two tools can do.

This comparison is not a detailed feature comparison table, comparing option to option and command to command. Such a comparison would be interesting, but not necessarily meaningful: the two programs have such different approaches that a comparison table is hard to produce, and would be hard to make sense of. Thus, the approach taken here is to describe both programs at a higher level.

The goal of this exercise is to get an actionable list of changes to sq to make it better suited as an everyday tool for cryptography. The comparison is meant to be a short-cut to extensive user studies.

The comparison is divided into four parts: a short description of gpg, and of sq, a discussion of the differences, and a list of concrete proposals for changing sq.

For this blog post, we assume the reader has at least a basic understanding of OpenPGP.

gpg in summary

gpg is close to being a complete solution for using OpenPGP. It allows a user to do the basic cryptographic operations (encrypt/decrypt, sign/certify/verify, etc), as well as generate keys, manage collections of keys or certificates, manage sharing of certificates. gpg can handle keys stored on the local file system, or on hardware smartcards. It can exchange certificates with key servers.

gpg manages collections of keys and certificates in “key rings”, which it stores, by default, in a hidden directory in the user’s home directory. By default, it only uses keys and certificates stored there. The hidden directory also has configuration files.

Some of gpg functionality is actually implemented as daemons, which gpg starts automatically, if they aren’t already running. For example, all cryptographic operations using private keys is done in gpg-agent.

gpg tries hard to require a user to specify only a minimal amount of information for common commands. It gets configured defaults and other information from its implicit hidden directory. Thus, the minimal command to encrypt a file for a given recipient is:

gpg -e -r Bob msg.txt

Here, gpg knows to look for a certificate with a User ID containing “Bob”, and use that for the encryption. The user only needs to specify the minimal number of things, none of which can be inferred: the operation (encrypt), the recipient, and the file.

gpg has some support for being used in a programmatic way: the --with-colons and --status-fd options.

The gpg command line interface is based on hundreds of options. Some of them are by now only interesting for historical reasons.

In general, gpg tries to handle every possible use case for any possible user.

sq in summary

sq allows, and currently requires, the user to be more verbose than gpg does. To encrypt a file for a given recipient:

sq encrypt --recipient-cert=bob.pgp --output=msg.pgp msg.txt

sq does not have an implicit key ring where to look for the recipient’s certificate. The file with the key or certificate needs to be named by the user. sq also does not have a configuration file. sq has support for exchanging certificates with key servers.

There is an upcoming programmatic interface for sq: my project to add JSON support to sq is about doing exactly that.

The sq command line interface is based on subcommands, some of which have options.

Discussion of differences between gpg and sq

  • Configuration file: The approach taken by sq so far doesn’t preclude adding a configuration file, if and when one makes sense. However, configuration files may make programmatic use more difficult, as the configuration may affect what a program does.

  • Implicit key rings, and certificates: the Sequoia project is working on separate stores of public certificates and private keys. These are meant to be usable by other OpenPGP implementations as well.

  • Configurable cryptography: gpg allows the user to be quite specific as to key types and sizes, algorithms, etc. sq provides a few choices that its developers deem necessary. The Sequoia developers prefer this approach, because it tends to be difficult to learn enough to make informed choices here.

  • Hardware smartcards: gpg has pretty good support for this. Sequoia is working on that support, including for using the TPM chip in most PCs.

Proposals for changing sq (and Sequoia in general)

Note that this list only covers the high level changes. Details are expected to be discussed at length when the change actually gets implemented. (Issue numbers provided as a guide: they may not be exhaustive.)

  • Allow a user to add User IDs to an existing key. There is no need to remove User IDs, because certificates are an append-only data structure. Revoking a User ID is already possible. (#483)

  • Allow a user to set, unset, or change the expiration time of a key or subkey. (#848)

  • Improve adding certifications. (#637)

  • Allow a user to add subkeys. (They can already be revoked.) (#849)

  • Allow a user to extract a certificate in the SSH public key format. (#850)

  • Allow a user to set a signature or a certification to expire. (#103, kind of)

  • Allow a user to clean up / minimize certificates for sharing. (#810)

  • Integrate support for public and private key stores into sq. (No issue, but work is happening. This will probably include a lot of design work as it touched most aspects of sq.)

  • Integrate support for using smartcards and TPM. (No issue, but work is happening.)

  • Allow users to add/remove/revoke/export User Attributes, especially social handles, but maybe also photos. Also, extract them to a file or similar. (#853)

  • Allow a user to clean/minimize export certificates. (#758)

  • Allow a user to change capability flags for a key. (#851)

  • Allow a user to retrieve keys using DANE, LDAP, and NTDS.

  • Discuss whether group functionality is needed in sq.

  • Discuss whether sq should support something like pinentry.

  • Allow a user to debug sq by using logging. (#851)

  • Allow a user to find keys from various places online. (#651)