Steve Yates wrote: > > "This function encrypts data. The data is padded with "\0" to make sure > the length of the data is n * blocksize. This function returns the > encrypted data. Note that the length of the returned string can in fact be > longer then the input, due to the padding of the data." > > I am storing the encrypted, padded string.
I wasn't sure on the padding scheme that mcrypt uses, so if it is indeed zeroes, you're probably fine. That might not always be the case depending on the padding scheme used (such as not having a padding scheme at all), but since mcrypt obviously does, things should be fine. As to the garbage that's being appended, could it possibly be due to some thread-safety issues? libmcrypt is thread-safe, but I believe there's an additional configuration parameter needed for safety. (Not entirely sure on that. Are you using a threaded web server?) > However changing now will mean handling some historical data > differently > somehow. :( And storing an IV for each record would of course increase > the data size. > It wouldn't be that hard to convert. Just write a script that converts the old data to the new cipher mode and shove it back in the database. Storing the IVs would naturally increase the storage size by a few bytes per record, but the increased security might be worth it. J -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
