Re: [Bacula-users] PATCH: add AES-ECB support to Bacula
On 04/07/10 06:52, 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 > it is built into OpenSSL 0.9.8 . This trivial patch adds appropriate > entries in the public crypto.h enum for cyphers so that the AES ECB mode > may be requested by the fd, and translates this into OpenSSL cypher > settings in crypto.c . > > OpenSSL doesn't automatically do ECB encryption in parallel. However, > unlike the currently used CBC mode, it's possible to do. > > 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... Craig, you should really think about joining the -devel list. :) -- Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355 ala...@caerllewys.net ala...@metrocast.net p...@co.ordinate.org Renaissance Man, Unix ronin, Perl hacker, Free Stater It's not the years, it's the mileage. -- 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
Re: [Bacula-users] PATCH: add AES-ECB support to Bacula
On 7/04/2010 8:42 PM, Matija Nalis wrote: > 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. Yeah. I got confused at some point while digging into all this. Thanks for following up and explicitly pointing it out, as it needs to be on record with the original post. At some point I'd got ECB and CTR mode muddled. This is why I should probably stick to something not even remotely touching on security, or at least do it when I'm reasonably awake ;-) > 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. Yep. Not as bad as the recent "AES encrypted" USB flash disks that just used the user's password as a key to AES-128 encrypt/decrypt a session "key" that they merrily used to xor all the data written to / read from disk. Still inscure, though, due to known-plaintext attacks. > I know just enough crypto to know that without knowing way 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. You're quite right. -- Craig Ringer -- 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
Re: [Bacula-users] PATCH: add AES-ECB support to Bacula
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 way 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, 1 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
[Bacula-users] PATCH: add AES-ECB support to Bacula
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
it is built into OpenSSL 0.9.8 . This trivial patch adds appropriate
entries in the public crypto.h enum for cyphers so that the AES ECB mode
may be requested by the fd, and translates this into OpenSSL cypher
settings in crypto.c .
OpenSSL doesn't automatically do ECB encryption in parallel. However,
unlike the currently used CBC mode, it's possible to do.
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...
--
Craig Ringer
diff --git a/bacula/src/lib/crypto.c b/bacula/src/lib/crypto.c
index fb52c25..077b8d2 100644
--- a/bacula/src/lib/crypto.c
+++ b/bacula/src/lib/crypto.c
@@ -1022,6 +1022,11 @@ CRYPTO_SESSION *crypto_session_new (crypto_cipher_t cipher, alist *pubkeys)
cs->cryptoData->contentEncryptionAlgorithm = OBJ_nid2obj(NID_aes_128_cbc);
ec = EVP_aes_128_cbc();
break;
+ case CRYPTO_CIPHER_AES_128_ECB:
+ /* AES 128 bit ECB */
+ cs->cryptoData->contentEncryptionAlgorithm = OBJ_nid2obj(NID_aes_128_ecb);
+ ec = EVP_aes_128_ecb();
+ break;
#ifndef HAVE_OPENSSL_EXPORT_LIBRARY
case CRYPTO_CIPHER_AES_192_CBC:
/* AES 192 bit CBC */
@@ -1033,6 +1038,11 @@ CRYPTO_SESSION *crypto_session_new (crypto_cipher_t cipher, alist *pubkeys)
cs->cryptoData->contentEncryptionAlgorithm = OBJ_nid2obj(NID_aes_256_cbc);
ec = EVP_aes_256_cbc();
break;
+ case CRYPTO_CIPHER_AES_256_ECB:
+ /* AES 256 bit ECB */
+ cs->cryptoData->contentEncryptionAlgorithm = OBJ_nid2obj(NID_aes_256_ecb);
+ ec = EVP_aes_256_ecb();
+ break;
#endif
case CRYPTO_CIPHER_BLOWFISH_CBC:
/* Blowfish CBC */
diff --git a/bacula/src/lib/crypto.h b/bacula/src/lib/crypto.h
index cb935bd..dc3171f 100644
--- a/bacula/src/lib/crypto.h
+++ b/bacula/src/lib/crypto.h
@@ -82,7 +82,9 @@ typedef enum {
CRYPTO_CIPHER_AES_128_CBC,
CRYPTO_CIPHER_AES_192_CBC,
CRYPTO_CIPHER_AES_256_CBC,
- CRYPTO_CIPHER_BLOWFISH_CBC
+ CRYPTO_CIPHER_BLOWFISH_CBC,
+ CRYPTO_CIPHER_AES_128_ECB,
+ CRYPTO_CIPHER_AES_256_ECB
} crypto_cipher_t;
/* Crypto API Errors */
--
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
