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

Reply via email to