Hi all,
After midterm evaluations I have been working on signing the message
using one the keys associated with the list, now since python-gnupg
does not allow selecting keys with key credentials( like address or
list-name name) so we need key_id. As barry suggested we can create a
mapping of address to key_ids and store in a seperate table.
I was of the opinion that we need key_ids only for signing the content
and hence need to select only list's keys and not user, so can we add a
new column key_id to the existing list table? So that the key_id is
easily accessible as a list parameter and can be easily updated. One
point in this would be should we allow more than one key associated with
a user( or address? ).
Any comments on this? (barry?)
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.gpg and
all the list's public keys are in pubring.gpg and all the user's
public keys are in userring.gpg. It will be changed to keep the secret
keys at a more safer location.
Abhilash Raj
Abhilash,
I see no reason to have more that one keyring for public keys and another for the private ones. In both cases, those key rings are a flat table indexed by the Key_id. It doesn't matter if the "owner" of the key is a list or a subscriber (or any other user) As for user keys, I think that they should be treated as a ManyToMany relation between the public keys and either the lists or users or, perhaps the subscriptions, in a manner similar to the way that Email addresses are associated with a user.
Wacky
On Aug 13, 2013, at 9:46 AM, Abhilash Raj raj.abhilash1@gmail.com wrote:
Hi all,
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) so we need key_id. As barry suggested we can create a mapping of address to key_ids and store in a seperate table.I was of the opinion that we need key_ids only for signing the content and hence need to select only list's keys and not user, so can we add a new column
key_idto the existing list table? So that the key_id is easily accessible as a list parameter and can be easily updated. One point in this would be should we allow more than one key associated with a user( or address? ). Any comments on this? (barry?)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.
Abhilash Raj
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/rkw%40dataplex.net
Security Policy: http://wiki.list.org/x/QIA9
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?
I agree with everything written elsewhere by Steve and Richard.
On Aug 14, 2013, at 05:35 PM, Stephen J. Turnbull wrote:
[1] Has anybody else noticed that both gpg's UI and its documentation seem designed to make it as hard to use as possible?
Sadly, I think this is one of the biggest reasons why we've never seen widespread adoption of signatures and encryption in email. I'll ignore nefarious reasons like authors of MUAs-for-the-masses in deliberate collusion to make it difficult for the non-Snowdens of the world.
In any case, I've always heard that gpg deliberately does not expose a programmable API that e.g. could be wrapped by Python. They only provide a command line API because they think that's the best way to avoid incorrect use in language bindings. They're probably not wrong about that. In any case, tools like python-gnupg are essentially glorified subprocess wrappers around the gpg cli, because there's no other way to do it.
-Barry
Barry Warsaw writes:
On Aug 14, 2013, at 05:35 PM, Stephen J. Turnbull wrote:
[1] Has anybody else noticed that both gpg's UI and its documentation seem designed to make it as hard to use as possible?
Sadly, I think this is one of the biggest reasons why we've never seen widespread adoption of signatures and encryption in email.
Sure, but the wrappers I've seen don't really help. I get the feeling that they are basically designed around smebody's personal needs with all kinds of bags and kludges added on request.
Maybe you can sprinkle RDM with itch powder the next time you see him? I bet he could do for a gpg wrapper what he's done for the email package! }:-}
On 13-08-14 2:35 AM, Stephen J. Turnbull wrote:
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? Not only have people noticed, but " Why Johnny Can't Encrypt: A Usability Evaluation of PGP 5.0" is often required reading for computer security students at Carleton because it serves as a great example of how poor usability can render carefully designed encryption and security completely worthless.
" The analysis found a number of user interface design flaws that may contribute to security failures, and the user test demonstrated that when our test participants were given 90 minutes in which to sign and encrypt a message using PGP 5.0, the majority of them were unable to do so successfully. "
If you haven't read it, I highly recommend it. It's an easy read, freely available online, and very educational. Obviously this is especially of interest to those talking about PGP and mailman, but it's a good read for anyone who works with code:
https://www.usenix.org/legacy/events/sec99/whitten.html
Terri
On 08/14/2013 04:35 AM, Stephen J. Turnbull wrote:
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)
hmm, always_trust=True is probably problematic -- if someone manages to inject another key with the associated User ID earlier into gpg's keyring, then their key will be used before the correct key.
I agree that gpg should be able to figure out the key to use given the e-mail address, but i'm not sure if it necessarily will if there are two keys which both claim a given User ID and only one has a valid binding (i.e. a proper OpenPGP certification from a trusted introducer).
so the above test worked, given the keyring that you had, but it might result in *not* working (e.g. by encrypting to the wrong key) given a different keyring.
fortunately, in the current implementation we're only worrying about signing, not encryption; so the relevant issue is the choice of secret key, and we don't expect other users to be able to inject data into the secret keyring, so this shouldn't be a concern. right?
--dkgDaniel Kahn Gillmor writes:
On 08/14/2013 04:35 AM, Stephen J. Turnbull wrote:
Python 2.7.5 (default, Aug 1 2013, 23:58:20)
from gnupg import GPG gpg = GPG(gnupghome='/Users/steve/.gnupg',keyring='test-pub',secret_keyring='test-sec') crypted = gpg.encrypt(u'A bit of random text.', u'stephen@xemacs.org', always_trust=True)
hmm, always_trust=True is probably problematic
Of course it is, but I was working with a test keyring.
-- if someone manages to inject another key with the associated User ID earlier into gpg's keyring, then their key will be used before the correct key.
This is an argument for validity checks on the keyring. The alternative is keeping the email-to-fingerprint mapping in the User database, which is *not* designed for crypto validation. I see no reason to suppose it's easier to attack the keyring that the User database.
fortunately, in the current implementation we're only worrying about signing, not encryption; so the relevant issue is the choice of secret key, and we don't expect other users to be able to inject data into the secret keyring, so this shouldn't be a concern. right?
I don't think it's a major concern, period. True, encryption uses the public key, which may be downloaded from a keyserver or entered from the web, making injection attacks plausible. So what? What's the alternative given that the raison d'etre of Mailman is to give users control over their profiles?
Note that I don't deny that there are real security issues here, and that in some contexts they are important. But if they are, I have to wonder if Mailman isn't much too complicated to be trusted anyway.
Steve
participants (6)
-
Abhilash Raj -
Barry Warsaw -
Daniel Kahn Gillmor -
Richard Wackerbarth -
Stephen J. Turnbull -
Terri Oda