Devel October 2023

devel@lists.sequoia-pgp.org

2 participants
4 discussions

sequoia-ipc 0.31.0
by Neal H. Walfield 27 Oct '23

27 Oct '23

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-gnupg https://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

1 0

sequoia-openpgp 1.17.0
by Neal H. Walfield 27 Oct '23

27 Oct '23

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

1 0

buffered-reader 1.3.0
by Neal H. Walfield 27 Oct '23

27 Oct '23

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

1 0

SecureDrop's migration to Sequoia
by Kunal Mehta 18 Oct '23

18 Oct '23

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

2 2

2024

2023

2022

2021

2020

2019

2018

Devel October 2023