Abhilash Raj writes:
After midterm evaluations I have been working on signing the message using one the keys associated with the list, now since
python-gnupgdoes not allow selecting keys with key credentials( like address or list-name name)
Have you tried this? In the GPG documentation, "key ID" often actually means any of the above.[1] If python-gnupg simply passes its argument to the gpg process, it should Just Work. Anyway, it seems to work for me (some output edited for clarity):
venv27 abhilash 15:39$ python2.7 Python 2.7.5 (default, Aug 1 2013, 23:58:20) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. No entry for terminal type "emacs"; using dumb terminal settings.
from gnupg import GPG gpg = GPG(gnupghome='/Users/steve/.gnupg',keyring='test-pub',secret_keyring='test-sec') gpg.list_keys() [{'dummy': u'', 'keyid': u'17A810C33BDFEFA8', 'expires': u'', 'subkeys': [[u'2C376F1897FD6C1C', u'e']], 'length': u'2048', 'ownertrust': u'u', 'algo': u'1', 'fingerprint': u'A36D6B345C18B02E695B8B7917A810C33BDFEFA8', 'date': u'1376462161', 'trust': u'-', 'type': u'pub', 'uids': [u'GPG Test User <gpg-tester@turnbull.sk.tsukuba.ac.jp>']}, {'dummy': u'', 'keyid': u'87EBCC0B6DF8B373', 'expires': u'', 'subkeys': [[u'18E03AE36F3B6DAD', u'e']], 'length': u'1024', 'ownertrust': u'-', 'algo': u'17', 'fingerprint': u'A9FC56DBD48F5E5B61B7137487EBCC0B6DF8B373', 'date': u'1183228371', 'trust': u'-', 'type': u'pub', 'uids': [u'Stephen J. Turnbull (XEmacs Reviewer) <stephen@xemacs.org>']}] crypted = gpg.encrypt(u'A bit of random text.', u'stephen@xemacs.org', always_trust=True) str(crypted) '-----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.14 (Darwin)
hQIOAxjgOuNvO22tEAgAgPUFFCFDKe8zSWt42IG7LkLWWbbTCiAsO7aM2pEgtFrI KxRklwvEOX7bj5cYbmGr1PeM2IH58T4gMMHsYuOUyNzxS1mbsXZ9C4rpE0QJSkPY +5Z10dpHEyAZ030g6uBeubFHC+78as1s10UP16zlVgs2AeZwfM88OBocs7FmUdZr X5uAUxpB5RGET/zc2uHvBzIigXTzUrS8LrTtPfhyP8jCia6klX/2+2Q3gPlENoaP PkIx/vZ7aKCIKyoP+pbLlwGAb/CX1WoQgyrsNFApg/HJhZ3ZLYKcvIqO3PNejOcN 8ZYLRV4Uz0tLCuALCccw+XEZSQTKBoemXqVUwSKCAAf+OiHpMqDMoO7ReVVZg841 MnRcZzfUnL8mj1FZwnr3iTcQ7BdUbu5vMAjn0SIlBISquu0rZi+wynGwgSpWnJeF Llh+gjizNuHUxtO96phbwMeyVrD1yKSxkxC9cY0r8NBo/MTwUmyMCHNKpj0qrome GZI2ekhYjLWfAbX3c6dwBx7pQhwkHkgMmoY6yN0OpLf1urnHGpv+AsEwDmWZ8mz3 CLtD/l9eMl4LGIHNSV7yQ4lAzhYMenNdxkYJyKtxEvM1BFdqOblRb/h+B3X/xtT/ 6ATAK1mZz1nU4H2EB1EvS4rbbQJ6oIevQSz3r/G6jSI7PqPDJvhnzQBrN7wh1pep ldJQASeq3bCushTnFolWVxOgswXm2VFMPnhqEVxBJrZ12nZO2LGN7Y2/W+qQ/Qqb DdYqbYOXNFW9r9p7ugJKKD1kK3XUkTC0Y+t1I/a7dLJBvpA= =olXg -----END PGP MESSAGE----- '
of = open ('/tmp/cryptfile', 'w') of.write(str(crypted)) of.close() signed = gpg.sign('A bit of random text.', passphrase=u'Not useful without my keyring.', keyid=u'gpg-tester@turnbull.sk.tsukuba.ac.jp') str(signed) '-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
A bit of random text. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (Darwin)
iQEcBAEBAgAGBQJSCz30AAoJEBeoEMM73++oWGcH/jS3AJ6OZLm8JHiLAI0AzCXe muRVhPPfGrqL/Jr+l9WA8Zj3pClHa04H0ha3nvYFHPhN30lFDDw56iCPMA+DbJbr 2BeqUSfJj36EGHOi8yV5iljZA4NhAw9qqhwQz7kas+KTeY8+98DQDS10ixVZ92Gv NDxQCKcyTj+6leqy3ePRAgXP5DouTGXntupzPQzcbQW6L8X6h6STOiLAAGKXpGJm t4Fruvbb3kAcqDGCp5Y9kLrxd1unlCp9leoeJeG5NZ5IcI2B4qUwqKdydu9ZMJxS kJYJR1ZNVMtQh/kMNA87GMNv4nd8d5QPD+bm5b4L5BDlibzMGb5Q80mJAKD5xqo= =qHjE -----END PGP SIGNATURE----- '
Decryption of the encrypted file works. I didn't verify the signature, but it looks like it's working.
Also I understand that keeping key safe is one of the important tasks but for the time-being I am simply adding the public and secret keyrings in "VAR_DIR/gpg/", all the list's private keys are in
secring.gpgand all the list's public keys are inpubring.gpgand all the user's public keys are inuserring.gpg. It will be changed to keep the secret keys at a more safer location.
I agree with Richard that there's no particular reason to do anything but put the public keys on one ring.
I don't see any point in putting the private keys somewhere else. As I wrote elsewhere, the weak point in the private keys is the need to supply a password, not the location of the file containing the key. I wonder if there may not be a way to do this using agent forwarding so that the private keys are kept on a different host.
The only issue I can see is that *if* at some point it becomes feasible to use agent forwarding, I suspect only one agent can be used per GPG subprocess.
Footnotes: [1] Has anybody else noticed that both gpg's UI and its documentation seem designed to make it as hard to use as possible?