Sequoia Stagg in Alder Creek, California
In 2018, three former GnuPG developers began work on the Sequoia project , an implementation of OpenPGP in Rust. As you know, OpenPGP is an open data encryption standard often used for secure email; and GnuPG is the reference implementation of this standard.
The developers themselves stated the motivation for creating a new OpenPGP library:
- GnuPG is difficult to modify. The code and API have been accumulating over 21 years. There are no unit tests. The components are closely related to each other. The architecture leaves a lot to be desired, and simple refactoring won't help.
- Many developers are unhappy with the GnuPG APIs. The GnuPG command line tool and the corresponding programming libraries have different functionality: some commands are only available from the command line.
- Rust is a memory-safe language that automatically eliminates a whole class of bugs.
- GnuPG cannot be used on iOS due to GPL restrictions.
The GPLv2-licensed Sequoia library is now approaching version 1.0 , although there are still several issues to be addressed .
GnuPG criticism
The new library should be free of the shortcomings of GnuPG. Although it should be noted that in addition to the "reference" implementation of OpenPGP, there are others, including OpenKeychain , OpenPGP.js and RNP .
GnuPG has been criticized for years . It has been criticized for its absurd complexity, a universal Swiss knife design: GnuPG does everything but does badly, including digital signature, password protection, public key encryption, secure file transfer, packet signing, backup protection, chat messaging, etc. .d. It is believed that in the modern era, specialized tools are needed: a separate library for secure messaging, a separate library for signing packages, a separate one for encrypting files (as a utilityrage written in Rust) and so on. And not all of these utilities need to be fully PGP compliant.
OpenPGP's striving for backward compatibility with ciphers of the 90s has been criticized, which means that the default settings do not correspond to modern best practices for strong cryptography and security is always possible through negotiation protocols. The problem is that it is impossible to simultaneously maintain backward compatibility and comply with modern secure cryptography.
We already mentioned garbage code: “The de facto standard PGP implementation is GnuPG. This program is not very neatly written. There's an extensive C codebase - a language with duplicated functionality (for example, a recent denial-of-service attack on SKS parsing says it has multiple key parsers) with a long CVE track record ranging from memory corruption to cryptographic attack via side channels. Sometimes it was possible to remove authentication from messages without GnuPG noticing it. You could have fed him the keys without the correct fingerprint. In 2018, the Efail vulnerability was caused by GnuPG serving unauthenticated plaintext upon request, ” Latacora writes .
Another problem is (in) usability.
Several years ago, a PGP usability study was conducted, in which a group of technicians was placed in a room with a computer and asked to configure PGP. Two hours later, none of them came out yet. - Ted Unangst , OpenBSD and LibreSSL Developer
Other complaints are the insecurity of long-term storage of the same key, the completely weak MDC ciphertext authentication system , lack of forward secrecy, and clumsy giant keys.
Sequoia project
Sequoia is a modern OpenPGP toolkit that solves many of these problems, writes LWN. Sequoia has already been adopted by several other projects, including keys.openpgp.org , OpenPGP CA , koverto , Pijul and KIPA .
The project is funded by the p≡p (pep) and Wau Holland foundations , with all development being open- source .
The new library is focused on security and correctness, while using the most reliable modern cryptography. The developers promise powerful tooling, including a command line program and Git-style subcommands.
$ echo hi | sq encrypt --recipient neal
-----BEGIN PGP MESSAGE-----
wcBMA8K4GQVsZSWYAQgAllrQ+9490eoFdB/jLrVvGl+IVtGJWPFDg9uhcl0D8k05
AWz8ZU2sd6GzoCH1nRpwASJWHxloNbPgvxhNRRVReg3GgfFwMkcoNJ2Xb4zocvx+
niH7ZlP9Py6kseuqtjhQZEyvtIfWc58TK9DRdPp5suzS3Y9Zbew9vC2N2u+8YsKL
BbbminTZqLYbt/00ZT/ZuDbtHhoDUxlnCK2Y2R6NZvuvwS1ujI0EOfdOagZO0z5k
hs8U9Xgk1/BWpQtKn3ygMDO0401nBBbwNgialcu/8yFS+wXoifRaj60Cbxhjv2/G
aTcl9loYpN93BL0a7EbKmcwDl14HwosKdkMj4Px25dI0AZjLxI7TBX18e+hBu5vr
q83G7aEwllpiDU3z+rFXBjsWDOwP2UBf05D/Bl05eSYx4x7UnQ==
=qAvC
-----END PGP MESSAGE----- A clear interface for parser and packet inspection has been implemented, as well as hex dumps, which can now be viewed in the online demo .
$ 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 last Unlike GnuPG, where the gpg command line tool is more powerful than the library, Sequoia is primarily a library; all of its functionality is available through open APIs. The project plans to provide two "layers" of API: a low-level implementation of the OpenPGP specifications and a high-level API with sensible defaults to make it easier for users to perform common tasks such as signing packages and verifying signatures:
$ sqv --trace --keyring tails-signing.key \
tails-amd64-3.11.iso.sig tails-amd64-3.11.iso
Will check signature allegedly issued by A8B0 F4E4 5B1B 50E2.
Found key A8B0 F4E4 5B1B 50E2.
Checking signature allegedly issued by A8B0 F4E4 5B1B 50E2.
Signature by A8B0 F4E4 5B1B 50E2 is good.
A490 D0F4 D311 A415 3E2B B7CA DBB8 02B2 58AC D84F
1 of 1 signatures are valid (threshold is: 1).
$ echo "Just check the exit status: $?"
Just check the exit status: 0 Despite the low-level implementation of the OpenPGP specifications, the developers have eliminated some outdated and dangerous standards, such as MD5 hashes.
Even before the start of the initiative, the founders of the project met with prominent members of the OpenPGP community and end users to discuss plans for the project and make sure that their approach is indeed justified. Active development is underway now. Judging by the entries in the repository and tracker , there are about 30 participants, and three releases have been made since the announcement in April 2020 of the preparation of version 1.0. The last release 0.19.0 was released in August 2020 - the most notable improvement in it is the integration of the Windows Cryptography API: Next Generation as a backend(CNG) instead of Nettle, which has problems in non-POSIX environments.
For added security, Sequoia plans to use process separation between public and private key services (as in gpg-agent). Here, for interprocess communication, the Cap'n Proto serialization protocol is introduced - this is something similar to Protocol Buffers, only faster.
In the presentation, the developers point out that the separation of processes is not always possible, for example, in iOS environments. When it is not available, Sequoia plans to use a shared SQLite database to communicate between services in the process, like a colocation.
Sequoia takes a conceptually different approach to public keychains: they are designed to be "more like an address book than a PGP keychain." Keys are stored by user identifiers ( petname ), with the ability to bind arbitrary structured data useful in implementing trust models. The developers say this approach is more in line with how users actually represent keys: they are associated with names, rather than a set of abstract identifiers. This is one area where Sequoia differs from other OpenPGP implementations.
In addition, all keys are assigned a "realm" indicating the intended purpose of the key. Two realms are currently supported: "Contacts" and "Software update key".
The keychain is automatically updated from remote servers (similar to parcimonie ) to keep track of changes, new subkeys and key revocations in a timely manner. The documentation indicates that this can be done using anonymized services such as Tor, in addition to the more common TLS encryption methods.
Sequoia's private keychain implementation will support forward secrecythrough the OpenPGP specifications, which are not implemented in many other libraries. These specifications make it possible to distinguish between data "at rest" (encrypted storage) and data "in motion" (encrypted transmission). From a security point of view, it is good to periodically change keys for data "on the move", but retain the ability to decrypt the data "at rest". A presentation by one of the developers, Justus Winter, compares Sequoia's forward secrecy features to other OpenPGP implementations.
Rust advantages
Sequoia takes advantage of all the memory safety benefits of Rust.
What is memory safety is popularly explained in an article by Michael Hicks. In simple terms, it means that in no state can a program access invalid memory. These are the following errors:
- buffer overflow;
- dereferencing a null pointer;
- saving the pointer after freeing memory (use-after-free);
- use of uninitialized memory;
- an attempt by a program to free the same cell twice (double-free).
Memory security violations lead to vulnerabilities such as data leakage and remote code execution. While some languages have resigned themselves to performance degradation in the name of memory safety, Rust's concept of ownership ensures safety and minimizes overhead.
Based on the current development of Sequoia, there is significant effort being made to write unit tests to prevent regressions and improve code quality.
Sequoia targets “modern platforms” including Linux, Windows, macOS, Android and iOS, making the most of existing cryptographic tools; the goal of the project is tight integration with cryptographic services of a specific platform. For example, on iOS devices it is planned to use the Secure Enclave coprocessorwhen available. Sequoia also provides an external function interface (FFI) for integrating a project with programs written in other languages. Bindings (bindings) with Python and C are currently offered. However, it should be noted that programs with these bindings lack the built-in memory safety of Rust, therefore special rules have been published for the correct handling of memory usage .
Sequoia Components
Plans for the future
The release of version 1.0 may take place soon, although at first only the low-level API will be released, that is, the sequoia-openpgp crate and its dependencies. This means Sequoia is not yet a replacement for tools like GnuPG for all users: the first major release will focus on a developer library. The Sequoia developers need to complete a command line tool
sqthat will not be included in version 1.0. In addition, the key storage service is still under development - together with the command line tool, this is one of the main priorities of the project after the release of version 1.0.
Overall, it's nice to see a project that is trying to make OpenPGP easier to use and more accessible. It can be seen that the developers have made significant progress in three years. The documentation allows you to use this library in applications. However, Sequoia still has a long way to go before it becomes a reliable cryptographic tool. Most importantly, the code needs to be audited. The project page says it hasn't been audited yet, but "as soon as we release the main Sequoia crate, it will be third-party audited." No release date for version 1.0 has been announced, but it looks like it will be coming soon.
Advertising
VDS for programmers with the latest hardware, attack protection and a huge selection of operating systems. The maximum configuration is 128 CPU cores, 512 GB RAM, 4000 GB NVMe.
