Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83903
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <D114A04E.5DE53%fsb@thefsb.org>
References: <D114A04E.5DE53%fsb@thefsb.org>
Date: Thu, 26 Feb 2015 16:12:18 +0000
Message-ID: <CAPwsocGTbg-WBfLtfHK_dxnr4yOBkhadb7NFj-qV9aOQueaVJw@mail.gmail.com>
To: Tom Worster <fsb@thefsb.org>
Cc: php-internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] crypto_something
From: leight@gmail.com (Leigh)

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.