On 2/26/15, 3:48 AM, "Stanislav Malyshev" <smalys...@gmail.com> wrote:
>The custom is that the first word names the function group (yes, I know >old functions do not follow it, but this is new one). Unless we're going >to introduce a group of functions called secure_*, random_* is a natural >choice. This reminds me of the other problem. There is no one crypto lib that is in good shape or really covers what's needed. The Cryptography lib for Python has the right idea with it's backend interfaces: http://is.gd/kUztPc There's a lot else I like about that lib, like putting all the primitives under a member named "hazmat". The problems with mcrypt have been discussed. The limitations of OpenSSL became apparent when I researched what a shim on OpenSSL could manage: http://is.gd/jHtafh tl;dr The coverage is so poor I wouldn't bother trying. If you're using AES/CBC you're OK and it's not worth messing around with a shim. I'm not sure there's anything else OpenSSL supports that I want anything to do with. Besides, people are understandably scared of OpenSSL. libgcrypt does at least have a maintainer but it's poor Werner Koch who is so destitute he lives on charity raised on Kickstarter and has his work cut out just trying to deal with GPG: http://is.gd/cbHCYO Botan has a nice array of features and is well documented but is otherwise a mystery to me. Python Cryptography uses also Apple's CommonCrypto but it doesn't add very much, is limited to OS X and comes with Apple's open source license. I thought I'd share what I learned while working on it. And, fwiw, Yii excises Mcrypt in 2.0.3. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php