GPG import ($50)

[MaddieM4]

Add the ability to import GPG keys into the encryptor cache via ejtp-identity. Should act like ejtp-identity new in terms of its output and behavior, with all parameters overrideable.

$ ejtp-identity gpg import joe.gpg
{
    "[\"gpg\", null, \"Joe Blow (generated by Retroshare) <joe@blow.net>\"]": {
        "encryptor": [
            ...
        ],
        "name": "joe@blow.net",
        "owner": "Joe Blow",
        "purpose": "generated by Retroshare",
        "created": "2012-06-19",
        "expires": "2012-10-17",
        "location": [
            "gpg",
            null,
            "Joe Blow (generated by Retroshare) <joe@blow.net>"
        ]
    }
}
$ ejtp-identity gpg import joe.gpg --location='["udp4", ["ejtp.blow.net", 9090], "joe"]'
{
    "[\"udp4\", [\"ejtp.blow.net\",9090], \"joe\"]": {
        "encryptor": [
            ...
        ],
        "name": "joe@blow.net",
        "owner": "Joe Blow",
        "purpose": "generated by Retroshare",
        "created": "2012-06-19",
        "expires": "2012-10-17",
        "location": [
            "udp4",
            [
                "ejtp.blow.net",
                9090
            ],
            "joe"
        ]
    }
}

~Depends on #122 for obvious reasons.~ #122 is done.

[MaddieM4]

Bounty is $50.

http://www.freedomsponsors.org/core/issue/231/gpg-import

---

(Copied from acceptance criteria)

Add facility to decode GPG key data files into EJTP identities with extended attributes, according to given examples and any relevant in-thread discussion.

[MaddieM4]

http://www.gnupg.org/gph/en/manual/x56.html

[soulseekah]

Since GPG keys are actually exported separately (--export and --export-secret-keys) this means that there is no one file to import, there will be two (unless of course we merge them into one file, but this is not standard). So either ejtp-identity gpg import <pubkey filename> <privkey filename> or cat pubkey privkey > keys && ejtp-identity gpg import keys.

Instead of files, one can interface with the gpg binary instead to issue the necessary commands in sequence, with the command usage being: ejtp-identity gpg import <email/id> [--homedir] [--gpg-bin]. This would allow simpler import from the pubring without having to export the keys and merge them thereafter for import. One obvious drawback is the requirement for gpg binary to be available.

Any thoughts? I'm ready to take on both import and export of RSA/RSA (only) keys (preferably directly using the gpg binary, via the built-in subprocess module).

[MaddieM4]

Sounds good to me. I don't know if this is true of other asymmetric encryption standards, but in RSA, all you need is the private key, and you can derive the public key from that. But even if I'm mistaken there, calling the gpg binary with subprocess gives us the freedom to present a nice interface, regardless of the details underneath.

[soulseekah]

You are right about the derivation of the public key from a private key. gpg automatically derives the public key from a private key during import; so storing the private key should theoretically be enough inside an identity file.

However, GPG's key format is not enveloped into the expected PKCS wrapper standards (i.e. not compatible with later versions of PyCrypto [https://bugs.launchpad.net/pycrypto/+bug/996814]). What this means is that in order to make use of these new gpg identities a new encryptor would have to be written, since the regular rsa encryptor won't support gpg keys. A new encryptor would have to interface with gpg for both encryption and decryption.

One could theoretically extract the e, n, d, p and q necessary for encryption and decryption and wrap them up into PEM or DER PKCS envelopes for use with PyCrypto (i.e. use the existing rsa encryptor); reference: http://neva.li/post/9685063505 and http://tools.ietf.org/html/rfc4880. This seems to be the better approach as having clients encrypt/decrypt using gpg via subprocess involves some deployment overhead perhaps (http://www.saltycrane.com/blog/2011/10/python-gnupg-gpg-example/ or more low-level gpgme-based solution https://launchpad.net/pygpgme).

So what I'm thinking is that importing would involve conversion from OpenPGP format (4880 compliance seems fair, or maybe PKCS12 using --export-secret-key-p12, then perhaps openssl pkcs12 -in key.p12 -nodes -nocerts > key.pem) to PKCS1 version 1.5 supported by PyCrypto. Not sure how exporting #124 would work yet. A simpler approach would be to rip out the RSA primitives (based perhaps on bits of code from https://pypi.python.org/pypi/pgpdump/) and inject them into the keydata directly as per https://www.dlitz.net/software/pycrypto/api/current/Crypto.PublicKey.RSA._RSAobj-class.html#keydata exporting to PEM-encoded PKCS#1 inside the identity data. This could then be used directly with the rsa encryptor.

Using something like https://launchpad.net/pygpgme is certainly way easier than conversion of key and signature envelopes for PyCrypto, but requires additional dependencies and a new encrypter.

Ideas? Suggestions?

[MaddieM4]

This definitely sounds like you're on the right track. Hopefully the conversion algorithm isn't too insane to write. On Apr 23, 2013 12:05 AM, "soulseekah" notifications@github.com wrote:

You are right about the derivation of the public key from a private key. gpg automatically derives the public key from a private key during import; so storing the private key should theoretically be enough inside an identity file.

However, GPG's key format is not enveloped into the expected PKCS wrapper standards (i.e. not compatible with later versions of PyCrypto [ https://bugs.launchpad.net/pycrypto/+bug/996814]https://bugs.launchpad.net/pycrypto/+bug/996814%5D). What this means is that in order to make use of these new gpg identities a new encryptor would have to be written, since the regular rsa encryptor won't support gpg keys. A new encryptor would have to interface with gpgfor both encryption and decryption.

One could theoretically extract the e, n, d, p and q necessary for encryption and decryption and wrap them up into PEM or DER PKCS envelopes for use with PyCrypto (i.e. use the existing rsa encryptor); reference: http://neva.li/post/9685063505 and http://tools.ietf.org/html/rfc4880. This seems to be the ideal approach as having clients encrypt/decrypt using gpg via subprocess involves a lot of development and deployment overhead.

So what I'm thinking is that importing would involve conversion from OpenPGP format (4880 compliance seems fair) to PKCS1 version 1.5 supported by PyCrypto. Not sure how exporting #124https://github.com/campadrenalin/EJTP-lib-python/issues/124would work yet.

Ideas? Suggestions?

— Reply to this email directly or view it on GitHubhttps://github.com/campadrenalin/EJTP-lib-python/issues/123#issuecomment-16842676 .