Thomas, I don't think I'm following completely. I'm not suggesting we eliminate salts or vectors. What I'm discussing does not impact the vector, which is the salt component of this, at all. Once the vector is set, that vector is used, unmodified, through the encrypt and decrypt processes. This however, is not true for the key. Once you set the key string, the value that you set is NOT used to actually perform the encryption. A portion of the hash of this string is used instead. This means you cannot actually control what the key for your encrypted data is. This is, quite obviously, a very big problem.
The process of hashing the key does not actually provide any additional security. There is no difference in performing encryption using a plain text key and performing encryption using the hashed value of a plain text key. In both cases the data coming out will be as secure as the key is. In both cases you need the key in order to encrypt or decrypt the data. In both cases you cannot recover the key from the encrypted data. The only difference is that any other system accessing the encrypted data must be coded to use the same hashing logic or must be told to use the hash of the encryption key. In other words, the process of hashing the key instead of using the key itself does not provide any additional security but does severely hamper or in some cases eliminate, the process of interoperability with other systems. For example, we have an existing database containing encrypted data. That data was encrypted using AES-256 by a legacy system. That system has an existing key and an existing vector. Using these values we can decrypt the data using Mcrypt (not Zend), native Java encryption, etc. We cannot use Zend_Filter_Encrypt_Mcrypt to decrypt the data because, even though we set the key used by the other systems, this key will not actually be used to decrypt the data. The only way to allow Zend_Filter_Encrypt_Mcrypt to interact with the data would be to decrypt all of the data and re-encrypt it using the MD5 hash of the current key. What it comes down to is that, by implementing a system of encoding the set key, Zend_Filter_Encrypt_Mcrypt limits itself to decrypting data that was encrypted using Zend_Filter_Encrypt_Mcrypt and no other system. My suggestion would be that, rather than limit the functionality of the class by forcing the encoding of the actual key, that the class either not modify the key or that the modification of the key be made optional, even if it be on by default. The encoding of the key is not providing any additional security, so unless I'm missing something, its primary function at the moment is controlling the size of the key. I will go ahead and open a bug report and I am happy to take a first shot at a patch, however I would strongly suggest that this not be treated as a minor issue as it has a significant impact on anyone attempting to use encryption outside of a Zend Framework application. Regardless of the actual code fix, at a bare minimum the documentation, both in file and in the handbook, needs to be updated to explain that the key that you set is not actually the key that is used for the encryption or decryption of data. Thanks, James On Wed, Apr 22, 2009 at 3:15 PM, Thomas Weidner <[email protected]> wrote: > So you propose not to use SALT but to lower the security for the encryption. > My opinion is that default behaviour should provide as much security as > possible. > > You should add a issue to jira as feature request for having lowered > security integrated. > I would see this as feature increasement even if this is a feature > lower-ment. > > Greetings > Thomas Weidner, I18N Team Leader, Zend Framework > http://www.thomasweidner.com > > ----- Original Message ----- From: "James Stuart" <[email protected]> > To: "Thomas Weidner" <[email protected]> > Cc: <[email protected]> > Sent: Wednesday, April 22, 2009 8:34 PM > Subject: Re: [fw-general] Zend_Filter_Encrypt_Mcrypt Key Modified Before > Encryption/Decryption > > > Tom, > > Sorry, I wasn't clear in my first e-mail. We're setting both a vector > and a key. However, when the encrypt or decrypt routine is run, the > key itself is modified while the vector is left unchanged. > > For example, given the following values: > > Key: 1234567890ABCDEFGHIJKLMNOPQRSTUV > (32 byte, 256 bit) > IV: 1234567890ABCDEF > (16 byte, 128 bit) > Algorithm: MCRYPT_RIJNDAEL_128 > Mode: MCRYPT_MODE_CBC > > PHP Mcrypt: > $module = mcrypt_module_open(MCRYPT_RIJNDAEL_128, '', MCRYPT_MODE_CBC, ''); > mcrypt_generic_init($module, '1234567890ABCDEFGHIJKLMNOPQRSTUV', > '1234567890ABCDEF'); > $encrypted = mcrypt_generic($module, 'test_string'); > $encoded = base64_encode($encrypted); > ---- > $encoded = gFHQANviiEyF2LEy24Ws+w== > > Zend_Filter_Encrypt: > $encrypt = new Zend_Filter_Encrypt( > array( > 'adapter'=>'mcrypt', > 'algorithm'=>MCRYPT_RIJNDAEL_128, > 'mode'=>MCRYPT_MODE_CBC, > 'key'=>'1234567890ABCDEFGHIJKLMNOPQRSTUV', > 'vector'=>'1234567890ABCDEF' > ) > ); > $encrypted = $encrypt->filter('test_string'); > $encoded = base64_encode($encrypted); > ----- > $encoded = mkN6BBnQWHnwiPjnKe6zGg== > > The difference there is the result of a difference in key. Even though > I am passing the same key to both function, Zend_Filter_Encrypt_Mcrypt > is modifying it. The key that is actually used to perform the > encryption is '09c87b51e8bfad618e7bb82c538ac525' and not > '1234567890ABCDEFGHIJKLMNOPQRSTUV'. > > If I have an existing set of encrypted data using the key > 1234567890ABCDEFGHIJKLMNOPQRSTUV, I would have to re-encrypt it using > 09c87b51e8bfad618e7bb82c538ac525 in order for Zend_Filter_Decrypt to > work on it, using the same key. Obviously in real life keys would be > a little more complex than 1234...TUV but, the idea remains the same. > Zend_Filter_Encrypt_Mcrypt will only work with applications that run > substr(md5($key), 0, [key length]) logic on the given key before > performing encryption. > > Does that make any more sense? > > Thanks, > James > > On Wed, Apr 22, 2009 at 2:07 PM, Thomas Weidner <[email protected]> > wrote: >> >> James, >> >> You may be mistaken by the used notations. >> >> For mcrypt you don't need just a key for decryption. >> You also need the vector from the encryption to get the content decrypted. >> Take a look at the manual for details. >> >> The point is, that the key is used as base for creating the >> encryption-vector. >> And only to have the key is not enough for decryption. >> >> So to answer your questions in detail: >> 1.) No, Yes >> 2.) No >> 3.) No (you should set vector and key when you have them... the key alone >> >> Greetings >> Thomas Weidner, I18N Team Leader, Zend Framework >> http://www.thomasweidner.com >> >> ----- Original Message ----- From: "James Stuart" <[email protected]> >> To: <[email protected]> >> Sent: Wednesday, April 22, 2009 7:41 PM >> Subject: [fw-general] Zend_Filter_Encrypt_Mcrypt Key Modified Before >> Encryption/Decryption >> >> >> Hi, >> >> I encountered an interesting problem with Zend_Filter_Encrypt_Mcrypt. >> We are hoping to use it to interact with a database that contains >> encrypted information. We set everything up, plugged our keys in, >> fired up the app... and nothing decrypted properly. After a little >> big of digging, we found the issue: three lines of code in the >> encrypt() and decrypt() methods of the Mcrypt adapter. >> >> srand(); >> $keysize = mcrypt_enc_get_key_size($cipher); >> $key = substr(md5($this->_encryption['key']), 0, $keysize); >> >> This code appears to be in place to ensure that the key is the correct >> size. In doing so, it completely changes the actual value of the key. >> By modifying the key itself the code, for all intensive purposes, >> eliminates the possibility of Zend_Filter_Encrypt_Mcrypt being able to >> interact with any other, non Zend Framework (or even non >> Zend_Filter_Encrypt_Mcrypt) systems. >> >> In order for these filters to be useful to us, we need to be able to >> set the exact key that will be used for encryption. Before we work >> around the issue here I have a couple of questions for this list: >> >> 1.) Am I correct in interpreting that the code above is simply a way >> of ensuring that the key is the correct size? Is it being used for >> any other purpose? >> 2.) Does anyone else see this as a potential issue for them? >> 3.) Would it be worth us modifying Zend_Filter_Encrypt_Mcrypt to >> ensure there is a way around the modification of keys? (If not, we >> may just fork a copy of the class for our own purposes.) >> >> Thanks, >> James >> > >
