Repository navigation
GPG import ($50) #123
Description
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"
]
}
}
Activity
MaddieM4 commentedon 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.
MaddieM4 commentedon Apr 8, 2013
http://www.gnupg.org/gph/en/manual/x56.html
soulseekah commentedon Apr 23, 2013
Since GPG keys are actually exported separately (
--exportand--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 eitherejtp-identity gpg import <pubkey filename> <privkey filename>orcat pubkey privkey > keys && ejtp-identity gpg import keys.Instead of files, one can interface with the
gpgbinary 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 forgpgbinary to be available.Any thoughts? I'm ready to take on both import and export of RSA/RSA (only) keys (preferably directly using the
gpgbinary, via the built-insubprocessmodule).MaddieM4 commentedon 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 commentedon Apr 23, 2013
You are right about the derivation of the public key from a private key.
gpgautomatically 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
rsaencryptor won't support gpg keys. A new encryptor would have to interface withgpgfor both encryption and decryption.One could theoretically extract the
e,n,d,pandqnecessary for encryption and decryption and wrap them up into PEM or DER PKCS envelopes for use with PyCrypto (i.e. use the existingrsaencryptor); 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 usinggpgviasubprocessinvolves 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 perhapsopenssl 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 thekeydatadirectly 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 thersaencryptor.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 commentedon 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: