securityinnovation / pgpy

Pretty Good Privacy for Python

PGPy: Pretty Good Privacy for Python

PGPy is a Python library for implementing Pretty Good Privacy into Python programs, conforming to the OpenPGP specification per RFC 4880.

Features

Currently, PGPy can load keys and signatures of all kinds in both ASCII armored and binary formats.

It can create and verify RSA, DSA, and ECDSA signatures, at the moment. It can also encrypt and decrypt messages using RSA and ECDH.

Installation

To install PGPy, simply:

$ pip install PGPy

Documentation

PGPy Documentation on Read the Docs

Discussion

Please report any bugs found on the issue tracker

You can also join #pgpy on Freenode to ask questions or get involved

Requirements

• Python >= 3.6

  Tested with: 3.10, 3.9, 3.8, 3.7, 3.6

• Cryptography
• pyasn1
• six

License

BSD 3-Clause licensed. See the bundled LICENSE file for more details.

pgpy's Issues

Decrypt Secret Key Material that was encrypted with Camellia128

Key material added in 0911f56

Decrypt Secret Key Material that was encrypted with 3DES

Key material added in 0911f56

Test FileLoader against a non-existent URL

https://coveralls.io/files/190133283#L59

Verify inline signatures

Currently, verifying an inline signature is not directly possible (but it can be done by splitting the message and signature out ahead of time), but it should be.

PGP Packets created by PGPy should use new style header length formats

I don't think compatibility with PGP 2.x (not GPG) is an issue, and GPG can understand new-style packet length headers no problem.

Therefore, we should (by default) create GPG packets using new-style headers (while still understanding old-style, of course)

Code Cleanup: Abstract all subpackets out to be a subclass of SubPacket

This should make the code a bit easier to follow.

Update the CI test matrix to test against OpenSSL 0.9.8

Currently, Travis is testing only against one version of OpenSSL (which I assume is 1.0.1, as that is what ships with Ubuntu 12.04 currently). The test matrix should be updated to test against 0.9.8 as well.

Looking at apt, openssl_1.0.1-4ubuntu3 is the default, which uses libssl_1.0.0. libssl_0.9.8 is also in the repo. Also, cryptography has openssl 0.9.8 in their test matrix.

Coveralls

I'll set up Coveralls for this repo and see how it looks.

Verify document/signature

In heading for the first release, we need to be able to verify a document against a provided signature.

Signing Binary Documents with DSA

Like #15, this is waiting on pyca/cryptography to release 0.4.0

Test FileLoader against a file that does not exist but a valid directory path

https://coveralls.io/files/190133283#L72

Sphinx docs for 0.1.0

Initial Sphinx documentation needs to cover the following classes:

• PGPKeyring
• SignatureVerification

Decrypt Secret Key Material that was encrypted with AES192

Key material added in 0911f56

Add an assertion to TestPGPKeyring.test_sign_with_encrypted_rsa

... to ensure that sec_keymaterial.empty is True on all secret key (both packets and subpackets) after leaving the context management block.

Allow exporting of keys from PGPKeyring objects

We should be able to export keys that are loaded into PGPKeyring objects.

This should be about 95% working already. There are two things that need to be accounted for:

• According to the RFC, trust packets should not be exported (and therefore ignored) - which should be trivial to implement.
• A key loaded from a keyring can not yet determine its magic string for output, so that should also be fixed

Test FileLoader against a completely invalid path

https://coveralls.io/files/190133283#L78

Change PGPKeyring context manager

Currently, the context manager is pretty useless aside from syntactical flavor:

with PGPKeyCollection(keys) as k:
    # do stuff with k

I think it would be much nicer to use context management to decide which loaded key to use. Something more like this:

kc = PGPKeyCollection(keys)

with kc.key(id='DEADBEEF'):
    kc.sign(document)

Decrypt Secret Key Material that was encrypted with Blowfish

Key material added in 0911f56

Decrypt Secret Key Material that was encrypted with AES128

Key material added in 0911f56

PGPDump revisit

• add format abstract method to PGPObject
• add format methods to PGPObject concrete subclasses, with the following flags:
  • a (for PGP* objects; also default for them) - just returns str(self) if Exportable; otherwise, raises ValueError('Invalid format specifier')
  • g for gpg --list-packets-style output
  • p[impl]... for pgpdump-style output with the corresponding flags (default for non-Exportables)

Secret keys are not being properly parsed

Currently, secret key parsing is not working properly, and it's failing on the multi-precision integer fields.

Thinking about it, and re-reading the appropriate part of RFC 4880, I'm guessing it's because I'm not fully parsing secret key information.

In order to fix it, I'll have to more intelligently parse the MPI fields based on algorithm.

Find a PGP block with a new style packet header to test against

https://coveralls.io/files/190133271#L105

PGPKeyring should add Trust packets to keys imported without them

Importing keys from a GPG keyring includes trust packets.

As mentioned in #10, exporting keys to ASCII armored blocks should not include Trust packets. Per RFC 4880:

The Trust packet is used only within keyrings and is not normally
exported.  Trust packets contain data that record the user's
specifications of which key holders are trustworthy introducers,
along with other information that implementing software uses for
trust information.  The format of Trust packets is defined by a given
implementation.

Trust packets SHOULD NOT be emitted to output streams that are
transferred to other users, and they SHOULD be ignored on any input
other than local keyring files.

So, we should be able to specify how much we trust a given key.

Use libgcrypt for crypto

OpenSSL does not reliably provide everything we need (and it's pretty heavy, as well).

It's probably worth switching to using libgcrypt (through cffi) and just piggybacking on GPG instead of OpenSSL.

Fix PKG-INFO formatting

It's kinda messed up!

Decrypt Secret Key Material that was encrypted with IDEA

Key material added in 0911f56

Relicense with BSD 3-Clause

PGPy should raise an exception if a requested algorithm/keysize combo is not supported by the current OpenSSL backend

Use cryptography.hazmat.backends.openssl.backend.cipher_supported() to do this.

Then, we can catch that exception and imperatively xfail

Load keys in non-PGP formats

It might be nice to be able to load keys from other formats (like X.509)

Sign binary document

In heading for the first release, we'll need to be able to use a loaded secret key to sign a binary document (signature type 0x00).

Remove SubPackets parameter methods

They aren't really all that useful, and it's possible to have more than one of most subpacket types anyhow.

Decrypt Secret Key Material that was encrypted with Twofish

Key material added in 0911f56

Load ASCII armored public and private keys

This is complete

Add unit test to test that Managed raises errors in the proper conditions

see: https://coveralls.io/files/193954137#L33

Create protected secret keys in other formats for further testing

Decrypt Secret Key Material that was encrypted with AES256

Key material added in 0911f56

Signing with 1024-bit DSA keys does not work on OSX (OpenSSL 0.9.8y)

Signing with DSA keys with p > 1024 bits works fine (although verifying signatures that were generated using keys with p > 1024 bits does not work). However, signing with DSA keys with p == 1024 bits does not work (see #16)

It is probably worth testing against multiple versions of OpenSSL, so the travis test-matrix should be updated to reflect this as well.

refactor unit tests

It's getting quite messy and a little bit out of hand to continue adding test material.

This will be a several step process:

• Throw away all current test keys
• Regenerate new test keys, like so, with the following naming convention:
  Test{alg}[-Enc{encalg}]-{bits}[.sec].key into the current directories.
  • unencrypted key material:
    • RSA (and RSA)
      • 1024-bit
      • 2048-bit
      • 3072-bit
      • 4096-bit
    • DSA (and ElGamal)
      • 1024-bit
      • 2048-bit
      • 3072-bit
      • 4096-bit
    • RSASignOnly
      • 1024-bit
      • 2048-bit
      • 3072-bit
      • 4096-bit
    • DSASignOnly
      • 1024-bit
      • 2048-bit
      • 3072-bit
      • 4096-bit
• encrypted key material:
  • RSA (1024-bit)
    • IDEA
    • CAST5
    • CAST5Simple (--s2k-mode 0)
    • CAST5SaltedS2K (--s2k-mode 1)
    • CAST5MD5 (--s2k-digest-algo MD5)
    • CAST5SHA1 (--s2k-digest-algo SHA1)
    • CAST5RIPEMD160 (--s2k-digest-algo RIPEMD160)
    • CAST5SHA256 (--s2k-digest-algo SHA256)
    • CAST5SHA384 (--s2k-digest-algo SHA384)
    • CAST5SHA512 (--s2k-digest-algo SHA512)
    • CAST5SHA224 (--s2k-digest-algo SHA224)
    • 3DES
    • AES128
    • AES192
    • AES256
    • Blowfish
    • Camellia128
    • Camellia192
    • Camellia256
    • Twofish
  • DSA (1024-bit)
    • CAST5
• Move keylists to conftest.py
• Use gpg to sign tests/testdata/signed_message with each generated key above for testing signature verification
• Rename TestPGPKeyring.test_sign_with_key to TestPGKeyring.test_sign
• Refactor the parametrization for TestPGPKeyring.test_sign

Create inline signatures

Currently, there is an inline flag for PGPKeyring.sign(), but it has no effect.

We should be able to create inline signatures like GPG does.

Load ASCII armored signatures

This is complete already.

decrypt passphrase-protected secret keys

As it turns out, if you export a passphrase-protected secret key to the ASCII armored format, the key material itself remains protected.

We need to be able to load this key material properly, and decrypt it using a correct passphrase.

Decrypt Secret Key Material that was encrypted with Camellia192

Key material added in 0911f56

Need to find a good crypto library

Before I can continue, I need to find a good crypto library (or set of libraries, as the case may be) that support the following algorithms:

Symmetric-Key Algorithms

• IDEA
• TripleDES
• CAST5
• Blowfish
• AES 128, 192, 256
• Twofish

Of these, TripleDES is the only one explicitly required for all implementations by the RFC specification; CAST5 and AES128 are heavily recommended.

IDEA is required only if the implementation needs to be able to interact with PGP 2.6.

Public-Key Algorithms

• RSA
• ElGamal
• DSA

RSA and DSA are the two Public-Key algorithms that are required for signing things.

ElGamal is used for encryption only (for DSA keys generated with the ability to also encrypt). Naturally, RSA can be used for encryption also, unless the key is marked as being for signing only.

Add unit test to test an invalid signature

Two scenarios:

• Signature is just wrong
• Signature subject has changed

see: https://coveralls.io/files/193954137#L430

DSA Signature Verification

This is waiting on the impending release of Cryptography 0.4. Release 0.1.0 only really needs to understand RSA signatures, though, so this shouldn't block that.

Decrypt Secret Key Material that was encrypted with Camellia256

Key material added in 0911f56

Understand GPG Trust Packets

Currently, we can import a Trust packet no problem.

However, there is no parsing taking place - the payload stays in byte form, and it is meaningless.

PGPy should be able to understand a GPG Trust packet when loading an existing GPG keyring, so those trust preferences are maintained.

Load keys from a GPG keyring file

In working toward the first release, I still need to be able to load a GPG keyring file.

This will include being able to load public and secret keys from a keyring, as well as password protected secret keys.

Key material is not being tested currently

Currently, parsing PGP blocks is being done against the Python pgpdump pakage, which is very good.

However, I have not figured out how to compare key material with it (it may not allow that).

At any rate, I need to be able to check key material when parsing blocks to ensure everything is done right. As it stands, I am getting false positives on parsing keys properly because key material is not being checked.

Prepare for Release 0.1.0

Looks like Release 0.1.0 is about ready to go.

So, a couple small tasks left:

• Start the release branch
• Bump the version to 0.1.0
• Read through all the documentation and verify its correctness.
• Think about initial documentation for PGPSignature and PGPKey
• Fill in some missing enum returns (most notably, HashAlgo)
• Hide the package path in Sphinx for pgpy.signature.SignatureVerification
• Add additional exception classes whenever a method can raise the same one in multiple situations
• Publish documentation to github.io
• Make sure setup.py works correctly
• Last round of testing

And finally, sign the release, merge to master, tag as a release, and register the package to PyPI!