> **Update (6 February 2015):** > It seems like the class in question has actually updated as a response to the answers here (through an issue, now closed, raised on github).
I was looking for an easy to use library for encrypting files in PHP. PHP provides encryption functionality through the [mcrypt library](http://php.net/manual/en/book.mcrypt.php). Yet, there is a lot of configuration options and choices, enough of them to make a lot of mistakes.
So, instead of making those mistakes ourself, I searched for a drop in class (open source license, no framework constraints) which has already figured out how to apply the functionality securely. There is a lot of examples out there, but I cannot seem to find any code which has been reviewed by anyone with any background knowledge on this.
The best candidate I have found so far is on github: Pixelfck/SymmetricEncryption
The code seems pretty well written, the class is quite compact and well commented, so that is at least a good sign. Yet I don't think ourselves qualified to judge the security part of it.
Could anyone with more background on this read through the code and see if there are any issues?
I've quite some questions I hope to see answered (don't hesitate to pick the code apart even more):
First: the class includes two 'userland-implementations' of cryptographic functions:
Are those two implementations actually correct?
Second: some 'odd' things I spotted:
- The HKDF 'extract' step has been replaced by the use of PBKDF2, is this an accepted idea for the intended use?
- The number of rounds used for PBKDF2 is added (unencrypted) to the output of the encrypted data and used without/before being authentication by the hmac. isn't this a risk?
- PBKDF2 is limited to a single 'block' only, isn't this contrary to how PBKDF2 is intended to function?
Third: some 'minor' questions:
- Is 2^12 (= 4096) indeed an acceptable minimum number of rounds for PBKDF2 when used in this fashion?
- Is 128 bits of salt for PBKDF2 indeed enough 'with safety margin to spare'?
- The hmac key is 256 bits long, is this enough in this case?
Maybe I'm just worrying too much about this, but I would rather not use a third-party library that is flawed.