ffff ff firma - ffff encrypted mailing list manager ff - a firma cai mas nao quebra ff The concept ----------- In portuguese, "firma" means for signature, signature and trust checking and is a slang for strenght and enteprise. All this together just can be one thing: an encrypted mailing list manager :P In the streets, the expression "a firma cai mas nao quebra" (the enterprise falls but does not breaks) is commonly used to talk about the strenght of a group that operates in secrecy. To our list manager, this concept says that your encrypted mailing list can stops to work -- if the server goes offline or abducted by aliens -- but the system can never be broken. With firma, we are trying to follow this philosophy. Firma is based on the gpgmailalias.pl perl script, hosted at http://www.rediris.es/app/pgplist/index.en.html, but completely rewritten in bash. Firma works as a command line and MTA pipe alias tool that receives a email message in its input, grab the encrypted and signed message and re-encrypt and send it to each subscriber. In the server you just need the script, a keyring with the list keypair and a config file. When mail arrives, it is redirected by the MTA to the script and it process the message if its properly encrypted and signed. No temporary files are written during a message processing and no default message archive, so no messages -- encrypted or not -- rest on your system in all steps of the process. Everyone has the private key X The server has the private key ------------------------------------------------------------- When using a encrypted mailing list software, one must choose between keeping the private key in the server or send it to each of the subscribers. We'll not consider the case where every subscribers encrypt the message to all recipients cause this has none automation in the process we are looking for. For the second option we have the NAH6 Mailman patch, http://mail.python.org/pipermail/mailman-coders/2003-June/000506.html For the first we have GPG Mailman, http://medien.informatik.uni-ulm.de/~stefan/gpg-mailman.xhtml This is a question of centralized versus descentralized vulnerability. - descentralized means just an alias for incoming encrypted email - if some user has its keypair compromissed, the list admin just need to remove the correspondent pubkey from the list's keyring Why Bash -------- You may ask why we choosed bash. Its really strange a crypto project using shell scripting language. But bash has many advantages: - Bash is found in almost all unix-like systems - Small dependencies: firma needs just tools like sed, awk, grep, cut and gpg itself. Look at the file "GUIDELINES" to see a complete list of all unix commands needed to run firma. - You can easily put all the tools, scripts and config files in a read-only media to protect againt cracks such as rootkits. - Keeping your encripted list manager out from a huge and sometimes bugged mail software prevents insecure use of your mailing list by an excess of unwanted functions and routines. - Firma has a total KISS design, and bash helps to keep it simple. Setup ----- Firma installation is quite simple: 1 - create a folder to store lists; by default firma use /usr/local/etc/lists but you can use anything, just edit firma and change FIRMA_LIST_PATH variable. 2 - copy firma script to whatever you like, eg. /usr/local/bin and check that it has no write permission 3 - then create your lists with the command firma -c your-list this will ask some questions and create a gpg keyring and a config file with the following variables: MAIL= path for sendmail or any smtp wrapper (eg, /usr/lib/sendmail) MAIL_ARGS= command line arguments to the smtp wrapper GPG= path for gnupg binary (eg, /usr/bin/gpg) LISTNAME= list email (eg, firma@domain.tld) LISTADMIN= list administrator email addresses (space separated) GPGDIR= gpg dir for the lists' keyring PASSWD= passwd for the lists' keyring then a gpg keypair and a config file are created. the owner of the config file and keyring should be nobody.nobody (or the user your MTA run as) and its permissions must be 600. 4 - create an alias to the list at your MTA; on sendmail or postfix, add this to your aliases file: your-list: "| /usr/local/bin/firma -p your-list" your-list-request: "| /usr/local/bin/firma -r your-list" and then run the command newaliases 5 - to subscribe the users and the list admins on the list, use ... 6 - send encrypted AND signed messages to your-list@yourmachine and look what happens :) Tips ---- - Use an encrypted swap memory - Use a read-only media to store firma and its needed apps - Use ramdisk to FIRMA_LIST_PATH so all keys and passwords vanishes if the server frozes - Use a big PASSWD, 25+ chars with alpha-numeric and special ascii keys Design and features ------------------- Firma is simple but its simplicity does'nt reflect in lack of design. - uses a gpg keyring to store both the keys and the subscribers options - command line is simple to avoid admin tasks resting in some .bash_history - non-pgp blocks in a message are discarded since we dont want to deal with unencrypted content - all unwanted email headers are striped as a privacy measure for who sends the message - firma does'nt use any disk write when processing a message; no temp files that may rest in the system; everything goes in memory (but take care, sometimes it will use the swap and then is best to make it encrypted) - by default it doesn't archive messages in the server - by default it remove the Subject header and put it inside the encrypted message, as Subject are outside the PGP/MIME context - messages appear to be sent To: Undisclosed Recipients Major features are: - keyring support - administration through email or command-line