nwalfield

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.

Not yet, but it is on the road map!

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.

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.

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.

  $ sq key generate -u '<[email protected]>' --export /tmp/alice.pgp; sq inspect /tmp/alice.pgp
  /tmp/alice.pgp: Transferable Secret Key.
  
      Fingerprint: 99E2 68B5 F5A2 45E9 4A9F  A1FB F10A BDD2 C1BC 2478
  Public-key algo: EdDSA Edwards-curve Digital Signature Algorithm
  Public-key size: 256 bits
       Secret key: Unencrypted
    Creation time: 2021-02-15 21:34:45 UTC
  Expiration time: 2024-02-16 15:01:06 UTC (creation time + P1095DT62781S)
        Key flags: certification
  
           Subkey: E54F CB2B 4619 FDB9 680A  974C 94D7 9D77 395B 8A7C
  Public-key algo: EdDSA Edwards-curve Digital Signature Algorithm
  Public-key size: 256 bits
       Secret key: Unencrypted
    Creation time: 2021-02-15 21:34:45 UTC
  Expiration time: 2024-02-16 15:01:06 UTC (creation time + P1095DT62781S)
        Key flags: signing
  
           Subkey: 62BF 9E6B C022 D3FB 681F  5279 2B09 341C EDFE 0AF9
  Public-key algo: ECDH public key algorithm
  Public-key size: 256 bits
       Secret key: Unencrypted
    Creation time: 2021-02-15 21:34:45 UTC
  Expiration time: 2024-02-16 15:01:06 UTC (creation time + P1095DT62781S)
        Key flags: transport encryption, data-at-rest encryption
  
           UserID: <[email protected]>

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.

Let's go through Matt's major points:

    Key Exchange / Key Management

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 ([email protected]).

:) Neal

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.

One way to reduce the cost of cross CPU synchronization is to use sloppy reference counters:

"An Analysis of Linux Scalability to Many Cores" (https://pdos.csail.mit.edu/papers/linux:osdi10.pdf)

Taler is quite different from, say, bitcoin in that it tries to enable taxation while preserving anonymity. The main webpage has more info: https://www.taler.net/ . Unfortunately, it doesn't appear that a paper has been published yet. But, there are a couple of presentations at https://taler.net/news .

He is listed by Tanja Lange as one of her PhD students: http://www.hyperelliptic.org/tanja/

Check out sloppy counters: https://pdos.csail.mit.edu/papers/linux:osdi10.pdf

The author unfortunately doesn't understand how GC works:

> GC’s overhead relates to the total memory allocated, not just > the memory actively used in the code. Each new allocation > results in an increased time per scanning cycle. Certainly > there are many optimizations involved in a good GC to limit > this, but the fundamental relationship is still linear. As a > program uses more memory the overhead of it’s GC increases.

A GC's overhead (at least a mark and sweep collector) is proportional to the number of live objects. This is because all of the dead objects are unreachable and thus aren't scanned.