Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81591
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAH8MpnmumQFq8=JHQhq-uGe+dPW+jQDfR7O93xk1v=800ekRvw@mail.gmail.com>
References: <CAH8MpnktGy27BGFyH9i+tdfuMbti8KzHEXp=KD5LWy0vnKtxMw@mail.gmail.com>
	<CAPwsocELvXd+f2f_7-CeDB-=dQkM43yxZ5y3je8R9Tk8-0OYPw@mail.gmail.com>
	<CAH8MpnmumQFq8=JHQhq-uGe+dPW+jQDfR7O93xk1v=800ekRvw@mail.gmail.com>
Date: Mon, 2 Feb 2015 15:44:05 +0000
Message-ID: <CAPwsocEo_z=wbBcnuVFN9-oJQ2kMgeGK0FRJQrTiNLCcozTgKg@mail.gmail.com>
To: Daniel Lowrey <rdlowrey@php.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>, Jakub Zelenka <bukka@php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Re: OpenSSL ext. improvements for authenticated cipher modes.
From: leight@gmail.com (Leigh)

On 2 February 2015 at 14:30, Daniel Lowrey <rdlowrey@php.net> wrote:
>> The extra params aren't really _that_ bad.
>
> Okay, I'd like to reset the conversation a bit here. It's clear that the
> current API does not fit the problem domain very well. Tacking on more
> parameters only creates a bigger mess. Six parameters to a stateless
> function call is a completely incoherent API. It's unusable without
> consulting the manual. I think we need a completely different approach. Let
> me propose something else that won't break BC in any release and results in
> an API that's actually sane:
>
> class CryptoContext {
>     private $mode;
>     private $password;
>     function __construct($mode, $password) {
>         $this->mode = $mode;
>         $this->password = $password;
>     }
>     function encrypt($data) {
>         // ...
>         return $encryptedData;
>     }
>     function decrypt($data) {
>         // ...
>         return $decryptedData;
>     }
>     function setOption($option, $value) {
>         // ...
>     }
>     // more methods here to do anything you need
> }
>
> Thoughts on a stateful object API here? Personally I find this much more
> coherent than anything that's been proposed so far and it could be
> implemented without affecting existing functionality.

I'd really love to move to a context based crypto API.

I'd go one further and say I'd really love to see an extensible crypto
API, where extensions could provide ciphers or modes not available in
core.

That works for me going forward, but I'd still like a solution that
can go into 5.x