On 25.04.2013 21:10, Abhilash Raj wrote:
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 link[1]. 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
May I suggest that mailman doesn't create the list key by itself, but ask the list maintainer to upload a public/private key pair (if no crypto hardware is used, see below)? On a virtualized system, getting real randomness is tricky.
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.
I would distinguish the following two scenarios:
The list is not-so-high-sec that you can risk storing the secret key without a password (which is the equivalent to storing the passphrase in the database).
Your list has elevated security requirements. In this case, you can use gpg-agent to manage the secret key (and its passphrase). This would require the sysadmin to start the gpg-agent and enter the list's passphrase before firing up mailman (or mailman could queue incoming mails until the secret key becomes available). This would open you the option to have the mailing list's secret key on a hardware token (e.g. the CryptoStick http://shop.kernelconcepts.de/product_info.php?cPath=1_26&products_id=133).
Stefan.