Hi all,
I'm pleased to announce the release of version 0.31.0 of
sequoia-ipc.
I have published sequoia-ipc on crates.io:
https://crates.io/crates/sequoia-ipc
You can also fetch version 0.31.0 using the ipc/v0.31.0 tag:
https://gitlab.com/sequoia-pgp/sequoia/-/tags/ipc/v0.31.0
which I signed:
$ git verify-tag ipc/v0.31.0
gpg: Signature made Fri Oct 27 16:39:49 2023 +02:00
gpg: using RSA key C03FA6411B03AE12576461187223B56678E02528
gpg: Good signature from "Neal H. Walfield <neal(a)walfield.org>" [ultimate]
gpg: "Neal H. Walfield <neal(a)gnupg.org>"
gpg: "Neal H. Walfield <neal(a)pep-project.org>"
gpg: "Neal H. Walfield <neal(a)pep.foundation>"
gpg: "Neal H. Walfield <neal(a)sequoia-pgp.org>"
This is a bug fix release.
The most noticeable fix is that using gpg-agent is now more robust.
One problem was that when using a key managed by gpg-agent, e.g., from
the chameleon, our gpg reimplementation, or from the octopus, our
OpenPGP implemenation for Thunderbird, the first interaction would
sometimes fail.
https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupghttps://gitlab.com/sequoia-pgp/sequoia-octopus-librnp
This has been improved in these commit:
https://gitlab.com/sequoia-pgp/sequoia/-/commit/648858b7b8ce1db35a6f5f4a993…https://gitlab.com/sequoia-pgp/sequoia/-/commit/c5670ce4958a33c4a7c3b861bdb…
We also added support for GnuPG's loopback pinentry mode.
Neal on behalf of the whole Sequoia PGP team
Hi all,
I'm pleased to announce the release of version 1.17.0 of
sequoia-openpgp, our low-level OpenPGP library.
I have published sequoia-openpgp on crates.io:
https://crates.io/crates/sequoia-openpgp
You can also fetch version 1.17.0 using the openpgp/v1.17.0 tag:
https://gitlab.com/sequoia-pgp/sequoia/-/tags/openpgp/v1.17.0
which I signed:
$ git verify-tag openpgp/v1.17.0
gpg: Signature made Fri Oct 27 09:21:43 2023 +02:00
gpg: using RSA key C03FA6411B03AE12576461187223B56678E02528
gpg: Good signature from "Neal H. Walfield <neal(a)walfield.org>" [ultimate]
gpg: "Neal H. Walfield <neal(a)gnupg.org>"
gpg: "Neal H. Walfield <neal(a)pep-project.org>"
gpg: "Neal H. Walfield <neal(a)pep.foundation>"
gpg: "Neal H. Walfield <neal(a)sequoia-pgp.org>"
This release includes significant testing improvements, infrastructure
upgrades, new functionality, performance increases, and a number of
minor bug fixes.
# Testing Improvements
This release includes a new "null" crypto backend, which faciliates
fuzzing:
https://gitlab.com/sequoia-pgp/sequoia/-/commit/a4c2b9f50a9f6e6539154eb3bce…
Fuzzing works by passing invalid or malformed input to a function to
uncover defects. As decryption and signature verification is highly
sensitive to malformed input, the cryptography routines would quickly
reject malformed input, which prevented the fuzzer from exercising the
non-crypto related code.
The null crypto backend faciliates fuzzing by accepting pretty much
anything. Specifically, it uses a highly optimized version of double
ROT-13 to encrypt and decrypt data, and indicates that all signatures
are valid. This fuzzing uncovered a bug, which has also been fixed:
https://gitlab.com/sequoia-pgp/sequoia/-/commit/3c76d468060a02b0aa129308bc4…
There is also a new framework to detect secrets that are leaked to the
heap or stack. This happens when memory that stores a secret is not
erased after it is deallocated. Erasing secrets can help prevent
heartbleed-style attacks.
https://heartbleed.com/
See, in particular, this commit for a lot of technical details and a
description of the approach:
https://gitlab.com/sequoia-pgp/sequoia/-/commit/c62fb995baee091ef6009a06068…
The good news is that most crypto backends are good at protecting
their secrets. One issue was reported to the Rust aes crate, and a
partial fix has since been committed:
https://github.com/RustCrypto/block-ciphers/issues/385
# Infrastructure Upgrades
On the infrastructure side, we now use Sequoia git to enforce a
signing policy:
https://gitlab.com/sequoia-pgp/sequoia/-/commit/18dd64b9548ad151fdfa0ec8f67…
Sequoia git is a new tool that we've been working on to simplify the
articulation and verification of a signing policy:
https://gitlab.com/sequoia-pgp/sequoia-git
The basic idea is that a file, `openpgp-policy.toml`, is added to a
git repository. It contains a list of who is authorized to add
commits, sign tags, and change the policy. The `sq-git` CLI can then
be used to ensure that a version (e.g., a commit) is an authorized
derivation in the sense that each change made since an earlier, known
good version (the trust root) is consistent with a parent commit's
signing policy. More details are in the specification:
https://sequoia-pgp.gitlab.io/sequoia-git/
Using this tool, downstream users can detect changes that were not
authorized by the upstream developers, e.g., modifications by a
package registry, a forge, or some other machine in the middle.
Using the commit where the signing policy was added as our trust root,
we can authenticate all commits up to the openpgp/v1.17.0 tag:
$ sq-git log --trust-root 18dd64b9 openpgp/v1.17.0 && echo Authenticated.
81d59e96ea37083b187909f12d298e5196c65130..65448ef8932cc8136b67445267e0f9849b7395c0: neal [74E445BA0E15C957]
...
Authenticated.
# New Functionality
Sequoia now includes better support for early v4 certificates. These
certificates often lacked a key flags subpacket. Previously, Sequoia
would consider these certificates to be unusable, as it concluded the
keys had no capabilities. Now, Sequoia more closely matches the
behavior of other implementations by inferring the key flags from the
algorithm, and the key's role (i.e., whether it is a primary key or a
subkey). See:
https://gitlab.com/sequoia-pgp/sequoia/-/commit/9e48a064e55e5ee61bc8caf6d7d…
This release adds support for Camellia and DSA to the Rust Crypto
backend:
https://gitlab.com/sequoia-pgp/sequoia/-/commit/e2cb5bafb95fea51328238acac9…https://gitlab.com/sequoia-pgp/sequoia/-/commit/13d56eddcaa3925fb3bfa8ef422…
Note: the algorithms supported by each of the backends is listed on
the status page:
https://sequoia-pgp.org/status/
Sequoia now also uses SHA-1 CD in place of SHA-1 everywhere.
https://gitlab.com/sequoia-pgp/sequoia/-/commit/5188c044b9f6645dd05a0918d4a…
# Performance Increases
Generating a certificate is now much faster. Previously, the
certificate was canonicalized after each key was added. For a
certificate with a primary key and two subkeys, this means that it was
canonicalized three times. Each time a certificate is canonicalized,
all of the signatures are checked. Now, the certificate is only
canonicalized once, at the end.
https://gitlab.com/sequoia-pgp/sequoia/-/commit/4a2c51173f9dc48ebd864998238…
Neal on behalf of the whole Sequoia PGP team
Hi all,
I'm pleased to announce the release of version 1.3.0 of
buffered-reader, an enhanced version of the `BufRead` trait from
Rust's standard library.
https://doc.rust-lang.org/stable/std/io/trait.BufRead.html
I have published buffered-reader on crates.io:
https://crates.io/crates/buffered-reader
You can also fetch version 1.3.0 using the buffered-reader/v1.3.0 tag:
https://gitlab.com/sequoia-pgp/sequoia/-/tags/buffered-reader/v1.3.0
which I signed:
$ git verify-tag buffered-reader/v1.3.0
gpg: Signature made Thu Oct 26 17:05:24 2023 +02:00
gpg: using RSA key C03FA6411B03AE12576461187223B56678E02528
gpg: Good signature from "Neal H. Walfield <neal(a)walfield.org>" [ultimate]
gpg: "Neal H. Walfield <neal(a)gnupg.org>"
gpg: "Neal H. Walfield <neal(a)pep-project.org>"
gpg: "Neal H. Walfield <neal(a)pep.foundation>"
gpg: "Neal H. Walfield <neal(a)sequoia-pgp.org>"
This release includes two new constructors, `File::new` and
`File::new_with_cookie`, which wrap `std::fs::File`. These interfaces
allow for some low-level manipulation of the File object before it is
wrapped. For instance, it is possible to stat(2) the file to get the
file size, or to implement metadata-based caching. For more details,
please see:
https://docs.rs/buffered-reader/1.3.0/buffered_reader/struct.File.html#meth…
Neal on behalf of the whole Sequoia PGP team
Hi all,
SecureDrop is migrating from GPG to Sequoia in our upcoming 2.7.0
release. I want to give a brief overview of how SecureDrop works and
then a request for review if anyone has some time.
For those not familiar, SecureDrop is a whistleblower submission system.
Sources upload documents and send messages for journalists to review
said information and determine whether or not to act on it. There's a
high-level architecture overview at
<https://docs.securedrop.org/en/stable/what_is_securedrop.html>.
== Our PGP operations ==
Submissions are encrypted for journalists using PGP. The journalist
secret key is kept offline on an airgapped machine, while the public key
is on the SecureDrop server and generally publicly available.
When a source logs in, they are given a diceware passphrase ("codename"
in SD documentation). The server generates a PGP keypair protected by
that passphrase. When the source submits a document/message, it is
encrypted for the journalist key and stored. (Note: sources can
pre-encrypt their submission locally and upload that, in which case we
don't further encrypt it again, but our impression is that this is
rarely done).
If the journalist chooses to reply to source, that message is encrypted
to the specific source and journalist (so journalists can read messages
they sent). When a source logs in with their passphrase, we decrypt any
journalist replies and display them to the source.
Currently this is all done using GPG, using a vendored copy of the
unmaintained pretty_bad_protocol library:
<https://github.com/freedomofpress/securedrop/tree/develop/securedrop/pretty…>.
== Migration to Sequoia ==
Any new source gets a keypair generated by Sequoia, which is stored in
our SQLite database in armored format instead of the GPG keyring.
Upon upgrade we run a one-time migration that iterates over the GPG
keyring, exporting public keys into our database.
When sources log in, we use their passphrase to export their secret key
out of GPG and into our database as well.
We've also added some checks for SecureDrop admins to reject SHA-1 keys
during installation using sq-keyring-linter.
To bring Sequoia into our Python application, we've written a small Rust
crate ("redwood") that implements the encryption, decryption and key
generation functions and can be exported to Python using the PyO3
bridge: <https://github.com/freedomofpress/securedrop/tree/develop/redwood>.
== Review request ==
Thanks to Wiktor who's already reviewed some of our code and Neal for
some input on issues and people who replied to my questions in IRC.
We'd appreciate if anyone could take a look at our Sequoia-interfacing
code, with a focus on the following areas:
* Are we creating PGP key pairs correctly?
* Is this (armored text) a safe format to store keys in?
* Are we generally using the correct Sequoia APIs / are we using those
APIs correctly?
All of our Rust code is at
<https://github.com/freedomofpress/securedrop/tree/develop/redwood> and
the main Python<-->Rust integration is at
<https://github.com/freedomofpress/securedrop/blob/develop/securedrop/encryp…>.
And if there are any other concerns or potential issues that other
migrations have encountered that we might have not considered.
== Thanks ==
As a general note, it has been fantastic to use Sequoia. So thank you to
everyone who has worked on it!
-- Kunal, on behalf of the SecureDrop team