nwalfield

vor 5 Jahrendiscuss

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.

nwalfield

vor 5 Jahrendiscuss

Not yet, but it is on the road map!

nwalfield

vor 5 Jahrendiscuss

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.

nwalfield

vor 5 Jahrendiscuss

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.

nwalfield

vor 5 Jahrendiscuss

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.

nwalfield

vor 5 Jahrendiscuss

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]>

Submissions

Sequoia PGP: sq JSON: first sketch

The Future of Sequoia PGP

Sequoia PGP is now LGPL 2.0

Yes, We Want Cryptographic Protection for Email

PGP Marks 30th Anniversary

Hello, OpenPGP CA

Towards Sequoia OpenPGP v1.0

comments