PHP Unframework
PHP Unframework
PHP Unframework
Instead of requiring the mcrypt extension, a good idea to make the code more portable and useful to coders would be to provide support for phpseclib. This could be implemented as an optional init parameter: e.g. fCore::usePHPSecLib( string $phpseclib_include_path ); and only used thereafter.
The current reliance on mcrypt breaks Flourish on most free hosting plans, which denies its use to many.
Given that phpseclib uses mcrypt if it's available (for speed) why use phpseclib optionally? Why not include it with flourishlib and just use it all the time whenever doing encryption? It'll encrypt with or without mcrypt and do it at the fastest possible speed.
I won't be including phpseclib in Flourish due to licensing issues - I've done a lot of work to keep Flourish MIT, but phpseclib is LGPL.
I certainly can add support for phpseclib if mcrypt is not found. fCryptography would just check to see if mcrypt was available. If not, phpseclib would be checked for next. Flourish would just rely on it being available in the include_path, or that it would have already been manually included. This would prevent the need for adding a special method to fCore. This technique is possible since phpseclib is LPGL and not GPL.
Ideally I'd take some time and implement AES in fCrytography in pure PHP since most of the rest of phpseclib is not required, and since it would be simpler for end-developers, but unfortunately I doubt I'll have time for that in the near future.
Seems like it'd be easier to ask the phpseclib developer to fork phpseclib with the MIT license or re-license it with the MIT license or something.
Implementing cryptographic algorithms, yourself, is generally not recommended. To top it off, phpseclib, per its own documentation, has the fastest pure-PHP AES implementation around. You could try to write a faster implementation but would you succeed when no one else has?
Also, you wouldn't need to include all of phpseclib - including Crypt_AES and Crypt_Rijndael is sufficient.
Yes, it certainly would be a good idea to ask and see if the phpseclib developer would license the code as MIT.
Either way, with code related to security, I would definitely write unit tests to ensure that the code is correct. In the process I would also audit the code and check it against reference algorithms.
If you would find a pure PHP implementation of mcrypt useful, please open a ticket and that will make sure I end up getting to it.
Another way would be to include Movable Type's implementation:
http://www.movable-type.co.uk/scripts/aes-php.html
It is licensed under a simple CC-By, which allows you to relicense the work provided you retain the copyright notice.
This implementation is arguably slower than phpseclib's, and therefore checking for phpseclib before using it would be better.
According to benchmarks included within the phpseclib documentation phpseclib is more than 5x faster than the movable type implementation:
http://phpseclib.sourceforge.net/documentation/sym_crypt.html#sym_crypt_aes_benchmarks
I'd still go with asking the phpseclib to re-license. You'd be surprised at how many open source developers I've come across who simply have no understanding of how the license they're using works.