By Justus | October 12, 2018
I’d like to inform you about the recent progress on your favorite OpenPGP implementation. It has been five weeks since I last wrote an update, and there are exciting developments to report.
Sequoia now collects direct key signatures, and honors subpackets affecting the primary key (like key flags) usually found on user id binding signatures. Although not specified by RFC4880, this is clearly a better place for such subpackets, because they have nothing to do with user ids. There is at least one other implementation that does this, Riboses fork of NetPGP.
The public key store now supports lookup by keyid, and the frontend exploits that for signature verification.
We did a great deal of refactoring, e.g. moving code around, refining types, using our own abstractions more instead of accessing fields directly.
Sequoia now tracks signature levels. A level 0 signature is directly over data, a level 1 signature notarizes level 0 signatures and data, etc. The frontend, sq, displays this information. Furthermore, the frontend now can add signatures to existing messages, and notarize existing signatures.
Sequoia gained a new buffered reader implementation for files. The buffered reader trait allows us to compose readers into a stack of filters. At the bottom of each stack is a reader actually reading data from somewhere. The implementation for files can be specialized to use platform specific methods to read the file, e.g. on POSIX systems it tries to mmap the file.
The TPK module now supports, honors, and creates revocation signatures.
The streaming verifier has been improved, and it gained a friend, the streaming decryptor (that also verifies any signatures). Both objects use a trait that the user needs to implement to fetch TPKs and secrets, and implement a verification policy.
The ‘sq dump’ command now draws a tree using line-drawing characters to illustrate the tree structure of OpenPGP messages.
Sequoia now tries to protect secrets like secret key MPIs, session keys, and passwords by introducing specialized types that currently overwrite their memory when they go out of scope. In the future, we may also mlock these regions. As a nice side-effect, these types provide clear semantics of function arguments.
When encrypting using ‘sq encrypt’, we optionally sign the data. In this case, we also emit the proposed intended recipient subpacket. The streaming decryptor now honors these subpackets.
The lower-level parser API has been simplified. We now track the packet’s path in the parser, and no longer return the depths when transitioning to the next packet. This greatly improves the ergonomic of the parser.
Our FFI-boundary received some attention driven by Neal’s effort to port the pEp engine to Sequoia. The port is quite complete at this point, merely the actual encryption and decryption operations are missing. This is notable because the pEp engine relies on the OpenPGP implementation for storing keys.
Finally, Sequoia now supports the AEAD bits of RFC4880bis, that is we handle the preferred AEAD algorithm subpacket, the AEAD feature flag, SKESKv5 packets, and AEAD Encrypted Data Packets. We can encrypt and decrypt using the unencumbered EAX mode. The streaming encryptor uses the AED packet in favor of the SEIP+MDC packets if all recipients announce support for AEAD in their TPKs.
That’s it for now, thanks for flying with Sequoia :) Justus