Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83904
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAPwsocGTbg-WBfLtfHK_dxnr4yOBkhadb7NFj-qV9aOQueaVJw@mail.gmail.com>
References: <D114A04E.5DE53%fsb@thefsb.org>
	<CAPwsocGTbg-WBfLtfHK_dxnr4yOBkhadb7NFj-qV9aOQueaVJw@mail.gmail.com>
Date: Thu, 26 Feb 2015 11:17:27 -0500
Message-ID: <CAAyV7nE9vdzd17QczTXVUNKKMvtfOWrr_Cm2xBxdA+UwV0YOvQ@mail.gmail.com>
To: Leigh <leight@gmail.com>
Cc: Tom Worster <fsb@thefsb.org>, php-internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] crypto_something
From: ircmaxell@gmail.com (Anthony Ferrara)

Leigh and all,

On Thu, Feb 26, 2015 at 11:12 AM, Leigh <leight@gmail.com> wrote:
> On 26 February 2015 at 15:37, Tom Worster <fsb@thefsb.org> wrote:
>> On 2/26/15, 3:48 AM, "Stanislav Malyshev" <smalyshev@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.

One thing I'd like to make clear: I do not intend to target 7 with
this functionality (possibly 7.1 or later). I'd rather build a POC and
play with it for a bit. So while I do want to discuss it, I just
wanted to set expectations properly.

Anthony