On Wed, Apr 07, 2010 at 06:52:40PM +0800, Craig Ringer wrote: > Bacula currently only uses the AES CBC cypher mode. This cypher can't be > effectively parallelized because block n+1 depends on block n. > > The AES ECB mode was developed to address that limitation. Support for
Actually, ECB was "developed" as it is one of the building blocks for CBC (and other schemes). It is not secure at all by itself. You may however use it to build other schemes which allow for (some/much) parallelisation and/or precomputing (like OFB, CTR etc), and which are way more secure then ECB itself (but still worse than CBC probably) > Right now, this patch gains you little or nothing. It also costs little > or nothing, and probably shouldn't actually be applied at present. I'm > putting it up here to keep it and the notes about crypto in the archives > in case I don't have any luck following it up with an actually parallel > implementation and others are looking into it later. > > The next step is to try to spawn worker threads to encrypt chunks in > parallel. Hopefully this will be possible with OpenSSL... I really think doing pure ECB is a veeery bad way to go, as it lulls the user in false sense of security without actually providing security. For examples, see nice pictures at http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Electronic_codebook_.28ECB.29 Sometimes you can even tell by the plain eye view of ECB-encrypted picture what the original picture was (See wikipedia)! Not to mention many various crypto attacks against its use in our contexts. What I would actually propose is filter support. Then a FD could pass a data stream via pipe to the standard external filter program (which reads from stdin and writes to stdout), and a user can put any third party utility there that s/he wants - from multi-core compression ones (like pbzip2) to encyption ones (like aespipe and ccyrpt and similar, or others that employ paralellisation or special hardware support), or a combination of those. Current encryption and compressions can be provided as separate applications included in default bacula distribution. What we might additionally need though, is some way to put some identifier as to which filter was used for which job, so one can retain compatibility with older backups if one decides to change the crypto/compression) I know just enough crypto to know that without knowing waaaaay much more I'm likely to make terrible mistakes (and we all still remember Debian "fixing" OpenSSL security fiasco, don't we?). Raw ECB sounds just like one of those mistakes. By using filters, we can have both maximum flexibility, and actually have the more secure encryption (by recommending the proven encryption tools to use instead of reinventing the wheel [probably badly]) -- Matija Nalis Odjel racunalno-informacijskih sustava i servisa Hrvatska akademska i istrazivacka mreza - CARNet Josipa Marohnica 5, 10000 Zagreb tel. +385 1 6661 616, fax. +385 1 6661 766 www.CARNet.hr ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
