- Devel - lists.sequoia-pgp.org

sequoia-openpgp: 1.12.0
by Neal H. Walfield 06 Jan '23

06 Jan '23

Hi everyone, I'm pleased to announce the release of version 1.1.4 of the buffered reader crate. It has been published on crates.io: https://crates.io/crates/buffered-reader You can also fetch it using the buffered-reader/v1.1.4 tag: https://gitlab.com/sequoia-pgp/sequoia/-/tags/buffered-reader%2Fv1.1.4 which I signed: $ git verify-tag buffered-reader/v1.1.4 gpg: Signature made Fri Jan 6 21:40:10 2023 GMT gpg: using RSA key C03FA6411B03AE12576461187223B56678E02528 gpg: Good signature from "Neal H. Walfield <neal(a)walfield.org>" gpg: "Neal H. Walfield <neal(a)g10code.com>" 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 fixes a performance bug in the generic buffered reader (`buffered_reader::Generic`). When the amount of data that is requested (e.g., via `BufferedReader::data`) exceeds the default buffer size, exactly that amount of data was read from the underlying reader. This is problematic for two reasons. First, as users of a buffered reader often do not immediately consume the data that is read, most reads are forwarded to the underlying buffered reader. Second, most reads are for one byte. Because `buffered_reader::Generic` keeps all data in a single vec, this resulted in a lot of copying, which hurt performance. Neal on behalf of the whole Sequoia PGP team

1 0

sequoia-openpgp: 1.12.0
by Neal H. Walfield 13 Dec '22

13 Dec '22

Hi everyone, I'm pleased to announce the release of version 1.12.0 of the sequoia-openpgp crate. It has been published on crates.io: https://crates.io/crates/sequoia-openpgp You can also fetch it using the openpgp/v1.12.0 tag: https://gitlab.com/sequoia-pgp/sequoia/-/tags/openpgp%2Fv1.12.0 which I signed: $ git verify-tag openpgp/v1.12.0 gpg: Signature made Tue Dec 13 16:14:59 2022 GMT gpg: using RSA key C03FA6411B03AE12576461187223B56678E02528 gpg: Good signature from "Neal H. Walfield <neal(a)walfield.org>" gpg: "Neal H. Walfield <neal(a)g10code.com>" 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>" The main reason for this release is to fix an issue with a dependency. sequoia-openpgp v1.11.0 depended on version 0.12 or later of the base64 crate. Version 0.20 of the base64 crate was recently released with an incompatible API. This means that when an application uses sequoia-openpgp, it may try and to use version 0.20 of base64, and compilation will fail. Version 1.12.0 tightens the dependency. We expect that the next version of sequoia-openpgp will upgrade to version 0.20 of base64. This release also includes a fix for how text data is hashed [1]. When sequoia-openpgp hashes a text (signature type = "0x01: Signature of a canonical text document" [2]), it breaks the input into to blocks. Unlike for signatures over data, for signatures over text, the line endings `\n`, `\r`, and `\r\n` are canonicalized to `\r\n`. Unfortuantely, if a '\r\n' is split across two blocks, sequoia-openpgp would recognize two line endings instead of one, and hash too much data. This defect does not impact binary signatures, and in practice it is relatively uncommon as a line ending has to straddle two blocks. Nevertheless, this defect may have resulted in the creation of incorrect signatures, or correct signatures being incorrectly identified as invalid. [1] https://gitlab.com/sequoia-pgp/sequoia/-/issues/960 [2] https://www.rfc-editor.org/rfc/rfc4880#section-5.2.1 Neal on behalf of the whole Sequoia PGP team

1 0

sequoia-openpgp: 1.11.0
by Neal H. Walfield 18 Nov '22

18 Nov '22

Hi everyone, I'm pleased to announce the release of version 1.11.0 of the sequoia-openpgp crate. It has been published on crates.io: https://crates.io/crates/sequoia-openpgp You can also fetch it using the openpgp/v1.11.0 tag: https://gitlab.com/sequoia-pgp/sequoia/-/tags/openpgp%2Fv1.11.0 which I signed: $ git verify-tag openpgp/v1.11.0 gpg: Signature made Fri 18 Nov 2022 02:28:42 PM CET gpg: using RSA key C03FA6411B03AE12576461187223B56678E02528 gpg: Good signature from "Neal H. Walfield <neal(a)walfield.org>" [ultimate] gpg: aka "Neal H. Walfield <neal(a)gnupg.org>" [ultimate] gpg: aka "Neal H. Walfield <neal(a)pep.foundation>" [ultimate] gpg: aka "Neal H. Walfield <neal(a)pep-project.org>" [ultimate] gpg: aka "Neal H. Walfield <neal(a)sequoia-pgp.org>" [ultimate] Primary key fingerprint: 8F17 7771 18A3 3DDA 9BA4 8E62 AACB 3243 6300 52D9 Subkey fingerprint: C03F A641 1B03 AE12 5764 6118 7223 B566 78E0 2528 The most notable change in this release is support for v3 signatures. RFC 4880 says: Implementations SHOULD accept V3 signatures. Implementations SHOULD generate V4 signatures. https://www.rfc-editor.org/rfc/rfc4880#section-5.2 Although the recommendation from 2007 is clear that v4 signatures should be preferred, the rpm ecosystem still generates v3 signatures. As Panu Matilainen, the maintainer of rpm, says: this appears to be more because it was forgotten about than out of any desire to stick with v3, and now it is time to figure out how to move on: [I]t IS us the rpm-ecosystem who has been sleeping here. The good news is that V3 doesn't appear to be heartbleed critically flawed, just that V4 is better and everybody should be using that instead. ... This caught us all by surprise. It's just another piece of rusty but vitally important piping in the backyard that everybody had forgotten until it bust open. It's a good thing this was discovered, now lets just move on to fix this up https://bugzilla.redhat.com/show_bug.cgi?id=2141686#c29 But, moving to v4 signatures will take time, because resigning all existing packages is infeasible. So, to accommodate reality, sequoia-openpgp is now able to parse and verify v3 signatures. By default, they are forbidden by the standand policy; an application must opt in to them using `StandardPolicy::accept_packet_tag_version`. https://docs.rs/sequoia-openpgp/1.11.0/sequoia_openpgp/policy/struct.Standa… Other user visible changes are listed in the NEWS file: https://gitlab.com/sequoia-pgp/sequoia/-/blob/openpgp/v1.11.0/openpgp/NEWS Neal

1 0

Super Powering End-to-End Email Encryption in Thunderbird
by Neal H. Walfield 08 Apr '21

08 Apr '21

Hi Everyone, I'm pleased to announce that we, the Sequoia PGP team, have released v1.0 of the Octopus. The Octopus is an alternate OpenPGP backend for Thunderbird 78 based on Sequoia PGP. https://sequoia-pgp.org You can find more details in our blog post and README, which also include installation instructions (for Windows we provide precompiled binaries). https://sequoia-pgp.org/blog/2021/04/08/202103-a-new-backend-for-thunderbir… https://gitlab.com/sequoia-pgp/sequoia-octopus-librnp The project was started as a simple Thunderbird-specific drop-in replacement for RNP, which Fedora and RedHat do not want to distribute, because Botan is not one of the cryptographic backends that they support. https://fedoraproject.org/wiki/Fedora_Crypto_Consolidation In the end, the project grew to also reintroduce many of the features that we and others miss from Enigmail, in particular, close gpg integration, web of trust support, and background updates. Along the way, we also discovered some security flaws, which we found workarounds for (see below). And Sequoia has several non-functional advantages. These include: - Features - Integrates GnuPG's keyring. - Integrates GnuPG's key validity information ("web of trust") - Directly talks to gpg agent (no GPGME required). - Updates certificates in the background using something like parcimonie. - Rejects weak cryptgraphic primitives. - Works around a 20 year old security flaw that Thunderbird introduced by rewriting Thunderbird-generated signatures on the fly. - Non-Functional Advantages - Unencrypted secret key material is protected in memory (like OpenSSH). This frustrates Heartbleed, Spectre, etc.-style attacks. - Countermeasures for weakness in SHA-1 collision resistance. (RNP accepts SHA-1 everywhere. In fact, stock RNP accepts MD5!) - Use of a variant of SHA-1 called SHA-1 collision dection, which is used by github, for instance. - SHA-1 is only accepted in safer contexts. - We've published and committed to a SHA-1 deprecation timeline. - Signatures include a salt to protect them from some attacks on collision resistance (like OpenSSH). - Avoids RNP's split brain problem due to its multiple sources of truth. - Some code (in particular, certificate parsing, which is slow) is multithreaded thanks to Rust's safer concurrency primitives. - Support for a broad range of OpenPGP certificates. If you have any questions, feel free to reach out either via email or on our irc channel (Freenode, #sequoia). :) Neal

1 0

New Contributor Preliminaries
by eli＠typedspace.com 04 Mar '21

04 Mar '21

Hello Sequoia developers, I am interested in contributing to sequoia and wanted to check-in and say hello before diving in. But let me introduce myself and say a few words about what brings me to sequoia. I am a software developer by trade (full stack web) and free software enthusiast. I am passionate about digital privacy and security. I love the mission of p≡p. I am a maintainer of the Exercism Rust track and am have a few years of Rust programming experience. I would like to contribute to a Rust project by solving practical problems in a domain Rust is well-suited for. Project Euler and Exercism are fun. But the world needs more quality crypto! What do you expect from new contributors? What would you say are the project's current needs befitting a newcomer? Thank you! Eli

2 2

ORCA problem statement: OpenPGP Relational Certificate Authentication
by Daniel Kahn Gillmor 03 Mar '21

03 Mar '21

Hi all-- I know folks on this list are concerned about the future prospects of the ill-named "Web of Trust" [0]. I wanted to kick off discussion about one particular corner of it: how to evaluate the "validity" of OpenPGP certificates for particular names. Thanks to Justus for coining the term ORCA: OpenPGP Relational Certificate Authentication. (maybe "Relational" should be "Recursive" or "Rational"?) I hope this message isn't "squatting" it too much. I'm happy to use a different term if there is an objection, but i like having a catchy shorthand, one that *isn't* "WoT". This e-mail is an attempt to just frame ORCA as a specific problem. I'm hoping that future messages on this list will try to tackle deeper definitions, implementation details, and algorithms. I'm proposing the following problem statement (which i drafted earlier today on IRC, but has evolved a bit in my mind since then): - ORCA is interested in authenticating aspects of an OpenPGP certificate. Concretely, the goal is to determine whether it is appropriate to associate a given User ID with a particular primary key. - ORCA models this problem as a function, where the inputs are: - set of OpenPGP public keys P, - set of OpenPGP certifications C, - a "root trust" mapping T from P → N where N ∈ [0.0,1.0] - user ID (UTF-8 string) U, and - primary key K and the output is a numerical score from 0.0 (meaning "K" is inappropriate for use in contexts where the User ID is expected to be "U") to 1.0 (meaning "K" is entirely appropriate for use in contexts where the user ID is expected to be "U") I observe that T in the definition above is slightly more flexible than the "set of root certificates" framing that Neal has been developing. It's capable of representing that of course (when X is a "root cert", T[X] = 1.0, else T[X] = 0.0), but could also represent something more nuanced, like GnuPG's "marginal ownertrust" (whatever that means). Maybe we want to go with just a "simple set of root certs" definition for T, but given that GnuPG exists and I think we want to be able to model its behavior, i lean toward starting with the more flexible mapping above. I also observe that N (a float from 0 to 1 that is output by T) has a remarkably distinct semantics from the output of the function itself. Maybe it'd be better to declare them with different ranges or different datatypes somehow to make it clear that you can't just map one to the other. Note also that this problem statement deliberately excludes several things. This is not to say that these things are ruled out or bad, just that they are *different problems* than the core of ORCA. Hopefully a clearer understanding of ORCA makes thinking about these other problems easier: - From the ORCA primitive function, we can build higher-level functions like "select the best match for user ID U from this set of OpenPGP certificates". But this particular framing does not concern itself with how to build this higher-level functionality. - ORCA doesn't concern itself with how to *discover* the various OpenPGP certifications that it uses. It accepts a set of certifications as input, and works from them. - This framing doesn't care at all about peripheral information like encryption-, signing-, or authentication-capable subkeys, algorithm preference advertising packets, keyserver preferences, etc. - This framing doesn't even contemplate OpenPGP "Certificates" (or "Keyblocks" or "TPKs" if you prefer). Rather, it assumes that some other layer is capable -- given the relevant OpenPGP packets -- of reassembling the appropriate packets into these higher-level objects. - This framing treats the User ID as a raw UTF-8 string. This isn't always how people will want to match or discover User IDs. For example, many MUAs might deliberately ignore the non-e-mail address part of a User ID, and just try to evaluate it in that way. This framing assumes that some sort of translation can be done to map these "filtered" user IDs onto real User IDs and vice versa, but that concern is not part of the ORCA model. - This framing ignores any attempt to evaluate User Attributes or other OpenPGP-style identity data. - This framing deliberately rules out the use of any additional metadata, such as "TOFU" information, Autocrypt state, etc. - The definition of T precludes applying "root trust" to anyything other than a pubkey. In particular, you can't apply it to a <pubkey,User ID> combination. It also precludes offering any more detailed nuance beyond a single scalar per pubkey for this mapping. Given the flexibility offered by the OpenPGP regex and "trust signature" subpackets, and the ability to synthesize new, privately-held pubkeys which can make new tsigs, i think we don't need anything more, but please sing out if you think otherwise. We have at least two known implementations of this function, which are GnuPG's "pgp" and "classic" trust models. In GnuPG terminology, these models calculate user ID "validity" based on its ownertrust DB and the certifications stored in its pubring. GnuPG allows the user to tweak its settings. These modules are additionally parameterized by GnuPG's options --completes-needed, --max-cert-depth, and --marginals-needed. Even given this fairly narrowly-constrained problem space, distinct implementations, which could provide different results. What do folks think about this problem statement? --dkg [0] "Web of Trust" is a disturbing term because it masks and conflates several of the underlying elements, for example willingness to rely on a particular key's certifications vs. willingness to use a particular key for a particular communications peer. It's also troubling because most people think they know what it means already, but haven't actually thought through the model in enough detail to understand their own confusion (i fall into this trap frequently myself). So using the term "ORCA" instead is a way to "reset" thinking about this, to allow a distinct framing of the problem.

1 0

Request for an official sq.exe distribution
by Stefan Claas 03 Feb '21

03 Feb '21

Hi dear sequoia-pgp team, After promoting sequoia-pgp in some communities I already received a second request from Windows users for a download link for sequoia-pgp, for Windows. While I usually compile sq.exe myself with MinGW I would like to see an official link from your site, so that interested Windows users can learn sq.exe. In case this would be possible, please not compiled in debug mode. I ask, because I have seen now Mr. Zimmermann in the testimonials and I guess when I further promote sequoia-pgp for Windows users, It could give sq.exe a boost, when seen on your site. Best regards Stefan

2 2

Sequoia PGP v1.0 Released: The Seedling's a Sapling
by Neal H. Walfield 16 Dec '20

16 Dec '20

Version 1.0. It's here. After three and a half years of development, we are happy to announce the release of version 1.0 of Sequoia! The release includes the low-level crate [`sequoia-openpgp`], and a program to verify detached signatures geared towards software distribution systems called [`sqv`]. [`sequoia-openpgp`]: https://crates.io/crates/sequoia-openpgp [`sqv`]: https://crates.io/crates/sequoia-sqv We will support this API with security updates for at least one year. In 9 months, we will announce whether we will extend this commitment. The two main criteria will be our financial situation (please [donate], or sponsor a developer or two), and the number of users. [donate]: https://pep.foundation/support-pep/index.html # Getting to Version 1.0 We actually [almost released] version 1.0 about a year ago. All of the features that we had planned for version 1.0 were implemented, we had good test coverage, and we even had a few users. But, we decided to wait. We decided to wait not because we thought of another feature, or because we become aware of a significant bug, but because [we][] [decided][] [to][] [take][] [some][] [time][] [to][to2] [improve][] [our][] [documentation][]. [almost released]: https://mastodon.social/@sequoiapgp/103364362621954545 [we]: https://gitlab.com/sequoia-pgp/sequoia/-/issues/465 [decided]: https://gitlab.com/sequoia-pgp/sequoia/-/issues/466 [to]: https://gitlab.com/sequoia-pgp/sequoia/-/issues/467 [take]: https://gitlab.com/sequoia-pgp/sequoia/-/issues/468 [some]: https://gitlab.com/sequoia-pgp/sequoia/-/issues/469 [time]: https://gitlab.com/sequoia-pgp/sequoia/-/issues/470 [to2]: https://gitlab.com/sequoia-pgp/sequoia/-/issues/471 [improve]: https://gitlab.com/sequoia-pgp/sequoia/-/issues/472 [our]: https://gitlab.com/sequoia-pgp/sequoia/-/issues/473 [documentation]: https://gitlab.com/sequoia-pgp/sequoia/-/issues/474 Our goal was to make sure that every module had a helpful introduction, and all public methods had a useful description, a link to [the standard], when appropriate, and a meaningful example. Dividing the task between five people, we figured it would delay the release by a month, perhaps two. In the end, well, it took nearly a year, and we had to scale our ambitions back a bit. Nevertheless, we're quite happy with [the][] [result][]. [the]: https://docs.sequoia-pgp.org/sequoia_openpgp/cert/index.html [the standard]: https://tools.ietf.org/html/rfc4880 [result]: https://docs.sequoia-pgp.org/sequoia_openpgp/parse/stream/trait.DecryptionH… First, the documentation is much better. It's of course hard to quantify its quality. But, we can distill a few numbers. When we started our documentation effort, shortly after we released version 0.14, the Sequoia library had just over 11k lines of comments including 53 documentation test, and 37 kSLOC including 12 kSLOC of unit tests. The 1.0 release has over 33k lines of comments (190% more) including 464 documentation tests (780% more), and 44 kSLOC (21% or 7.5 kSLOC more) including 8k SLOC of additional unit tests. Second, in the process of documenting our public API and writing examples, we discovered many minor annoyances, some inconsistencies, and more than a few bugs. We took the opportunity to fix them. Finally, as the rate of change of the API had decreased, more projects were willing to try out Sequoia. They provided additional useful feedback, which we integrated. All in all, we feel that with version 1.0 we've not only checked the [right boxes], but we also have a high-quality API and implementation that we can be proud of. [right boxes]: https://www.tomsguide.com/news/cyberpunk-2077-is-a-disaster-on-ps4-and-xbox… # Background Sequoia was started 3.5 years ago by Justus Winter, Kai Michaelis and me, Neal Walfield. Prior to working on Sequoia, the three of us had worked together at [g10code] on [GnuPG]. The [p≡p foundation] hired us not only to create a new OpenPGP implementation using a new architecture and programming language, but to improve the ecosystem around privacy-preserving tools as a whole. [g10code]: http://www.g10code.de/ [GnuPG]: https://gnupg.org/ [p≡p foundation]: https://pep.foundation The Sequoia library is a first step in that direction. But it is not our goal. Indeed, over the past three years, we've help other OpenPGP implementations. We've reported bugs that we've found (thanks in particular to our [OpenPGP interoperability test suite]), and even contributed some fixes to other OpenPGP implementations. [OpenPGP interoperability test suite]: https://tests.sequoia-pgp.org/ And, we've invested in tooling. We developed [Hagrid], a new verifying OpenPGP key server, which powers [keys.openpgp.org] and is now maintained by Vincent Breitmoser. We've helped [OpenPGP CA], a tool written by Heiko Schaefer to create *federated* CAs for groups like activists, lawyers, and journalists, but also companies, who don't want to trust centralized infrastructure with monetary incentives. OpenPGP CA significantly simplifies key discovery and authentication for unsophisticated OpenPGP users. We've developed [Koverto], an SMTP proxy, which makes it easy to sign and encrypt mails sent by services that don't support OpenPGP out of the box, like most CMSes. We developed a tool, [`sq-keyring-linter`] ([Debian]), to help users update their OpenPGP Certificates, so that we can [finally get rid of SHA-1]. [Hagrid]: https://gitlab.com/hagrid-keyserver/hagrid [keys.openpgp.org]: https://keys.openpgp.org/ [OpenPGP CA]: https://openpgp-ca.gitlab.io/openpgp-ca/ [Koverto]: https://gitlab.com/koverto/koverto [finally get rid of SHA-1]: https://mailarchive.ietf.org/arch/msg/openpgp/Rp-inhYKT8A9H5E34iLTrc9I0gc/ [`sq-keyring-linter`]: https://gitlab.com/sequoia-pgp/keyring-linter [Debian]: https://packages.debian.org/sid/sq-keyring-linter We're thinking big. We're thinking not only about mail encryption or even encryption in general, but also about integrity and authentication. And, we're thinking in particular, about [PKI]. If users can't easily find the **right** certificate for a communication partner, encryption and digital signatures are worthless, and possibly even dangerous. [PKI]: https://en.wikipedia.org/wiki/Public_key_infrastructure # Sequoia, the Library In designing Sequoia, we took a library-first approach. Although we have a command-line tool, [`sq`], which we are not yet releasing, we intend for the library to always provide a richer, more expressive interface. We agree that there is value in process separation, but we want to avoid the dangerous complexity of *safely* shelling out to another program. [`sq`]: https://docs.sequoia-pgp.org/sq/index.html The sequoia-openpgp crate (Rust's terminology for a library) is a low-level, policy-free OpenPGP implementation. Our goal was to implement all of [RFC 4880], and provide an API that can be used to access and modify pretty much everything, but is simultaneously secure by default. We understand low-level to mean not only an API that provides getters and setters, but an API that provides interfaces to parse and serialize those fields, and can combine them in ways intended by the standard, and needed by users. For instance, the [`Cert`] data structure encapsulates an OpenPGP certificate (casually referred to as an OpenPGP key). It canonicalizes the structure, and makes it easy to [query its properties]. But, it does so in such a way that it is still possible for a user to inspect and modify the low-level bits themselves without reimplementing the rest of the functionality. Another example is the [`DecryptionHelper`], which makes it easy to parse and decrypt an OpenPGP message. [`Cert`]: https://docs.sequoia-pgp.org/sequoia_openpgp/struct.Cert.html [query its properties]: https://docs.sequoia-pgp.org/sequoia_openpgp/cert/struct.ValidCert.html#met… [`DecryptionHelper`]: https://docs.sequoia-pgp.org/sequoia_openpgp/parse/stream/trait.DecryptionH… An example of how we make the API safe by default is that it is hard to accidentally export secret key material. In Sequoia, you have to explicitly [opt-in to export it]. Similarly, when [updating a signature], the creation time, hash algorithm, and issuer are automatically updated. This is usually what the user wants, but is easy to forget, and hard to debug when forgotten. Critically, it is easy to opt out when that behavior is not desired. [opt-in to export that]: https://docs.sequoia-pgp.org/sequoia_openpgp/struct.Cert.html#secret-keys [updating a signature]: https://docs.sequoia-pgp.org/sequoia_openpgp/packet/signature/struct.Signat… While developing Sequoia, we spent a lot of time thinking about extremes and corner cases. For instance, OpenPGP supports notarizations (signatures over signatures), but as far as we know no OpenPGP implementation supports them. We implemented support for it anyway, and it improved the ergonomics of the common case. ## Notable Details The devel is in the details. And while deviloping Sequoia, we paid attention. Here are a few noteworthy details: [SHA-1] has been broken since 2005. And, in 2011 NIST deprecated its use. Initially, we decided to simply reject any signature that used SHA-1. However, we were recently forced to [reevaluate][] [that decision][]: 22% of Debian developers use a certificate that relies on SHA-1 as do 63% of Arch developers. Even the Fedora release keys use SHA-1. [SHA-1]: https://en.wikipedia.org/wiki/SHA-1 [reevaluate]: https://mailarchive.ietf.org/arch/msg/openpgp/Rp-inhYKT8A9H5E34iLTrc9I0gc/ [that decision]: https://gitlab.com/sequoia-pgp/sequoia/-/issues/595 We decided that we couldn't simply reenable SHA-1. After some consideration, we've opted to [permit it] in contexts where collision attacks similar to the one presented in [SHA-1 is a Shambles] are harder. We also use a variant of SHA-1 called [SHA1CD] (SHA-1 Collision Detection), which detects and neutralizes the known attacks against SHA-1. Among others, [GitHub uses it]. And, we have also decided to **[start rejecting SHA-1 by default] at the beginning of 2023**, i.e., in a bit more than two years. This will hopefully give Debian developers and others sufficient time to [fix] or replace their certificates. [permit it]: https://docs.sequoia-pgp.org/sequoia_openpgp/policy/enum.HashAlgoSecurity.h… [SHA-1 is a Shambles]: https://sha-mbles.github.io/ [SHA1CD]: https://gitlab.com/sequoia-pgp/sha1collisiondetection [GitHub uses it]: https://github.blog/2017-03-20-sha-1-collision-detection-on-github-com/ [start rejecting SHA-1 by default]: https://docs.sequoia-pgp.org/sequoia_openpgp/policy/struct.StandardPolicy.h… [fix]: https://gitlab.com/sequoia-pgp/keyring-linter When we create a signature, we include a [salt]. This makes it harder for an attacker to predict what data a user will sign. And, it foils attacks where an attacker needs multiple signatures over the same message. [salt]: https://gitlab.com/sequoia-pgp/sequoia/-/issues/597 Similar to [OpenSSH], we [encrypt secret key material] while it is in memory. This frustrates side-channel attacks. [OpenSSH]: https://www.undeadly.org/cgi?action=article;sid=20190621081455 [encrypt secret key material]: https://docs.sequoia-pgp.org/sequoia_openpgp/crypto/mem/struct.Encrypted.ht… Sequoia supports [padding messages] to obfuscate an encrypted message's length. We include support for the [padmé] scheme, but other schemes can be plugged in. [padding messages]: https://docs.sequoia-pgp.org/sequoia_openpgp/serialize/stream/padding/index… [padmé]: https://bford.info/pub/sec/purb.pdf To allow users to control the policy while still using higher-level functionality, Sequoia uses a [policy object]. A policy object is passed to any method that checks something for validity. For instance, when a method needs to determine whether a binding signature should be used, it invokes the policy object's [signature callback]. Our experience suggests that this approach greatly simplifies dealing with this [cross-cutting concern] in a highly flexible manner. [policy object]: https://docs.sequoia-pgp.org/sequoia_openpgp/policy/index.html [signature callback]: https://docs.sequoia-pgp.org/sequoia_openpgp/policy/trait.Policy.html#metho… [cross-cutting concern]: https://en.wikipedia.org/wiki/Cross-cutting_concern Policy objects can also be embedded in other objects. For instance, a [`ValidCert`] encapsulates a [`Cert`] and a policy object. This ensures that the application of the policy is consistent, and hard to forget to apply. [`ValidCert`]: https://docs.sequoia-pgp.org/sequoia_openpgp/cert/struct.ValidCert.html [`Cert`]: https://docs.sequoia-pgp.org/sequoia_openpgp/cert/struct.Cert.html In Sequoia, we prefer the use of formal grammars rather than ad-hoc parsing when doing any non-trivial parsing. For instance, when verifying the structure of [OpenPGP Certificates] and [OpenPGP Messages], we use [LALRPOP], a parser generator, to generate the parser. [OpenPGP Certificates]: https://tools.ietf.org/html/rfc4880#section-11.1 [OpenPGP Messages]: https://tools.ietf.org/html/rfc4880#section-11.3 [LALRPOP]: https://github.com/lalrpop/lalrpop Sequoia implements a streaming API. If not careful, this can lead to a consumer processing unauthenticated data, which was exploited by [EFAIL]. To mitigate this type of failure, the [`DecryptionHelper`] withholds the last `O(1)` bytes of data, and only releases it if the message can be authenticated. This makes it harder for an attacker to control what is released. And for short messages, nothing is released since the whole message is buffered. [EFAIL]: https://efail.de/ [`DecryptionHelper`]: https://docs.sequoia-pgp.org/sequoia_openpgp/parse/stream/trait.DecryptionH… We've tried to ensure that data structures that may be used in a side-channel sensitive context use constant time comparisons. Where possible, we use a device driver-style API so that it is straightforward to add new backends. For instace, our [`Signer`] and [`Decryptor`] traits make it easy to implement alternative signing and decryption backends. In addition to the in memory implementations, we already have implementations that use secret key material managed by [gpg agent]. [`Signer`]: https://docs.sequoia-pgp.org/sequoia_openpgp/crypto/trait.Signer.html [`Decryptor`]: https://docs.sequoia-pgp.org/sequoia_openpgp/parse/stream/struct.Decryptor.… [gpg agent]: https://docs.sequoia-pgp.org/sequoia_ipc/gnupg/struct.KeyPair.html We tried hard to provide helpful error messages. This is particularly difficult when looking for a valid self signature, for instance: if all self signatures are ignored, because they are invalid, what should be shown? In this case, we remember why signatures were rejected, and then show one of those error messages. This is less confusing. The following output illustrates this idea: ``` $ sq inspect md5.pgp only-md5-pub.pgp: OpenPGP Certificate. Fingerprint: 526F D3F8 4EC7 DA9D E565 1B06 C4C9 7B7F A453 52C3 Invalid: No binding signature at time 2020-12-16T14:18:21Z Public-key algo: RSA (Encrypt or Sign) Public-key size: 2048 bits Creation time: 2020-11-05 09:16:25 UTC UserID: MD5 All Around <md5-all-around(a)example.org> Invalid: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance because: MD5 is not considered secure since 2004-02-01T00:00:00Z ``` Finally, we thought a lot about forward compatability. The OpenPGP standard makes provisions for this by using extensible types, and versioning. We are careful to preserve what we don't understand, and respect these packets as much as possible. ## What's Missing Sequoia provides a low-level API. As such, we don't provide a public or private key store. We do, however, plan to develop them (in fact, we already have prototypes). But, they will be released separately. In particular, we are not convinved that a single design is universally appropriate. For instance, a server application may not care about sharing keys with other applications, and it may have its own database. Sequoia implements most of [RFC 4880]. But, it is still missing a few features. In particular, we don't yet support [cleartext signatures]. The [`Cert`] data structure does not yet respect [certification revocations]. And, we still need to implement OpenPGP [regular expressions], which are used to scope [trust signatures]. We will add support for these features in the near future. [RFC 4880]: https://tools.ietf.org/html/rfc4880 [cleartext signatures]: https://tools.ietf.org/html/rfc4880#section-7 [certification revocations]: https://tools.ietf.org/html/rfc4880#section-5.2.1 [regular expressions]: https://tools.ietf.org/html/rfc4880#section-8 [trust signatures]: https://tools.ietf.org/html/rfc4880#section-5.2.3.13 Sequoia does not implement the cryptographic primitives that it uses, but relies on a library. By default, Sequoia uses [Nettle]. But, on Windows it is also possible to use [Windows CNG], which has the advantage that it is already part of the user's trusted computing base. A consequence of this is that Sequoia is limited to what the libraries support, and neither supports Elgamal keys, or [brainpool] keys. (For 25519 keys on Windows, we use the [ed25519-dalek] and associated crates.) [Nettle]: http://www.lysator.liu.se/~nisse/nettle/ [Windows CNG]: https://docs.microsoft.com/en-us/windows/win32/seccng/cng-portal [brainpool]: https://en.wikipedia.org/wiki/Elliptic-curve_cryptography [ed25519-dalek]: https://crates.io/crates/ed25519-dalek We have also decided to not support AEAD, as [its specification] for OpenPGP is still a draft, and consensus has not yet been reached. [its specification]: https://www.ietf.org/id/draft-ietf-openpgp-rfc4880bis-10.html For further details, please consult our [status page]. [status page]: https://sequoia-pgp.org/status/ # What's Next Our plans for the near future includes: - Adding support for the few [missing pieces from RFC 4880], as outlined above. [missing pieces from RFC 4880]: https://sequoia-pgp.org/status/ - Adding high-level services like a public key store and a private key store. We've already begun work on [prototypes], so we are confident that our low-level API is sufficient. A noteworthy goal of the private key store is to use a device driver-like framework so that different backends can be used. The main motivation for this is to handle smartcards. But, it can also be used to transparently access remote keys, and gpg's agent, which will simplify interoperability. [prototypes]: https://docs.sequoia-pgp.org/sequoia_store/index.html - Continuing to work on our CLI tool, [`sq`]. Although the tool is already quite usable, and useful, there are still some important [features missing]. In particular, we want to add a REST-style, JSON-based, versioned API as we expect people will end up writing scripts that use `sq`, and we want to avoid having them screen scrape its output, which will undoubtedly result in security issues. [`sq`]: https://docs.sequoia-pgp.org/sq/index.html [features missing]: https://gitlab.com/sequoia-pgp/sequoia/-/issues?label_name%5B%5D=cli More generally, we plan to continue our work in the ecosystem with a particular focus on tooling. # Financial Support Currently, the there are six people paid to work on Sequoia. They are all paid by the [p≡p foundation]. Additional financial support has came from a one-time donation from the [Wau Holland Foundation] in 2018. [Phil Zimmermann], the creator of PGP, donated 1000 Euros. And, [Proton Mail] donated 1000 Euros after our interoperability test suite found several issues in OpenPGP.js and GopenPGP, which they maintain. [p≡p foundation]: https://pep.foundation/ [Wau Holland Foundation]: https://www.wauland.de/de/ [Phil Zimmermann]: https://pep.foundation/blog/phil-zimmermann-donates-eur-1000-to-the-pep-fou… [Proton Mail]: https://protonmail.com/blog/openpgp-test-suite/ Although the p≡p foundation's finances are secure in the mid term, it is essential for Sequoia's long-term health that we diversify our funding. You don't need to directly use Sequoia to be positively impacted by it. For instance, OpenPGP CA is a new tool for creating federated CAs targeted at simplifying the use of OpenPGP for activists, lawyers, and journalists who can't rely on centralized authentication solutions. So, [consider donating]. Of course, if your company is using Sequoia, consider sponsoring a developer (or two). Note: if you want to use Sequoia under a license other than the GPLv2+, please [contact the foundation]. [consider donating]: https://pep.foundation/support-pep/index.html [contact the foundation]: https://pep.foundation/contact-us/index.html # Thanks Sequoia is a team effort. The following people have worked directly on Sequoia: - Azul - Daniel Kahn Gillmor - Daniel Silverstone - Heiko Schaefer - Igor Matuszewski - Jonas Bernoulli - juga - Justus Winter - Kai Michaelis - Neal H. Walfield - Nora Widdecke - Wiktor Kwapisiewicz The following people contributed code: - Alexander Kjäll - amesgen - Azul - Björn Petersen - Damian Poddebniak - Daniel Kahn Gillmor - Daniel Silverstone - David Sastre Medina - Doron Behar - Gerhard Bräunlich - Hartmut Goebel - Hussein - Igor Matuszewski - Jakub Kądziołka - Jakub Onderka - Jann Röder - Jonas Bernoulli - juga - Justus Winter - Kai Michaelis - Leonhard Markert - Levente Polyak - Neal H. Walfield - Nora Widdecke - phryk - Ruben Pollan - Sebastian Thiel - Tobias Mueller - Wesley Moore - Wiktor Kwapisiewicz And, the following people contributed on our [issue tracker]: [issue tracker]: https://gitlab.com/sequoia-pgp/sequoia/-/issues - [adulau](https://gitlab.com/adulau) - [alexanderkjall](https://gitlab.com/alexanderkjall) - [anarcat](https://gitlab.com/anarcat) - [ashkan.kiani](https://gitlab.com/ashkan.kiani) - [assarbad](https://gitlab.com/assarbad) - [azul](https://gitlab.com/azul) - [bme](https://gitlab.com/bme) - [chocol4te](https://gitlab.com/chocol4te) - [cluck](https://gitlab.com/cluck) - [curiousleo](https://gitlab.com/curiousleo) - [darkfox](https://gitlab.com/darkfox) - [darthmama](https://gitlab.com/darthmama) - [DBLouis](https://gitlab.com/DBLouis) - [dirkz](https://gitlab.com/dirkz) - [dkg](https://gitlab.com/dkg) - [doronbehar](https://gitlab.com/doronbehar) - [Ekleog](https://gitlab.com/Ekleog) - [erictapen](https://gitlab.com/erictapen) - [fdik](https://gitlab.com/fdik) - [flanfly](https://gitlab.com/flanfly) - [ghost1](https://gitlab.com/ghost1) - [hanno](https://gitlab.com/hanno) - [HeikoStamer](https://gitlab.com/HeikoStamer) - [hkos](https://gitlab.com/hkos) - [htgoebel](https://gitlab.com/htgoebel) - [husspEp](https://gitlab.com/husspEp) - [joakimlundborg](https://gitlab.com/joakimlundborg) - [juga0](https://gitlab.com/juga0) - [kalt](https://gitlab.com/kalt) - [kinnison](https://gitlab.com/kinnison) - [kushaldas](https://gitlab.com/kushaldas) - [lo48576](https://gitlab.com/lo48576) - [lu-zero](https://gitlab.com/lu-zero) - [mehmeteribol](https://gitlab.com/mehmeteribol) - [meskio](https://gitlab.com/meskio) - [mexus](https://gitlab.com/mexus) - [mishajw](https://gitlab.com/mishajw) - [mlboogerd](https://gitlab.com/mlboogerd) - [muelli](https://gitlab.com/muelli) - [nathankleyn](https://gitlab.com/nathankleyn) - [nimtiazm](https://gitlab.com/nimtiazm) - [nwalfield](https://gitlab.com/nwalfield) - [P-E-Meunier](https://gitlab.com/P-E-Meunier) - [pfaffm](https://gitlab.com/pfaffm) - [puzzlewolf](https://gitlab.com/puzzlewolf) - [Reisen](https://gitlab.com/Reisen) - [rockdaboot](https://gitlab.com/rockdaboot) - [roederja](https://gitlab.com/roederja) - [simonrepp](https://gitlab.com/simonrepp) - [teythoon](https://gitlab.com/teythoon) - [thomas__](https://gitlab.com/thomas__) - [TrashMacNugget](https://gitlab.com/TrashMacNugget) - [valodim](https://gitlab.com/valodim) - [vivapolonium](https://gitlab.com/vivapolonium) - [wezm](https://gitlab.com/wezm) - [wiktor-k](https://gitlab.com/wiktor-k) - [WolfgangMK](https://gitlab.com/WolfgangMK) - [Xanewok](https://gitlab.com/Xanewok)

1 0

Re: [openpgp] SHA1 Linter & Fixer
by Neal H. Walfield 18 Nov '20

18 Nov '20

Hi Phil, On Sun, 25 Oct 2020 02:03:43 +0100, Phil Pennock wrote: > I held off on "asking others to write software for me" in the previous > post, keeping it to "this exists now". This time around, I'm throwing > out a "Hey, pgpkey-sanitycheck would be a nice tool to have, folks" and > running away. I've written a certificate linter and fixer that does what you want, I think. You can find it here: https://gitlab.com/sequoia-pgp/keyring-linter https://crates.io/crates/sequoia-keyring-linter It detects and optionally fixes the following three types of issues: - A User ID's current self signature relies on SHA-1; - A Subkey's current binding signature relies on SHA-1; and, - A Signing-capable subkey's current primary key binding signature (backsig) relies on SHA-1. To just lint a key, one would do: $ sq-keyring-linter microsoft.asc Certificate 6CC73355668F7B75 is not valid under the standard policy Certificate 6CC73355668F7B75 contains a User ID ("Microsoft Security Notifications <securitynotifications(a)e-mail.microsoft.com>") protected by SHA-1 Examined 1 certificate. 0 certificates are invalid and were not linted. (GOOD) 1 certificate was linted. 1 of the 1 linted certificates (100%) has at least one issue. (BAD) 1 certificate has at least one non-revoked User IDs: 1 has at least one User IDs protected by SHA-1. (BAD) 1 has all User IDs protected by SHA-1. (BAD) 0 certificates have at least one non-revoked, live subkeys: 0 have at least one non-revoked, live subkeys with a binding signature that uses SHA-1. (GOOD) 0 certificates have at least one non-revoked, live, signing-capable subkeys: 0 certificates have at least one non-revoked, live, signing-capable subkeys with a strong binding signature, but a backsig that uses SHA-1. (GOOD) The tool lists the specific issues that it finds and then prints show statistics. The statistics are more useful when examining a keyring: $ sq-keyring-linter /usr/share/keyrings/debian-keyring.gpg ... Examined 885 certificates. 1 certificate is invalid and was not linted. (BAD) 884 certificates were linted. 207 of the 884 linted certificates (23%) have at least one issue. (BAD) 884 certificates have at least one non-revoked User IDs: 169 have at least one User IDs protected by SHA-1. (BAD) 106 have all User IDs protected by SHA-1. (BAD) 836 certificates have at least one non-revoked, live subkeys: 160 have at least one non-revoked, live subkeys with a binding signature that uses SHA-1. (BAD) 230 certificates have at least one non-revoked, live, signing-capable subkeys: 10 certificates have at least one non-revoked, live, signing-capable subkeys with a strong binding signature, but a backsig that uses SHA-1. (BAD) To fix a key, you need the secret key material. If that's available, it's straightforward: $ gpg --export-secret-key 4BE50C526C743502 | sq-keyring-linter --fix | gpg --import Certificate 4BE50C526C743502 is not valid under the standard policy Certificate 4BE50C526C743502 contains a User ID ("SHA1 User ID, SHA256 Subkeys <sha1-user-id-sha256-subkeys(a)example.org>") protected by SHA-1 Certificate 4BE50C526C743502, key CC6387BFA4D9263D uses a SHA-1-protected binding signature. Examined 1 certificate. 0 certificates are invalid and were not linted. (GOOD) 1 certificate was linted. 1 of the 1 linted certificates (100%) has at least one issue. (BAD) 1 certificate has at least one non-revoked User IDs: 1 has at least one User IDs protected by SHA-1. (BAD) 1 has all User IDs protected by SHA-1. (BAD) 1 certificate has at least one non-revoked, live subkeys: 1 has at least one non-revoked, live subkeys with a binding signature that uses SHA-1. (BAD) 1 certificate has at least one non-revoked, live, signing-capable subkeys: 0 certificates have at least one non-revoked, live, signing-capable subkeys with a strong binding signature, but a backsig that uses SHA-1. (GOOD) gpg: key 4BE50C526C743502: "SHA1 User ID, SHA256 Subkeys <sha1-user-id-sha256-subkeys(a)example.org>" 2 new signatures gpg: Total number processed: 1 gpg: new signatures: 2 Looking at the output, we see that two issues were corrected. Although you can build from source, if you are on Debian, the latest version of the tool, 0.3.0, should hit Debian unstable in the next few days (thanks dkg!). (The current version, 0.1.0, in Debian only includes the linter functionality.) https://packages.debian.org/sid/sq-keyring-linter If you have any feedback on the concept, I suspect that replying here would be okay. But tool-specific issues are probably off topic and should go to the tool's issue tracker or our mailing list (devel(a)sequoia-pgp.org, cc'ed): https://gitlab.com/sequoia-pgp/keyring-linter/-/issues Thanks! :) Neal

1 0

Heads up: New submission address for this list is devel@lists.sequoia-pgp.org
by Justus Winter 28 Oct '20

28 Oct '20

Hello :) we have migrated this list to a mailman installation that can be found at lists.sequoia-pgp.org. The new submission address is: devel(a)lists.sequoia-pgp.org Sorry for the inconvenience. On the upside, there is now a browseable, searchable archive at https://lists.sequoia-pgp.org/hyperkitty/. We also added a low-volume mailing list for announcements, for anyone who cannot bear the many threads of discussion that regularly overwhelm this list. Please report any problems with the new setup. Thanks, Justus

1 0

2024

2023

2022

2021

2020

2019

2018