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 AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
