On 26 February 2015 at 15:37, Tom Worster <f...@thefsb.org> wrote: > 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 problems with mcrypt have been discussed. > The limitations of OpenSSL became apparent Agree 100%. I've spoken with Anthony and a couple of others about something in the same vein as the new csprng functions. I think core needs a pair of functions that handles the needs of the 99%. Those functions are. aes_encrypt(string $data, string $key): string aes_decrypt(string $data, string $key): string I have discussed this briefly with Anthony and Nikita, and we haven't reached a consensus on whether AES-n would be determined by key-length (adding complexity for the user), or whether $key should be $passphrase and should have key-stretching performed (this would avoid the case where people pass in hex for a key), in which case we would default to AES-128. The default mode would be CTR An IV would be taken from the csprng random functions, and would be prepended to the result. A strong MAC would be calculated and appended to the result. This doesn't leave any room for interoperability where things are done differently, but it also doesn't leave any room for people to mess it up. I think it's important that when it comes to crypto, we give people the ability to "just get it right", without having to know about why something is right or wrong. I welcome any thoughts on this. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
