1. Unfortunately, the draft is progressing much slower than many people would like. This is partially because not all parties agree on the best way forward for a number of technical decisions that need to be made including AEAD. See for instance this discussion: https://mailarchive.ietf.org/arch/browse/openpgp/?gbt=1&inde...
Happily, the group was rechartered at the beginning of this year and the charter is more narrow (just a cryptographic refresh). So, I'm hopeful that we'll see a new version of OpenPGP in the near future.
2. I present some evidence that pgp is effective against powerful adversaries despite its bad UX in my blog post.
We (Sequoia PGP) are working on improving the UX. Currently we are focused on the plumbing. We have a library, which we put a lot of effort into making not only feature completely, but also safe. We spent a lot of time thinking about the API usable and how to make it secure by default. We're working our way up the stack with tools like Hagrid (which powers keys.openpgp.org) and OpenPGP CA (https://openpgp-ca.org), a tool for administering in-house, federated CAs.
3. If I thought the project I was working on was doomed, I'd stop :D.
It’s good news that we will see a new version soon.
The current version is probably secure, but an update is still needed if only for marketing (features such as AEAD or FS have become partly selling points; they may not be relevant in some cases).
Sequoia does not (yet) have feature parity with GnuPG.
Several important components are missing including a public key store. In GnuPG, the public key store is mandatory. In our discussions with application developers, in particular, developers working on server software, this requirement was more of a hindrance than a help. Thus, in Sequoia we decided it needs to be as easy to bring your own key store (e.g., an existing database) as to use ours.
That said, on the desktop, it is quite useful to have a shared key store--you don't want to import keys into each of your OpenPGP-using applications. We hope to finish our [public key store](https://docs.sequoia-pgp.org/sequoia_store/index.html) this year along with other features that end users need and expect.
Sequoia consists of a number of components. There is the low-level crate. We released version 1.0 of that in Dec. 2020. There is sq, the CLI tool. We released that a few weeks ago. We've barely started work on the high-level interface.
Just because we plan to write a high-level tool, doesn't mean the low-level crate is hard to use. On the contrary, our experience is that it is pretty easy to use and actually does a good job hiding a lot of the low level details that don't need to be tweaked. For instance, I ported the pep engine from gpgme (GnuPG's high-level interface) to Sequoia's low-level interface. The initial port required about half as many lines of code.
I think you've misunderstood something. sq has no problem generating certificates with subkeys. Here's the default structure. Notice that we actually include a separate signing subkey by default. This makes it harder to use a data signature where e.g. a self signature is expected and vice verse. This can help protect against some collision attacks, among others.
I wondered if I was misunderstanding something, thank you for the response and correction. It was, “For instance, it is not currently possible to add new subkeys to a certificate”, that I thought was acknowledging this, but looking closer it seems to just be different terminology [0] than I’m familiar with. Looking forward to giving this a try!
Right. The sq cli does not have an subcommand to add new subkeys to an existing certificate. But it can use such certificates, and when it generates a certificate, it, by default, generates a certificate with subkeys.
This functionality will, of course, be added to sq (it is possible to do this using the library). We just haven't gotten to it yet. It's not that the functionality is hard to implement. But, we want to have a clean CLI, and there are many possible options. We want to expose them in a sensible way that does not overwhelm the user.
We've been considering this, but we'd rather have people use the library. We already have the start of a Python interface, which is pretty easy to use, IMHO.
But, I suspect that some people will insist on a shell script. So, we'll probably go this route sooner rather than later to avoid developers trying to parse the output of sq in an ad-hoc manner.
What would make a friendly interface in your opinion?
The sq frontend uses git style subcommands to clearly separate actions from options. This is something that gpg doesn't do too well. For instance, commands (e.g., -e) look like options (e.g., -r). If no command is given, gpg tries to guess what you meant, which is perhaps good for users, but bad for programmers. And if an option isn't relevant to a command, it is often just ignored, which again, is perhaps reasonable for users, but bad for programmers.
I have nothing against the git style subcommands, in fact I think they are great. A friendly interface would in my opinion be from the perspective of an end user. In the case if GPG the end user can have a couple of goals in mind, to encrypt, decrypt or sign data. Although you could do a lot more things, for most users those would be secondary goals.
I guess the average user doesn't necessarily know about autocrypt, ASCII armor, OpenPGP packets etc. Those users would have to guess whether they need to (do I need autocrypt? Why isn't it a default?).
To be honest I don't think the usage output is very bad in its current form, but as a start for something that will evolve over the years I am not so sure.
This isn't really a problem with the OpenPGP protocol or an OpenPGP implementation. This is inherent to any system that tries to protect you from active adversaries. If you are willing to use centralization, then you can do something like X509 (what is what TLS uses), but there are many, many cases of CAs issuing bad certificates either by accident or maliciously, e.g., the TURKTRUST incident. You can also do something like Signal with its verified key servers. But, if you want to be decentralized, then somehow you have to get the user involved. So, in my opinion, this is more a criticism of decentralization than of OpenPGP.
Now, that doesn't mean that OpenPGP tooling can't help. In fact, about 4 years ago, several initiatives began working on mechanisms to make key discovery much easier, and mostly transparent for users primarily concerned about privacy (as opposed to those whose threat model includes active adversaries, like activists, lawyers, or journalists). See, in particular, the work that pep (https://pep.foundation) and Autocrypt (https://autocrypt.org) have been doing.
Forward Secrecy
As I've written before (https://arstechnica.com/information-technology/2016/12/signa...), I don't think that forward secrecy is actually fixing a problem that most people have. Particularly in the case of OpenPGP where most people are interested in encryption of data at rest (messages stored on an IMAP server), which forward secrecy doesn't help (forward secrecy, because it throws away old key material, only makes sense for protecting data in motion).
But, that doesn't mean that we haven't given some thought to the problem. In fact, at the very same gathering, Justus, who is also working on Sequoia, presented a proposal for adding forward secrecy to OpenPGP in a backwards compatible manner. You can watch the presentation (https://www.youtube.com/watch?v=an6oYjikAPY), or read an early version of the proposal (https://mailarchive.ietf.org/arch/msg/openpgp/mk8_FSS-n4DVGf...).
The short version is: OpenPGP already has mechanisms to mark encryption keys as being appropriate for data at rest or data in motion. Until now, no implementation has bothered with this distinction. We propose creating two encryption-capable subkeys, one for data at rest, and one for data in motion, and rotating the one for data in motion once a week. To ensure that a sender has a non-expired encryption key we pre-generate keys, and distribute them via the keyserver network.
The OpenPGP format and defaults suck
It is true that OpenPGP has standardized a number of ciphers that are no longer sensible, includes compression support, etc. But, OpenPGP is over 30 years old. In that time there have been many improvements. But Matt is right that these improvements come slowly. This is partly due to the lack of funding: the industry choose S/MIME over OpenPGP. (Although S/MIME is cryptographically worse than OpenPGP. See EFAIL for a critical example of why.)
A major difficult to deprecating old ciphers is that OpenPGP is used for data at rest. And people rightly expect, I think, to be able to decrypt data and verify signatures from X years ago. This means we can't completely drop support for, say, CAST5: people wouldn't be able to decrypt old messages. Matt seems to ignore this bit, and focuses primarily on real-time communication (e.g., Signal), which only needs encryption for data in motion, i.e., the encryption is stripped and only archived on a trusted device (e.g., not an IMAP server).
One thing that we are consider in Sequoia is requiring the caller to provide a timestamp when verifying or decrypting a message. The timestamp can be used to choose defaults that are appropriate for when the message was allegedly created. The timestamp can be double checked with the timestamp in the signature. In this way, if someone tries to send you an email using a deprecated cipher, they'll also have to set the timestamp in the email to, say, 1997, which would hopefully be suspicious. Likewise, something like a can be shown when the message doesn't meet the current standard.
I hope that helps! If you have any other questions, you're welcome to ask here, or on irc (#sequoia on freenode) or on our mailing list (devel@sequoia-pgp.org).
While at the Delta X gather last week, we recorded an introduction to Sequoia. The presentation covers our motivation for starting the project, an overview of Sequoia’s architecture, and the project’s status: https://www.youtube.com/watch?v=NBbtIZipeNI
The tl;dr is that we’re actually pretty far: Sequoia is already being tested with the p≡p engine, and other projects, like Delta Chat, have begun replacing GnuPG or NetPGP with Sequoia.
Happily, the group was rechartered at the beginning of this year and the charter is more narrow (just a cryptographic refresh). So, I'm hopeful that we'll see a new version of OpenPGP in the near future.
2. I present some evidence that pgp is effective against powerful adversaries despite its bad UX in my blog post.
We (Sequoia PGP) are working on improving the UX. Currently we are focused on the plumbing. We have a library, which we put a lot of effort into making not only feature completely, but also safe. We spent a lot of time thinking about the API usable and how to make it secure by default. We're working our way up the stack with tools like Hagrid (which powers keys.openpgp.org) and OpenPGP CA (https://openpgp-ca.org), a tool for administering in-house, federated CAs.
3. If I thought the project I was working on was doomed, I'd stop :D.