Hello there, I am the author of PGPy - I figured I’d chime in here, even though I have clearly noticed this discussion a little bit late.
When I decided that taking up the project of building a pure-Python OpenPGP implementation would be worthwhile, I did so after evaluating all of the existing Python libraries I could manage to find. The main reason I started the project was because very nearly all of the Python libraries for working with PGP were either wrappers around the gpg binary, or GPGME bindings (which itself is a wrapper around the gpg binary, but written in C). To be honest, I’m not sure if calling PGPy “pure-Python” is necessarily 100% correct. Although PGPy itself is 100% implemented in Python, I did not implement any of the actual crypto myself - that is handled by the Cryptography library, which uses cffi to invoke methods from existing libraries (the default currently being OpenSSL, but the possibility to plug into alternate backends exists as well) So basically, practically the only way to be able to use PGP in Python was, one way or another, to call out to the GPG binary (and as it turns out, platform portability in that context is a difficult proposition - the largest category of related StackOverflow questions I happened across while searching for as many of these libraries as I could were questions from people who were having difficulty getting them to work on different platforms - often Windows, but probably not all of them. That particular issue was not something we were necessarily gunning for, but it might be nice for a handful of people, at least.) The main problem we were interested in solving here was to be able to keep key management tasks within a single memory address space, to avoid the problems relating to securely sending passphrases to other processes, and to be able to use the keys without the additional disk IO involved in needing to import the key into an on-disk keyring before being able to use it for anything. As a bonus, it turns out that doing the parsing natively in Python and not having to incur the additional overhead of spinning up an external process and communicate with it over pipes is actually tangibly faster, especially when repeating relatively quick operations (like signing a number of separate things in a row). We did an internal security audit of PGPy 0.3.0 shortly before releasing it, but I would definitely be grateful for additional eyes on the code, maybe when 0.4.0 comes out (which I am working toward). If anyone is interested, wants to share concerns, etc, I would welcome the discussion. -- Michael Greene Software Engineer [email protected]
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
