PHP Encryption / Decryption Using the MCrypt Library (libmcrypt)

Andrew Johnson (ITNewb Guru) wrote 13 days ago

I also might consider using a different order: sql dump -> encrypt file -> gzip encrypted file. At that point, as long as the download is in binary and not ascii it should work (possibly even if base64 encode wasn't used). Then you would receive the gzip via upload, decompress it and finally decrypt it. This would seem like a more logical order to me.

Andrew Johnson (ITNewb Guru) wrote 13 days ago

The raw ciphertext can have any sequence of data in it including null values. It's possible they were being discarded during download. My statement about writing mode/eol is not an issue in your case.

Lesson of the day: use base64 encode if you plan on downloading encrypted files.

Andrew Johnson (ITNewb Guru) wrote 13 days ago

Glad to hear you sorted it out. Running it through base64 encode provides a nice representation of the raw binary ciphertext that can easily be passed around and stored. I'll wager to say you weren't writing the data to the file in binary mode and an EOL translation occurred.

ajenkins (Site Newb) wrote 13 days ago

Update #3:

Problem solved, but I'd like to have some insight into why this works. Everything works fine when I turn on base64 encoding. No need to change any lines in the script and files that have been saved to the server or downloaded and then uploaded all decrypt fine.

Thanks for your assistance and I'd love to understand why this is the case.....

ajenkins (Site Newb) wrote 13 days ago

Update #2:

Just as an aside, it is definitely the download process that is killing the ability to decrypt. I tried downloading a file and then simply moving it manually back to the server (not through an HTTP upload form) and it still died. At least we're narrowing down the problem.

ajenkins (Site Newb) wrote 13 days ago

Update:

changing the content-type: octet-stream didn't help. I even tried removing the content-length in the download header in case the file size was somehow getting very slightly altered but that didn't do anything either. All this happened while decryption of files that had never been downloaded still work.

ajenkins (Site Newb) wrote 13 days ago

@Andrew,

Thanks for the wicked fast reply. Here's how it goes:

User creates an encrypted file -> an sql dump is performed, that sql file is gzipped, and that gzipped file is encrypted using the following method:

                        $theFile = file_get_contents($filepath.$filename);
                        $fh = fopen($filepath.$filename,'w');
                            fwrite($fh,$encryption->encrypt($theFile,$key));
                        fclose($fh);

The file is then downloaded using Content-Type: application/force-download and transfer encoding as binary. I'm thinking the problem occurs here because if the exact same sequence is performed but the file isn't downloaded, then decryption works perfect with the class as is. The decryption is performed the exact same way as the encryption (as shown in the code above) except using the decrypt method, obviously. If I try to decrypt a file that was initially downloaded and subsequently uploaded to the server, then it fails at the line where the mac needs to be authenticated (boy did it take me a long time to find that out!).

Any insight you can provide is fantastic. Do you think the problem really lies in application/octet-stream vs application/force-download?

Everything else regarding the encryption method is exactly as it was posted in the cryptastic class function, including no base64 encoding (as shown by my use of the encrypt method above).

Thanks again! I'm going to give the application/octet-stream a shot while I'm waiting to hear back from you.

Andrew Johnson (ITNewb Guru) wrote 2 weeks ago

@ajenkins

If the MAC isn't authenticating that tells you some aspect of your message changed from point A to point B. You need to leave that line in there, it's important. If any part of the final package (iv+ciphertext+mac) is altered at any point after it leaves the encrypt method it will throw things off, and it's supposed to.

There are a number of possible culprits. Paint a clearer picture for me. Are you using the base64 encode option the class offers? What are you doing with the data returned from the encrypt method? How are you writing that data to a file? What PHP function(s) are you using to write to the file? Are you compressing into a zip, tar archive etc?

Off the top of my head, the HTTP Content-Type header needs to be application/octet-stream and the Content-Transfer-Encoding needs to be binary for the download to work properly -- assuming the file is prepared correctly.

ajenkins (Site Newb) wrote 2 weeks ago

Cool article. I'm using the class on a database system of mine which requires very high security. I've come across an issue though. I really understand very little of the class, even after your explanation of it. My problem is with the MAC. I create encrypted database backup files and store them on the server and allow users to download them. Users can then use these downloaded backup files to restore the database by uploading them, where they get unencrypted on the server using the decrypt method of this class.

The problem is, files that never leave the server can be unencrypted no problem, but when files that get downloaded and then uploaded back to the server, the mac can't be authenticated (the following line:)

 if ( $em !== $mac)) # authenticate mac
 return false;

If I remove this line, the uploaded files can be dencrypted perfectly, but then the files that have never been downloaded can't be decrypted.

Basically, what does downloading do to the file that removes or alters the MAC?

Andrew Johnson (ITNewb Guru) wrote 3 months ago

That does look useful, thanks for mentioning it! A guide that accomplishes the same thing the code in this article accomplishes but with phpseclib would certainly be a worthwhile contribution to the archive.

Thanks again, and welcome to ITNewb!

Hot Spots

Information

Powered By

Requirements

Copyright / Usage