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 '<alice@example.org>' --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: <alice@example.org>

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

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

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

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).

:) 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.

set -o pipefail makes common idioms a pain. Consider using head, which simply exits after it has read a few lines. In this case, the input process gets a SIGPIPE and exits with a non-zero exit code:

Consider /tmp/test.sh:

  set -o pipefail
  yes foo | head

  $ bash /tmp/test.sh >/dev/null
  $ echo $?
  141

This is a complicated story. The BND's priorities have changed (they are now migrating to Windows internally instead of GNU/Linux). FOSS is also a lower priority. See this video from the German Bundestag about funding GPG and related projects: http://vimeo.com/111715711 . (TLDR: We already gave them some money. Others should step in and cover the bill.)

I tried that trick and it didn't work for me (I still get the paywall). Too bad.

This post is disingenuous. In particular:

  [Cloud Operating Systems] enable the vision of light and fast application servers, while preserving the superior security and flexibility of true hypervisors.

As an extreme case, consider running all of your applications on your Desktop in their own VM. Now, you are in your web browser and you download a Word document that you want to edit. Somehow, you have to transfer this document to the Word Processor VM to edit it (they have different file systems so you need to use something like scp). If, after you're done editing it, you need to send it to someone via email, then you'll have to copy it to the Email VM. It's not how to see how this seriously impacts usability!

When sharing is required, then a Hypervisor is not helpful. That's not to say that Hypervisors are useless, as the author claims his opponents say. Hypervisors are good for running different operating systems on the same hardware and they are good at isolating the different OSes from each other. However, once any sharing is required, hypervisors are not the right tools for the job.

An unguessable ID that designates some resource is called a (crypto) capability.

Capabilities are quite different from access control lists (ACLs). In an ACL system, the list of authorized principals is attached to the resource. Thus, sharing access to a resource requires updating the resource. For instance, if Alice creates a document and wants to share it with Bob, then Bob needs an account and Alice needs to add Bob to the document's ACL. In a capability system, the capabilities designate the resource and sharing the resource is as simple as copying the capability. In fact, Bob can also share the document (without copying it first) with Carol. In an ACL system, Bob would not typically have permission to update the ACL.

For more information about capabilities, start with, for instance, the e-rights wiki at http://erights.org/elib/capability/index.html .

Unfortunately, there are a couple of misunderstandings here.

It is true that libraries call the gpg binary. This is a feature, not a bug. This architecture makes bugs in the applications less likely to affect the gpg code / data. For instance, it's a lot harder to dump the variable containing the secret key if it is in another process.

The wrappers don't scrape the output. There is a well-defined protocol for interacting with the binary.

This page explains what the money is going towards:

  http://goteo.org/project/gnupg-new-website-and-infrastructure/needs

- Release GnuPG 2.1 - Create a new web site

According to the descriptions, the new web site is not only about a new theme, but also about creating and collecting content that explains how to use GnuPG and encryption, in general.

This blog post is partially about the crowd funding campaign, but the author didn't include a link to the campaign!

http://goteo.org/project/gnupg-new-website-and-infrastructur...

"If this were" is an example of the subjunctive mood in English. It expresses a counter-factual assertion.

See also: https://en.wikipedia.org/wiki/Subjunctive_mood#English