Re: [Bacula-users] Possibility of parallelising encryption?

Richard Scobie wrote:
> I have a 2.8GHz Core i7 machine backing up uncompressable data spooled 
> onto an 8 drive RAID5, to LTO-4 tape.
> 
> Our requirements now dictate that data encryption must be used on the 
> tapes and having configured this, it seems that one core is saturated 
> encrypting the data and the result is that tape write speed is now about 
> 50% slower than when encryption is not used.
> 
> Would it be possible to optimise this task by perhaps reading data in 
> "chunks", which in turn can be encrypted by a core each, before being 
> recombined and written out to tape?

Sorry to reply-to-self, but after a bit more reading it seems that the
algorithm/cypher used by Bacula, aes-256-cbc, can't really be parallel
encrypted on multiple cores because encrypting one block affects the way
the next block is encrypted.

aes-ctr mode was developed to address that issue. It doesn't seem to be
hugely widely adopted yet, but is used in IPSec, appears in revisions to
the TLS standard, etc.

OpenSSL supports AES CTR mode at least for 128-bit, but only
single-threaded.

The implementation of multi-threaded aes-ctr encryption for OpenSSH I
referenced earlier was also presented to the OpenSSL folks:

  http://marc.info/?l=openssl-dev&m=120180007117054&w=2

but I can't find any response or follow-up to it.

So I guess the short answer is "parallel encryption is way harder to do
than it looks".

--
Craig Ringer

------------------------------------------------------------------------------
Download Intel&#174; 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