On Thu, Apr 25, 2013 at 7:05 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net>wrote:
On 04/25/2013 04:36 PM, Stefan Schlott wrote:
On 25.04.2013 00:14, Abhilash Raj wrote:
- When a message is decrypted and then passed on between the queues, it creates a security threat for the cleartext message is being held in memory, even for a small time in between the runners.
The Mailman server holds the key to decrypt _every_ incoming message. So if the server is compromised, a message temporarily held in memory is the least of your problems :-)
abhilash might have meant that there is a concern that a decrypted message could be stored *on disk* in one of the queues, not just in memory. This could be a problem if an adversary gets access to the disk and can get access to the backing storage, even after the files have been unlinked from the filesystem (since unlinking files doesn't guarantee removal of all traces from the backing storage).
Of course, if the secret key for the list is kept without a passphrase on the same filesystem or on a separate filesystem on the same backing storage, then your risk is elevated to begin with.
Abhilash, i don't see any mention in your proposal of how you plan to deal with the secret key material. will there be a way for mailman to use a secret key that is stored in a password-protected form? If so, how?
Well I am not quite proficient in cryptography but I tried to answer how could it be done and have updated on the same link1. Here is a copy of only that part:
One of the biggest issues of any cryptographic procedure is to secure and manage the keys. Firstly for the lists, when the list is created by the owner the keypair is generated by mailman in some time(because when i was trying to create one using gnupg, it asked me to wait for sometime and keep doing some work to get threshold entropy. Although in reality I don't have much idea about how the keys are created, but I am guessing that it somewhere uses the random bits from the memory of the host where key is created and thus required a threshold entropy for the proper randomization of the key. On virtualised Linux systems, this can often be achieved by installing the rng-tools package.) and is stored in the database against the name of the list. It will then be available for download to the subscribers. [python-gnupg][2] also allows one to encrypt/decrypt using the keys that are protected by a paraphrase. Such paraphrase though would then be stored in cleartext format in database. Though this poses a security thread but even if you encrypt and store the paraphrase, you can only slow the process of decryption once the server is compromised since the private-paraphrase-encryption key will also be needed to be stored somewhere on the local disk.
The pub-keys added by the users will be stored in different table(having many to one relationship with users) and will be used whenever there is a need to encrypt or verify_signature.
--dkg
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/raj.abhilash1%40gm...
Security Policy: http://wiki.list.org/x/QIA9
-- Abhilash Raj