
Sequoia-PGP – A new OpenPGP implementation in Rust - 1wilkens
https://sequoia-pgp.org/
======
alain_gilbert
I wish gpg had a decent cli/"api"

At work, we use it to store shared secrets. We can encrypt a file that can be
decrypted by multiple keys.

It's a bit hard to remember all the commands so I made a webUI to manage
everything.

The feature I like the most is that I can list which files you can access and
which files you cannot.

The thing is, to do that, I need to pass tons of obscure and magic nonsense
parameters IE:

    
    
        gpg --list-only --no-default-keyring --secret-keyring /dev/null ops.gpg
    

and then parse the completely un-parsable output to know which keys can
decrypt the file.

So far so good. The problem is that; this magic trick only work with gpg
2.0.30 or lower. If you have the latest version, you can see every keys that
can decrypt a file... except yours. There is no way to know if "You" can
decrypt a file anymore ! (how great is this)

I now have to tell people that if they want to use the nice UI they cannot
have the latest version of gpg, which is troubling.

I can't believe that in 27 years, it is still impossible to know which keys
can decrypt a file. Or even just have some parsable output instead of the pile
of crap the gpg tool can vomit out.

So I'm pretty excited about Sequoia :)

~~~
Freak_NL
Have you had a look at pass¹? It's a bash script that uses gnupg to encrypt
secrets as gpg-encrypted plain text files. It has a very nice feature that
allows you to specify a list of keys for all secrets in a specific directory
(using a .gpg-id file).

Once set up, accessing the secrets is a matter of using the pass command line
tool:

    
    
        pass edit some/secret
        # Copy the first line of a secret; by convention 
        # this is meant for a password:
        pass -c some/secret
        # Show the whole secret file:
        pass some/secret
    
        # Combined with git:
        pass git pull
        # Generate a 24-character random password:
        pass generate some/othersecret 24
        pass git push
    

We use pass to maintain a set of shared secrets with a small team. The
(encrypted) files are pushed to private git repository (pass supports this out
of the box).

1: [https://www.passwordstore.org/](https://www.passwordstore.org/)

~~~
zx2c4
I wrote pass, originally just as just a dumb bash script that I was using
privately, but then I put it on the Internet, and so all of the sudden there
was a requirement to _not be awful_. The experience has been pretty
frustrating, for precisely the reasons pointed out by GP: the gpg command line
interface is atrocious. I'm required to parse things in a million crazy ways,
buffer data myself, and work around all sorts of weird behaviors. All of that
headache, and then in the end all I get is lame PGP crypto out of it? As I
said, frustrating.

On the flip-side, at least we've (partially?) succeeded in taming the beast,
and the end result is something moderately usable that you happily recommend
to folks on HN. So that's good I suppose. :)

~~~
pferde
An alternative is to use the GPGME library, which does all the ugly gpg output
parsing for you. I realize, though, that a C library is not a solution for
everything, especially not for a shell script that you want to keep a shell
script. :)

~~~
zx2c4
Well... There's always
[https://github.com/taviso/ctypes.sh](https://github.com/taviso/ctypes.sh) ...

~~~
pferde
Holy crap, that's so cool. :) Thanks!

------
maxtaco
We at keybase developed a PGP replacement called Saltpack. It uses only modern
crypto, with all the features you would expect like authenticated encryption
and branch-free secret key operations (via the NaCl library). We have a better
armoring format that won’t get mangled in modern markdown contexts. It is also
integrated with our CLI and in the upcoming release we support encrypting for
teams.

[https://saltpack.org](https://saltpack.org)

~~~
jwr
The problem with keybase is that it has grown from a simple command-line tool
(which I could perhaps trust) to a monster with a GUI, menu-bar icon, resident
daemon, which does lots of things, and until recently failed to even properly
start for me. The running process daemon is required even to use the CLI.

I'm glad you are making a PGP replacement, but I'm worried that this will head
in the same direction. I want simpler, auditable and understandable systems
for crypto, not complex beasts with hidden interactions.

~~~
pornel
Oh yes! Keybase went full-Skype.

I loved the concept of verifiable identity and that I could use it even with
"plain" gpg commands without having to trust their client.

Unsurprisingly, there was no way to monetize this, so they've had to pivot to
being SlackDropboxIDontKnowWhat.app

~~~
Boulth
Too bad as verifiable identities can already be implemented in pure OpenPGP,
see Linked Identities ([https://tools.ietf.org/html/draft-vb-openpgp-linked-
ids-01](https://tools.ietf.org/html/draft-vb-openpgp-linked-ids-01)) as
implemented in e.g. OpenKeychain.

------
dvdplm
This uses the Nettle crypto library under the hood. Does anyone know how well
viewed (or reviewed) it is? I'm curious to hear more from the devs on their
reasoning for picking it (maybe it was the only one with the features needed
and a suitable license?)

[https://www.lysator.liu.se/~nisse/nettle/](https://www.lysator.liu.se/~nisse/nettle/)

~~~
flanfly
Nettle implements most of the crypto needed for OpenPGP, it's small size and
few dependencies makes it easy to wrap for Rust. I did review some, but not
all of Nettle and it looks pretty solid[1]. GnuTLS uses Nettle, so you can
expect there are people smarter than me trying to break it. Initially, I
wanted to use Botan, but the fact that it's in C++ means you need to write two
wrappers one from C++ to C and one from C to Rust.

1: I checked for proper RSA base blinding, a secure CPRNG, lack of
Bleichenbacher Oracles and lack of invalid curve attack vectors. It uses GMP
for bignum stuff so carry propagation bugs are unlikely. There are some things
that aren't super nice. The CPRNG does not reseed on forks, the included AES
doesn't look particularity time constant and the library doesn't use mlock()
nor zeros secrets after use.

~~~
randombit
Alas, I just started working on a Rust wrapper for Botan
[https://crates.io/crates/botan](https://crates.io/crates/botan)

The existing Botan C API is in fact sufficient for OpenPGP already,
[https://github.com/riboseinc/rnp](https://github.com/riboseinc/rnp) is in C++
now but was originally C and uses Botan's C API.

But Nettle is IMO quite solid and the developer is very skilled, so full steam
ahead.

Is there any relation between Sequoia and the BoringPGP spec?

~~~
flanfly
Yes, I'm a co-author of BoringPGP[1]. Sequoia itself will probably support it
as soon as Marcus and I get around finishing the spec but it's not part of
Sequoia and I only work on it in my free time.

1: [https://github.com/boring-pgp/spec](https://github.com/boring-pgp/spec)

------
fbender
Does it go beyond the minimum and old set of ciphers in use by the usual
implementations? I'm asking because I firmly believe that any GnuPG re-
implementation should try to improve on the current state of mail crypto [0].

[0] [https://blog.cryptographyengineering.com/2014/08/13/whats-
ma...](https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-
pgp/)

~~~
cyphar
It's interesting that blog post didn't mention one of the largest concerns
people should have with PGP -- it _still_ doesn't use authenticated encryption
even though the problems with unauthenticated encryption have been known for
decades.

(Yes, GPG has the MDC -- but as the fairly recent "PGP/MIME is broken" bugs
showed, the handling of MDC was broken in several ways and it can only be
detected after outputting all of the data. AEAD is far more cryptographically
sound.)

~~~
Xylakant
Nitpick: MDC failures can only be detected after decrypting all the data. So
the decrypting program would need 2 passes (one to validate and one to present
the plaintext) or buffer the decrypted output until it verified the MDC is
sound. GPG, however, does neither. AEAD, as far as I understand, suffers from
a similar, though less severe problem: decryption can fail at any point due to
a validation error. You can be certain that anything up to the failure hasn’t
been tampered with, but the question of what to do with the partial plaintext
remains. A partial, truncated ISO or script may be problematic, even if it
hasn’t been tampered with. (think: truncate rm -rf /tmp/foo to rm -rf /“)

~~~
cyphar
> GPG, however, does neither.

It also will output to --output even if an MDC validation error occurs at any
point, which is pretty insane. But from memory this is actually a larger
architectural problem (GPG doesn't appear to buffer anything -- which means
that when you tell it to write to --output it doesn't write anywhere else
first).

> AEAD, as far as I understand, suffers from a similar, though less severe
> problem: decryption can fail at any point due to a validation error. You can
> be certain that anything up to the failure hasn’t been tampered with, but
> the question of what to do with the partial plaintext remains.

That is also a problem, though it would avoid most attacks where programs
don't check GPG error codes (which is what the email vulnerabilities a few
months ago were about). The only practical attack is what you've described --
some sort of known-plaintext attack where the message already contains the
attack payload as a prefix. Ultimately AEAD (over MDC) is a protection against
people accidentally doing the wrong thing when using crypto tools -- because
users should not trust any of the decrypted text if the message didn't
validate.

------
tlamponi
Maybe also interesting: [https://neopg.io/](https://neopg.io/)

It's (also) from a former GPG dev, bases on the GPG source where some of the
targets are: * switch to C++, allowing to reuse the legacy code, with lots of
code thrown out * move to a single binary (again)

Now, C++ is naturally not your fancy new language and the rewrite-it-in-rust
people may run to their pitchforks but he has a blog post entry where he
argues his choice:
[https://neopg.io/blog/cplusplus/](https://neopg.io/blog/cplusplus/)

TLDR: He can build upon the well established GPG, C++ is mature and it's flaws
are known and can be avoided an worked around.

He even mentions the Sequoia Project in the last paragraph, and envies them a
bit as they can use Rust.

(for the record, nothing against rust or sequoia, just wanted to show a
related project)

~~~
pjmlp
While C++17 is a pleasure to work with, versus C++98, this kind of thinking
only works out in very small teams (<= 5), very focused on quality assessment
tooling like analyzers.

Making developers avoid C style coding on C++ code is a continuous fight.

------
nwalfield
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](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.

------
aorth
What about opmsg as a GPG replacement?

> _opmsg is a replacement for gpg which can encrypt /sign/verify your mails or
> create/verify detached signatures of local files. Even though the opmsg
> output looks similar, the concept is entirely different._

[https://github.com/stealth/opmsg](https://github.com/stealth/opmsg)

~~~
lmm
Your messages have perfect forward secrecy except when they don't, because it
uses DH but falls back to RSA when it runs out of keys. That's a security
failure waiting to happen; IMO no forward secrecy is a more user-friendly
model than "perfect forward secrecy except sometimes not".

Support for multiple recipients is inherently a mess in that kind of model.

No effort is made to even try to solve the identity problem

PFS aside it doesn't seem to do anything you couldn't do with GPG - e.g.
there's nothing to stop you verifying GPG key fingerprints by hand or using
different keys to communicate with different recipients. In particular it
doesn't seem to offer any improvement on the big problem that this is about -
good MUA integration.

Ultimately that looks like a good project that takes those techniques as far
as they can go, but also shows exactly why those techniques never made sense
for an email-like environment.

------
xur17
A bit of a tangent, but is something like BIP39 (seed words that can be used
for backup for cryptocurrency wallets) possible for gpg? It would make backups
100x simpler.

------
mynewtb
That name is unfortunate because most of the world has no clue how to
pronounce or spell it.

~~~
yorwba
Huh? Is the pronunciation given at
[https://en.wiktionary.org/wiki/sequoia#English](https://en.wiktionary.org/wiki/sequoia#English)
incorrect? It's exactly what I'd expect of a word spelled "sequoia", and I'm
frequently baffled by the inconsistencies in pronunciation that plague English
otherwise ("ough").

Although vowel centering makes it difficult to distinguish the pronunciation
from that of a hypothetical "siquoye" or similar, a quick look at the list of
translations indicates that most languages use equivalent vowels, unless they
have an etymologically completely unrelated word.

As far as names go, that one seems to be of the easier kind.

~~~
jcranmer
I've always pronounced it "sə-koy-ə" as opposed to "sə-kwoy-ə".

~~~
haldean
That might be a Britishism; Wiktionary does call that out as the UK
pronunciation. I also only know it as "səˈkɔɪ.ə".

