Devel

devel@lists.sequoia-pgp.org

79 discussions

Sequoia PGP: The Seeding Sees the Light of Day
by Neal H. Walfield 26 Nov '18

26 Nov '18

The Sequoia team proudly presents the first release of a new, cool OpenPGP implementation. On October 16, 2017, we made the first commit to the Sequoia repository. Just over a year and a thousand commits later, Sequoia's low-level API is nearly feature complete, and is already usable. For instance, a port of the p≡p engine to Sequoia is almost finished, and the code is significantly simpler than the version using the current OpenPGP library. We've also made experimental ports of other software that use OpenPGP, and written some new software to further validate the completeness and ergonomics of the API. During a successful talk at RustFest Rome presenting Sequoia, and the challenges of implementing Sequoia in Rust, we officially released version 0.1 of Sequoia. https://rome.rustfest.eu/sessions/sequoia https://media.ccc.de/v/rustfest-rome-6-sequoia About Sequoia: Sequoia is developed by three former GnuPG developers, Neal H. Walfield, Justus Winter, and Kai Michaelis. To mitigate many common security problems, Sequoia is written in Rust, a strongly typed language, which provides temporal and spatial memory safety. Rust also provides excellent support for embedding libraries in other languages. Sequoia already provides C bindings, and Python bindings are being actively developed. Sequoia development is primarily funded by the p≡p Foundation with additional support from the Wau Holland Foundation. Contributions are welcome. Financial contributions can be made via the p≡p Foundation. People interested in making technical contributions are welcome to reach out on IRC, or the mailing list. https://pep.foundation/ https://www.wauland.de/ https://pep.foundation/support-pep/index.html https://sequoia-pgp.org/contribute/ Additional information about Sequoia can be found on our website, and in a recent presentation introducing Sequoia: https://sequoia-pgp.org/ https://www.youtube.com/watch?v=NBbtIZipeNI

1 0

State of the seedling
by Justus Winter 12 Oct '18

12 Oct '18

Hey folks :) 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

1 0

State of the seedling
by Justus Winter 07 Sep '18

07 Sep '18

Hey folks :) I'd like to inform you about the recent progress on your favorite OpenPGP implementation. It has been five weeks since my last mail, and there are exciting developments to report. Our parser is now more robust. If a packet stream is damaged, it tries to find the next OpenPGP frame, and resumes parsing. This helps to deal with corrupted data returned from key servers. Sequoia now features an API to generate keys and construct a TPK structure. This is a medium-level API that takes care of creating the binding signatures. ASCII Armor, designed to protect OpenPGP data in transit, has been a source of problems if the armor structure is damaged. For example, copying data manually from one program to another might introduce or drop newlines. Our armor parser now simply tries to detect base64-encoded OpenPGP data. This way, if the framing is in any way damaged, or even stripped, we can still recover the message. Our detached signature verification tool, sqv, now supports --not-before and --not-after options that constrain the signatures that are considered valid to the given interval. Furthermore, it properly ignores duplicate signatures, and multiple signatures from the same TPK. Sequoia can now generate and parse the proposed intended recipient subpacket. Support for emitting the subpacket is implemented in the streaming signer. Since Sequoia currently lacks a streaming decryption and verification interface, the counterpart of checking the intended recipients is not yet implemented. We have been working on the usability of our command line frontends. It is no longer necessary to use -i to specify the input file. We now generate shell completions for both sq and sqv for all shells supported by our command line parser (bash, fish, zsh, PowerShell, and elvish). sq gained support for signature generation and verification. Keys for all cryptographic operations can now be given as files. sq dump now pretty-prints the packets, similar to pgpdump. We now generate a pkgconfig file for the debug build. Linking against Sequoia from C during development is now as easy as pointing PKG_CONFIG_PATH to sequoia/target/debug. Sequoia is now more efficient in terms of stack use when parsing multiple signatures, and nested signatures (i.e. notarizations) can now be checked. Sequoia gained a streaming signature verification filter. Streaming verification (and decryption) has been missing until now, because designing an API that is convenient yet reasonably safe has been challenging, and the verifying filter is our testbed for the more complex case of a decrypting and verifying filter. We cleaned up our interface, and did some refactoring to get rid of accumulated technical debt. Notably our packet structs are now opaque and have appropriate accessors, and the structure of the openpgp crate is cleaner and hopefully a bit more accessible. Our TPK module can now merge incomplete TPKs. Such TPKs may be handed out by a privacy-preserving keyserver that omits UserIDs when clients poll for key updates. Kai published his ongoing work on our keyserver. The keyserver aims at being more performant, and more privacy preserving than the SKS keyserver network. It can be found here: https://gitlab.com/sequoia-pgp/garbage-pile Neal cut the recordings of our talks at the Delta X gathering, and they can be found on our web site. Finally, this is the first of these reports that is also published in our blog in the hope that this is more accessible for the casual reader. That's it for now, thanks for flying with Sequoia :) Justus

1 0

State of the seedling
by Justus Winter 27 Jul '18

27 Jul '18

Hey folks :) I'd like to inform you about the recent progress on your favorite OpenPGP implementation. It has been five weeks since my last mail, and there are exciting developments to report. We now emit a warning if a public interface has no documentation. Even though we tried to document everything in the past, this will keep us on our toes. Sequoia can now parse Autocrypt headers, and this is exposed in the sq frontend. So if you ever get a mail from someone using Autocrypt, you can get her key using sq: % sq autocrypt decode -i $(notmuch search --output=files from:look@my.amazin.horse | sort -r | head -n1) -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFAB3UABEADCyB/vbIBA3m1BwcyjTieEMLySwYgt54EQ2hglOocdtIhqC+b0 ... The frontend now emits armored data by default, so that users do not get bothered by binary OpenPGP data in case they forget to redirect the output to a file. Subpacket handling has been reworked, and there are now convenience functions on the Signature type to add subpackets. The subpackets now use high-level types, e.g. broken down time instead of the OpenPGP wire format. Our secret key handling has been improved. Notably, we now have a TSK type, and can generate and serialize keys. We now use a formal grammar to verify the structure of OpenPGP messages and TPKs. Users of the packet parser can at any time verify that the message they are processing in a streaming manner is in fact a prefix of a valid message, and abort processing otherwise. When parsing has concluded, the final result of the verification is presented to the user. Our C interface has received some attention. We added some missing glue functions, and added examples. In Rust, one can include examples in the documentation that are compiled and executed as tests. This makes sure that examples never bitrot, and one gets a few tests for free. We implemented the same for C examples, and updated and fixed examples that no longer compiled. One example of such an example is this: https://docs.sequoia-pgp.org/sequoia_ffi/openpgp/fn.sq_armor_writer_new.html Finally, we added a LICENSE.txt file documenting the fact that Sequoia is GPL3+. Kai, Neal, and me went to the Delta X gathering in Freiburg. It was a welcome opportunity to discuss Sequoia, OpenPGP, and related topics. We also did a fair amount of hacking, and when the heat got too intense around noon, we cooled down in the Dreisam. As our first non-trivial consumer we started a proof-of-concept port of delta.chat to Sequoia. Currently, delta.chat uses netpgp, and has only modest demands in terms of OpenPGP-related functionality, making it a good target for porting to validate and improve our C interface. The port can be found here: https://github.com/teythoon/deltachat-core/tree/sequoia There was some discussion about what to do with the key server network, because the concern is that the network might go down soon due to either the GDPR, the recent keyserver-fs, or both. The keyserver network is seen as a critical infrastructure for OpenPGP to deliver key updates and revocation certificates, and poor keyserver performance reflects badly on OpenPGP clients. As a result of this discussion, we started implementing a new keyserver on top of Sequoia. On Saturday there were talks at Freiburg's CCC. Kai presented ideas on defining a subset of OpenPGP, Neal gave a talk introducing Sequoia, and I presented our ideas on how to bring forward secrecy to OpenPGP. Slides (and hopefully soon recordings) can be found at: https://sequoia-pgp.org/talks/ Finally, Azul helped us get continuous integration testing up and running on Gitlab, this will hopefully help us catch mistakes earlier. Unfortunately, the builds on the servers provided by Gitlab are a bit too slow to integrate it in our everyday workflow, but having a CI system is a great step for our project. We are going on vacation over the next month or so, so expect things to slow down a bit in August. That's it for now, thanks for flying with Sequoia :) Justus

3 2

State of the seedling
by Justus Winter 20 Jun '18

20 Jun '18

Hello everyone :) I'd like to inform you about the recent progress on your favorite OpenPGP implementation. We've been quite busy in the last three weeks, and among various cleanups and bug fixes, we implemented the following features: Our frontend gained a new subcommand, sq split, that recursively splits an OpenPGP message into packets that can easily be recombined with cat. Sequoia now supports all ciphers specified in OpenPGP (RFC 4880 and RFC 4880bis) that are supported by our crypto library Nettle, namely TripleDES, Blowfish, AES128, AES192, AES256, Twofish, Camellia128, Camellia192, and Camellia256. Our handling of multi-precision integers changed substantially. Previously, we used plain vectors of MPIs, now we have a sum type that is aware of the kind of data we expect, e.g. whether we have an RSA public key with two MPIs, e and n, or an ECDSA public key with a Curve OID and an MPI q containing the encoded point on the curve. Sequoia now supports verification of DSA signatures, ECDSA signatures using the NIST curves specified in RFC 6637, and EdDSA using Ed25519. Sequoia gained a new type for an OpenPGP message as defined in RFC 4880, section 11.3. The previous message type, which was just a sequence of OpenPGP packets, was renamed to PacketPile to better reflect its unstructured nature. Sequoia now supports encrypting and decrypting of PKESKs using RSA and ECDH/Cv25519. Support for other curves needs a bit more support from our crypto library. The openpgp crate can now be built without compression support, reducing the trusted computing base in case compression is not needed, and making fuzzing of the openpgp crate easier, as the fuzzer can no longer generate compression bombs. Casual fuzzing of the parser revealed all the places where we cut corners, as well a real bug (index out of bounds) when parsing an MPI of length 0. Cheers, Justus

2 1

Update on current developments; Rustfest
by Justus Winter 01 Jun '18

01 Jun '18

Hello everyone :) Neal and I went to Paris for the Rustfest, and we had quite a productive week. Among other things, we thought a lot of how to implement an approximation of forward secrecy that only requires minimal changes to other implementations. This work resulted in several mails to the OpenPGP working group, the most complete description of our proposal being in [0]. 0: https://mailarchive.ietf.org/arch/msg/openpgp/mk8_FSS-n4DVGfh_VwuGtEOS2xk Furthermore, after an inspiring discussion with a Jabber/OMEMO developer, we believe we found a way to implement Signal's double ratchet protocol in a transport-protocol agnostic way in OpenPGP without requiring a rendezvous server. This, however, requires per-device keys, and keeping a lot of state, and therefore requires invasive changes to other implementations. Nevertheless, we are quite excited about the prospect :) Besides conceptual work, we also got to do some hacking during the impl days. While some rough edges remain, we are happy to report that our low-level OpenPGP library can do almost anything that does not require secret keys. Let's have a look at what we can do with our command line tools! Symmetric Encryption/Decryption ------------------------------- % sq encrypt -s -i plaintext -o ciphertext.pgp Enter passphrase: huhu % sq decrypt -i ciphertext.pgp Enter passphrase to decrypt message: huhu Hello world! Neat! What else? % sq encrypt -s -s -i plaintext -o ciphertext.pgp Enter passphrase 1: huhu Enter passphrase 2: haha % sq decrypt -i ciphertext.pgp Enter passphrase to decrypt message: huhu Hello world! % sq decrypt -i ciphertext.pgp Enter passphrase to decrypt message: haha Hello world! Sweet! Support for multiple passphrases. Key Store --------- Sequoia has a Key Store that manages and updates public keys. Let's see what my store has to offer: % sq store list +-------+----------------------------------------------------+ | label | fingerprint | +-------+----------------------------------------------------+ | me | CBCD 8F03 0588 653E EDD7 E265 9B7D D433 F254 904A | | neal | 8F17 7771 18A3 3DDA 9BA4 8E62 AACB 3243 6300 52D9 | | kai | FEC1 5429 6C79 773B 1562 511A 65AC 504E B50A 8C43 | +-------+----------------------------------------------------+ The store maps user-defined labels to keys. Let's add another one! % sq store add dkg 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 % sq store log dkg +------------------+----------------------------------------+ | timestamp | message | +------------------+----------------------------------------+ | 2018-05-31 19:13 | New binding dkg -> CCD2 ED94 D217 39E9 | +------------------+----------------------------------------+ Note that I only specified the fingerprint, I did not supply any key material. Now if I wait a little while, the keystore will reach out to the keyservers and fetch the key material. In the future, it should force an update if the user wants to use the key before an update occurred. It will continue to update the key at random intervals, like parciemonie (although currently we do not support TOR, that requires authentication support in the SOCKS middleware for our http library). % sq store log dkg +------------------+----------------------------------------+ | timestamp | message | +------------------+----------------------------------------+ | 2018-05-31 19:16 | Update successful | | 2018-05-31 19:13 | New binding dkg -> CCD2 ED94 D217 39E9 | +------------------+----------------------------------------+ The log is a machine-readable history of this binding. Neat! What can we do with that now? Asymmetric Encryption --------------------- % sq encrypt -r me -r dkg -i plaintext -o ciphertext.pgp % gpg --decrypt ciphertext.pgp gpg: encrypted with 4096-bit RSA key, ID E3A32229449B0350, created 2017-12-04 "Daniel Kahn Gillmor <dkg(a)fifthhorseman.net>" gpg: encrypted with 2048-bit RSA key, ID 08CC70F8D8CC765A, created 2017-07-19 "Justus Winter <justus(a)sequoia-pgp.org>" Hello world! Kai is working on secret key support, this should land soonish. As of now, we only support RSA, cv25519 is planned next. To get an idea how to do that from Rust with our low-level API, please look at our example [1]. 1: https://gitlab.com/sequoia-pgp/sequoia/blob/master/openpgp/examples/encrypt… Signature Verification ---------------------- We have been working on a replacement for gpgv, a stripped down version of GnuPG suitable for e.g. package verification. Our tool is called sqv: % sqv --keyring me.pgp huhu.sig huhu ; echo $? CBCD 8F03 0588 653E EDD7 E265 9B7D D433 F254 904A 0 Packet Stream Dumping --------------------- sq can be used to inspect OpenPGP data: % sq dump -i huhu.signed.detached Signature(Signature { version: 4, sigtype: Binary, issuer: "256A 4E55 E4A7 2D97 AD24 68E7 88DC 7E33 385F 791D", pk_algo: RsaEncryptSign, hash_algo: SHA256, hashed_area: {IssuerFingerprint: SubpacketArea { critical: false, tag: IssuerFingerprint, value (21 bytes): [4, 37, 106, 78, 85, 228, 167, 45, 151, 173, 36, 104, 231, 136, 220, 126] }, SignatureCreationTime: SubpacketArea { critical: false, tag: SignatureCreationTime, value (4 bytes): [90, 233, 129, 79] }}, unhashed_area: {Issuer: SubpacketArea { critical: false, tag: Issuer, value (8 bytes): [136, 220, 126, 51, 56, 95, 121, 29] }}, hash_prefix: "4390", computed_hash: None, mpis: ["2047 bits: 7EB8 37F5 D246 0299 B633 15A5 599A A3CB 87D7 6E52 0CB9 820A E238 AF28 6FCE 77D3 FD24 871B 681E 59C3 6EE9 D848 00C6 7FF7 B3E5 CFD5 F1E1 0901 107B BE97 DA75 7BA0 E8F9 A8C7 BE98 5E8C 06CB BC36 014A DCF0 6A13 BC8E AD9D 52B5 BE46 4C19 55E6 10FD 44D4 649A D7F1 475A FC2B BD7A CA3A 88B7 E91F 3271 4F85 7BDA 4DDD C588 51C0 2B04 CC79 B10D 6DB2 D280 F06A 6556 26E0 BD74 67C7 7DF3 7011 83CA 3D0A 7AAB D378 89F0 E6B6 0F90 A2D4 B387 CE66 FF85 34DE 8204 16E7 4074 FDCA 81E7 A8F6 77FF FACB 8419 06F9 2469 294E F800 41AE 30FA 073F 632E D211 783A 3929 083A 3D67 0CA3 EBF6 FCBF D34F 43E0 2F85 DB4B 2559 F666 E1DA A476 8828 425D A7FA F906 1A19 CCD7 0614 1F95"] }) And for the real curious, we can print an annotated hex dump: % sq dump --hex -i huhu.signed.detached Signature(Signature { version: 4, sigtype: Binary, issuer: "256A 4E55 E4A7 2D97 AD24 68E7 88DC 7E33 385F 791D", pk_algo: RsaEncryptSign, hash_algo: SHA256, hashed_area: {IssuerFingerprint: SubpacketArea { critical: false, tag: IssuerFingerprint, value (21 bytes): [4, 37, 106, 78, 85, 228, 167, 45, 151, 173, 36, 104, 231, 136, 220, 126] }, SignatureCreationTime: SubpacketArea { critical: false, tag: SignatureCreationTime, value (4 bytes): [90, 233, 129, 79] }}, unhashed_area: {Issuer: SubpacketArea { critical: false, tag: Issuer, value (8 bytes): [136, 220, 126, 51, 56, 95, 121, 29] }}, hash_prefix: "4390", computed_hash: None, mpis: ["2047 bits: 7EB8 37F5 D246 0299 B633 15A5 599A A3CB 87D7 6E52 0CB9 820A E238 AF28 6FCE 77D3 FD24 871B 681E 59C3 6EE9 D848 00C6 7FF7 B3E5 CFD5 F1E1 0901 107B BE97 DA75 7BA0 E8F9 A8C7 BE98 5E8C 06CB BC36 014A DCF0 6A13 BC8E AD9D 52B5 BE46 4C19 55E6 10FD 44D4 649A D7F1 475A FC2B BD7A CA3A 88B7 E91F 3271 4F85 7BDA 4DDD C588 51C0 2B04 CC79 B10D 6DB2 D280 F06A 6556 26E0 BD74 67C7 7DF3 7011 83CA 3D0A 7AAB D378 89F0 E6B6 0F90 A2D4 B387 CE66 FF85 34DE 8204 16E7 4074 FDCA 81E7 A8F6 77FF FACB 8419 06F9 2469 294E F800 41AE 30FA 073F 632E D211 783A 3929 083A 3D67 0CA3 EBF6 FCBF D34F 43E0 2F85 DB4B 2559 F666 E1DA A476 8828 425D A7FA F906 1A19 CCD7 0614 1F95"] }) 00000000 89 01 33 header 00000003 04 version 00000004 00 sigtype 00000005 01 pk_algo 00000006 08 hash_algo 00000007 00 1d hashed_area_len 00000009 16 21 04 25 6a 4e 55 hashed_area 00000010 e4 a7 2d 97 ad 24 68 e7 88 dc 7e 33 38 5f 79 1d 00000020 05 02 5a e9 81 4f 00000026 00 0a unhashed_area_len 00000028 09 10 88 dc 7e 33 38 5f unhashed_area 00000030 79 1d 00000032 43 hash_prefix1 00000033 90 hash_prefix2 00000034 07 ff 7e b8 37 f5 d2 46 02 99 b6 33 mpis 00000040 15 a5 59 9a a3 cb 87 d7 6e 52 0c b9 82 0a e2 38 00000050 af 28 6f ce 77 d3 fd 24 87 1b 68 1e 59 c3 6e e9 00000060 d8 48 00 c6 7f f7 b3 e5 cf d5 f1 e1 09 01 10 7b 00000070 be 97 da 75 7b a0 e8 f9 a8 c7 be 98 5e 8c 06 cb 00000080 bc 36 01 4a dc f0 6a 13 bc 8e ad 9d 52 b5 be 46 00000090 4c 19 55 e6 10 fd 44 d4 64 9a d7 f1 47 5a fc 2b 000000a0 bd 7a ca 3a 88 b7 e9 1f 32 71 4f 85 7b da 4d dd 000000b0 c5 88 51 c0 2b 04 cc 79 b1 0d 6d b2 d2 80 f0 6a 000000c0 65 56 26 e0 bd 74 67 c7 7d f3 70 11 83 ca 3d 0a 000000d0 7a ab d3 78 89 f0 e6 b6 0f 90 a2 d4 b3 87 ce 66 000000e0 ff 85 34 de 82 04 16 e7 40 74 fd ca 81 e7 a8 f6 000000f0 77 ff fa cb 84 19 06 f9 24 69 29 4e f8 00 41 ae 00000100 30 fa 07 3f 63 2e d2 11 78 3a 39 29 08 3a 3d 67 00000110 0c a3 eb f6 fc bf d3 4f 43 e0 2f 85 db 4b 25 59 00000120 f6 66 e1 da a4 76 88 28 42 5d a7 fa f9 06 1a 19 00000130 cc d7 06 14 1f 95 Usability improvements ---------------------- Our tools now detect and automatically handle armored data. The store subcommand no longer takes the store name as positional argument. For an overview what our tools can do, see [2] and [3]. 2: https://docs.sequoia-pgp.org/sq/index.html 3: https://docs.sequoia-pgp.org/sqv/index.html Cheers, Justus

1 0

Decryption support in the tool & Python bindings
by Justus Winter 27 Mar '18

27 Mar '18

Hi :) I went ahead and implemented support for decrypting symmetrically encrypted messages in our 'sq' tool, mostly to get a feeling for how the parser works: % echo 123456789 | sq decrypt -i openpgp/tests/data/messages/encrypted-aes128-password-123456789.gpg 2>/dev/null | head -n 8 A Cypherpunk's Manifesto by Eric Hughes Privacy is necessary for an open society in the electronic age. Privacy is not secrecy. A private matter is something one doesn't want the whole world to know, but a secret matter is something one doesn't want anybody to know. Privacy is the power to selectively reveal oneself to the world. For the curious, here [0] is the code. Note that this code is using the low-level API, we don't expect that every application developer will use this, but 0/ some people might, and b/ currently there is no high-level API. 0: https://gitlab.com/sequoia-pgp/sequoia/commit/30604553c08564e27621ce1e022cf… Then I was curious how the parser API would translate to the foreign function interface, so I added just barely enough glue to be able to do the same from C or Python. The Python version looks like this: import sys import os from getpass import getpass from enum import Enum, auto from sequoia.core import Context, NetworkPolicy from sequoia.openpgp import Tag, PacketParser ctx = Context("org.sequoia-pgp.tests", network_policy=NetworkPolicy.Offline, ephemeral=True) class State(Enum): Start = auto() Decrypted = auto() Deciphered = auto() Done = auto() state = State.Start algo, key = None, None pp = PacketParser.open(ctx, sys.argv[1]) while pp.has_packet: packet = pp.packet tag = packet.tag if state == State.Start: if tag == Tag.SKESK: passphrase = getpass("Enter passphrase to decrypt message: ") algo, key = packet.match().decrypt(passphrase.encode()) state = State.Decrypted elif tag == Tag.PKESK: sys.stderr.write("Decryption using PKESK not yet supported.\n") elif state == State.Decrypted: if tag == Tag.SEIP: pp.decrypt(algo, key) state = State.Deciphered elif state == State.Deciphered: if tag == Tag.Literal: body = pp.buffer_unread_content() os.write(sys.stdout.fileno(), body) state = State.Done pp.recurse() assert state == State.Done It is structured like the Rust version and I think it looks quite reasonable. (To use it, grab the latest Python branch from [1]). 1: https://gitlab.com/sequoia-pgp/sequoia/tree/justus/python-4 Cheers, Justus

1 0

Playing with the Python bindings
by Justus Winter 16 Mar '18

16 Mar '18

Hello :) I have been working on the foreign function interface, aka our C API. Instead of writing tests for that, I decided to write bindings for Python and testing that. This also gives me a feel for how complete and usable the C API is. And while there is no documentation yet, I have integrated it in our new build system and I invite you to try it out. Even if you are not into Python, it is a nice way to interactively play with Sequoia. To get it, either checkout the 'justus/python-3' branch or clone it using: % git clone -b justus/python-3 https://gitlab.com/sequoia-pgp/sequoia.git In addition to the build dependencies mentioned in 'README.md', you need python3-dev, python3-cffi (poke me if I missed any additional dependencies) and ipython3 (only for the nice interactive shell). Then do 'make', followed by: % make -Cffi/lang/python shell [... stuff...] IPython 5.5.0 -- An enhanced Interactive Python. ? -> Introduction and overview of IPython's features. %quickref -> Quick reference. help -> Python's own help system. object? -> Details about 'object', use 'object??' for extra details. In [1]: Wow, an interactive Python shell with all of Sequoias functionality already imported for you and a Context 'ctx' already created for your convenience is at your fingertips. Let's have some fun: In [1]: fp = Fingerprint.from_hex("D2F2C5D45BE9FDE6A4EE0AAF31855247603831FD") In [2]: keyid = fp.keyid() In [3]: tpk = KeyServer.sks_pool(ctx).get(keyid) In [4]: assert fp == tpk.fingerprint() In [5]: st = Store.open(ctx, "my awesome store") In [6]: st.import_("Justus' signing key", tpk) Out[6]: <sequoia.openpgp.TPK at 0x7fc5c0142780> In [7]: binding = st.lookup("Justus' signing key") In [8]: list(map(str, binding.log())) Out[8]: ["2018-03-16 13:10:10+00:00: org.sequoia-pgp.tests.interactive:my awesome store: New binding Justus' signing key -> 3185 5247 6038 31FD"] For more ideas you can look into ffi/lang/python/tests. Cheers, Justus

1 0

Symmetric decryption
by Neal H. Walfield 28 Feb '18

28 Feb '18

Hi, I'm pleased to report that I've just added support for decrypting SEIP packets as well as verifying MDC packets to Sequoia. See: https://gitlab.com/sequoia-pgp/sequoia/commit/e304deb0fc7a92801cf3ba58aafeb… Currently, there is only a low-level interface. The basic usage is more or less shown in the decryption unit test: https://gitlab.com/sequoia-pgp/sequoia/blob/e304deb0fc7a92801cf3ba58aafeb14… Basically, we create a packet parser as usual: let mut pp = PacketParserBuilder::from_file(&path).unwrap() .buffer_unread_content() .finalize() .expect(&format!("Error reading {}", filename)[..]) .expect("Empty message"); Then, we iterate over the message, and when we encounter a SEIP packet, we decrypt it: if let Packet::SEIP(_) = pp.packet { pp.decrypt(algo, &key[..]).unwrap(); } Now, if we recurse on the SEIP packet (pp.recurse() instead of pp.next()), we will iterate over the decrypted packets (otherwise the decrypted data will be stored in packet.body). When we encounter the MDC packet, we can check the hash as follows: if let Packet::MDC(mdc) = pp.packet { assert_eq!(mdc.computed_hash, mdc.hash); } Right now, it is up to the implementation to gather the SK-ESK and PK-ESK packets and extract the symmetric encryption algorithm and session key. When using a Message to parse a message all a once, it is currently not possible to decrypt the SEIP packets. Another current limitation has to do with the packet parser and not symmetric decryption per se: when a packet in the SEIP packet has an indefinite length (which is how GnuPG encodes the length of compressed data packets), Sequoia assumes that the remaining data belongs to packet with the indefinite length; if some data is unread, Sequoia just drops the data instead of looking for more packets. If someone is looking for a small project, consider adding a decrypt command to sq. :) Neal

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

Devel