Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GPG import ($50) #123

Open
campadrenalin opened this issue Apr 4, 2013 · 6 comments

Comments

Projects
None yet
2 participants
@campadrenalin
Copy link
Owner

commented Apr 4, 2013

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.

@campadrenalin

This comment has been minimized.

Copy link
Owner Author

commented Apr 8, 2013

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.

@campadrenalin

This comment has been minimized.

Copy link
Owner Author

commented Apr 8, 2013

@soulseekah

This comment has been minimized.

Copy link

commented Apr 23, 2013

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

@campadrenalin

This comment has been minimized.

Copy link
Owner Author

commented Apr 23, 2013

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

This comment has been minimized.

Copy link

commented Apr 23, 2013

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?

@campadrenalin

This comment has been minimized.

Copy link
Owner Author

commented Apr 23, 2013

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//issues/123#issuecomment-16842676
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.