The Sequoia 0.20.0 package release was introduced yesterday . It offers a library of functions and command line tooling with an implementation of the OpenPGP standards (RFC-4880). The project team consists of three people - members of the OpenPGP project (RFC-4880). To improve the security and reliability of the codebase, they decided to create a new free implementation of OpenPGP in Rust. The project code is distributed under the GPLv2 + license.
The goal of the developers is not only to improve the security of the product, but also to get rid of the shortcomings of GnuPG. Without breaking compatibility or fundamentally reworking the codebase, they cannot be eliminated in the main project. For example, the links between the individual components of GnuPG are strong enough that it is difficult to make changes, let alone create a unit testing system. The gpupg command line toolkit is not synchronized in functionality and library of functions, so a number of actions can only be performed using the utility.
Sequoia has a sq command line utility with Git-style subcommand support, plus two API options - low-level and high-level. There are bindings for C and Python languages. Most of the features described in the OpenPGP standard are supported for encryption, decryption, creation and verification of digital signatures.
Additional features include verification support for separately supplied digital signatures, adaptation for integration with package managers, and the ability to limit signatures by threshold values and time.
The low-level API reproduces very closely the capabilities of OpenPGP and some related extensions, including ECC support and elements from the "draft" of the future edition of the standard. As far as exceptions are concerned, these are only outdated parts of the specification that can negatively impact security - for example, support for MD5 hashes. The API also supports unbuffered message handling. In terms of its capabilities, it is close to the full coverage of the OpenPGP standard and is completely ready to work with OpenPGP data. A stable 1.0 release should be released in the near future.
As for the high-level API, it is just beginning to evolve and so far covers such capabilities as storing public keys and accessing functions over the network. Other support and domain-specific features are planned to be added as the project develops.
In addition, the package also has very powerful package inspection tools that can be used for development, debugging, and incident analysis. Inspection tools are combined with a parser so that the user can analyze the structure of encrypted messages, digital signatures and keys.
sq packet dump --hex message.pgp
New CTB, 13 bytes: One-Pass Signature Packet
Version: 3
Type: Binary
Pk algo: EdDSA Edwards-curve Digital Signature Algorithm
Hash algo: SHA512
Issuer: 83F8 2E4F E9A5 E098
Last: true
00000000 c4 0d frame
00000002 03 version
00000003 00 sigtype
00000004 0a hash_algo
00000005 16 pk_algo
00000006 83 f8 2e 4f e9 a5 e0 98 issuer
0000000e 01 lastIn terms of platform support, the package currently works with Linux, FreeBSD, Windows, macOS, Android and iOS platforms. It is also possible to work with the cryptographic services provided by these platforms, including coprocessors for computing in isolated enclaves. To provide additional isolation, it is practiced to separate services into separate processes that work with public and private keys. For example, a key store is developed in the form of a separate process. The Cap'n Proto protocol is used to ensure the interaction of individual processes.
The presented new version has a low-level package sequoia-openpgp , the sqv program (replacement of gpgv) to verify detached signatures and a sqop utility with an implementation of the Stateless OpenPGP CLI. Rust requirements have been raised to version 1.46. The use of the continuous integration system for checking changes has been expanded and the set for testing compatibility with OpenPGP has been improved.
In the near future, the developers plan to release version 1.0, which will include a high-level API, and not just a low-level one, as it is now.
