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
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
gpg can handle keys stored on the local file system,
or on hardware smartcards. It can exchange certificates with key
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.
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 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
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
gpg command line interface is based on hundreds of options. Some
of them are by now only interesting for historical reasons.
gpg tries to handle every possible use case for any
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.
sq command line interface is based on subcommands, some of which
Discussion of differences between gpg and sq
Configuration file: The approach taken by
sqso 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.
gpgallows the user to be quite specific as to key types and sizes, algorithms, etc.
sqprovides 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.
gpghas 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
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
sqshould support something like pinentry.
Allow a user to debug
sqby using logging. (#851)
Allow a user to find keys from various places online. (#651)