[cryptography] OpenPGP in Python: Security evaluations?

Michael Greene mgreene at securityinnovation.com
Fri Jun 12 17:20:16 EDT 2015


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

Right, and we’re not trying to integrate that far - I probably should have explained that a little more clearly. The idea is that we want tasks relating to managing and using keys to live in one process space, instead of duplicating them across two, and to eliminate the need to use Popen and pipes to accomplish that communication. It’s a lot slower because of the additional overhead, and it just feels kludgey. As you mentioned libassuan, a better method of IPC is needed than just Popen and pipes, and there’s no reason PGPy couldn’t be used in that way.

Thanks for the other information, though, that is useful for me. Our earlier internal audit was focused primarily on finding some of that low-hanging fruit. Since PGPy is all Python, compilers aren’t much help in this case. Other than pylint, which doesn’t touch on anything security related, I don’t know of any analysis tools that support Python. Coverity Scan appears to only support Java, C/C++, and C#. Do you or anyone else on the list know of any that are worth checking out?
--
Michael Greene
Software Engineer
mgreene at securityinnovation.com

> On Jun 12, 2015, at 4:05 AM, Jeffrey Walton <noloader at gmail.com> wrote:
> 
>> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20150612/3c53ce42/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3298 bytes
Desc: not available
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20150612/3c53ce42/attachment.p7s>


More information about the cryptography mailing list