Stop Proprietary Padding & Manipulation of AES Encrypted Files

Encryption is handled by the AES Encryption module. As far as I know, B&M does not manipulate padding or markers. Maybe the maintainer of the AES module can help answer this.

Huh, didn't realize that was in there. Haven't looked at that code in a while. To be honest I don't remember writing that and have no idea why it's there. I'll see if I can figure out how to remove it without breaking import for previously created backups.

Thanks
Ronan

I realized this was a major problem when my database went corrupt. There was no way to recover my data from the AES encrypted dumps, apart from installing a Drupal from scratch and installing Backup & Migrate and AES modules plus some click and point manipulation.

This is definitely not a good recovery strategy!

Any Linux distribution has AES encryption/decryption tools that would allow to do all this in less than a minute. What's more the 'aespipe' tool (Ubuntu) does not give any feedback on whether the password is right, it just gives something resembling a decrypted file whatever password you give it. This means that anyone using B&M + AES can spend half an hour (like I did) trying to figure out why on earth the "decrypted" files are not valid bzip2/gzip files, before landing on this bug report.

Please remove the lines :

98    $data = pack("a*H2", $data, "80");

and

117   $data = substr(rtrim($data, "\0"), 0, -1);

from includes/filters.encryption.inc

They make encrypted backups nearly unusable when you have a broken site, which defeats the purpose of having backups.

As for those who will have old AES backups, they should be given a simple php script that removes the padding, or maybe an option called something like "decrypt old encrypted files (legacy method)" on the bottom of the form.

It is urgent to stop corrupting encrypted backup files. That's why this bug should be considered as critical, IMO.

Sorry for the rant (data recovery situations are stressful) and keep up the good work: B&M is an amazing tool apart from this.

Vianney

The primary goal is that the backups be restorable with B&M. If I can play nice with other tools then that's a bonus. Therefore I am marking this as a feature request.

It would appear that the marker (which I must have taken from a comment on php.net: http://www.php.net/manual/zh/function.mcrypt-generic.php#68082) is because the php mcrypt function adds padding to the pre-encrypted data which would make the data unusable once decrypted unless I was reliably able to strip that padding.

I'm not sure I have enough knowledge of encryption to fix this ticket properly, and I certainly don't want to break anything. Do you know for sure that if I simply remove the marker then the files will be decryptable using aesutil or aespipe? I suspect that mcrypt_generic (which the AES module uses to encrypt the data) does not play nice with other tools (since it barely plays nice with itself). Can one of you confirm this by commenting out that line of code and testing the output with a 3rd party decryption tool?

If someone can give me another binary-safe way to deal with the PHP mcrypt padding that actually works with some tool other than PHP mcrypt_decrypt then I'll be happy to integrate it. Otherwise if you use encryption you will just have to use B&M for your restores.

I'm going to close this unless somebody has an idea of how to make it work.

We encountered a similar use case: decrypt the AES-encrypted backup files via terminal and not in Drupal Admin UI. We ended up creating a stand-alone, custom PHP script that could be run in terminal. Our custom script successfully decrypted the files. See details here: http://dropbucket.org/node/9160.