[cryptography] OpenPGP in Python: Security evaluations?

Jeffrey Walton noloader at gmail.com
Fri Jun 12 07:05:44 EDT 2015


> 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.

I think the trend appears to be the opposite - you have a consumer in
one process and a producer in another process. If the consumer gets
compromised (like a web server), then the secrets don't get
compromised as easily because the producer is out of process.

I'm pretty sure GnuPG switched to that model. Libassuan is the
dependency that's part of that mechanism. And I believe Microsoft's
CryptoNG uses it too (but I may be wrong).

> 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.

There are are a few ways to approach it. The first thing I would do is
pick the low hanging fruit. Its like folks like Bellovin and Guttman
say: why go through the crypto when you can go around it?

Get static and dynamic analyzers on the library. Compilers and their
warning system are a good first line defense. Clang and its sanitzers
are a good tool (https://docs.python.org/devguide/clang.html). And
don't forget about Coverity's free scanning service for FOSS software
(https://scan.coverity.com/).

Once the low hanging fruit is picked, then move onto the specialized
audits, like secure coding for the platform, platform security
integration, and cryptography.

Jeff

On Fri, Jun 12, 2015 at 12:05 AM, Michael Greene
<mgreene at securityinnovation.com> wrote:
> 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.


More information about the cryptography mailing list