Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81580
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAH8MpnktGy27BGFyH9i+tdfuMbti8KzHEXp=KD5LWy0vnKtxMw@mail.gmail.com>
References: <CAH8MpnktGy27BGFyH9i+tdfuMbti8KzHEXp=KD5LWy0vnKtxMw@mail.gmail.com>
Date: Mon, 2 Feb 2015 10:55:19 +0000
Message-ID: <CAPwsocELvXd+f2f_7-CeDB-=dQkM43yxZ5y3je8R9Tk8-0OYPw@mail.gmail.com>
To: Daniel Lowrey <rdlowrey@php.net>
Cc: "internals@lists.php.net" <internals@lists.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)

I should have stated my intent more clearly in the original mail. I
would be targeting 5.5 and above for a core change, and would provide
a an extension to back-fill 5.3 and 5.4. I think people should be able
to use authenticated modes of operation _now_, not when PHP 7 is
released and / or when it lands in a stable distro.

On 1 February 2015 at 17:49, Daniel Lowrey <rdlowrey@php.net> wrote:
> How about ...
>
> Old API:
> --------
> string openssl_decrypt ( string $data , string $method , string $password
> [, int $options = 0 [, string $iv = "" ]] )
> string openssl_encrypt ( string $data , string $method , string $password
> [, int $options = 0 [, string $iv = "" ]] )
>
> New:
> --------
> mixed openssl_decrypt ( string $data , string $method , string $password [,
> mixed $options = 0 [, string $iv = "" ]] )
> string openssl_encrypt ( string $data , string $method , string $password
> [, mixed $options = 0 [, string $iv = "" ]] )

Really not sure. On one hand it keeps the parameter count down and
opens the door for other options to be passed in future, on the other
the mixed return type bothers me a little.

> The main changes are:
>
>   - the $options parameter becomes mixed (either long or array) in both
> functions
>   - a long $options parameter triggers E_DEPRECATED in php7 (expects array)
>   - the presence of an $iv triggers E_DEPRECATED in php7 (scheduled for
> removal)

Is the intent to have the IV moved to the options array?

$options = [
    'flags' => OPENSSL_RAW_DATA,
    'tag' => ...,
    'taglen' => 16,
    'iv' => ...,
    'associated_data' => ...
];

>   - openssl_decrypt() now returns mixed ... if $options['get_tag'] == true
> then return [$decryptedString, $tag], otherwise return $decrypted string as
> before to preserve BC.
>   - the encrypt function could use $options['set_tag'] to define that (or
> any other secondary information needed for the operation).

The result of a mode like GCM is useless without the tag, it should
automatically be provided when you choose a mode that results in a
ciphertext and a tag, and likewise the mode should fail if you try and
decrypt without providing the tag.

> What I would prefer NOT to see is piling on more optional parameters to
> these already too-long function signatures. Also, I don't really like the
> idea of adding "state" to this operation with new
> openssl_set_tag/openssl_get_tag functions.

I agree about set/get. My least favourite option.

The extra params aren't really _that_ bad.

string openssl_encrypt ( string $data , string $method , string
$password [, int $options = 0 [, string $iv = "" [, string &$tag [,
string $associated_data ]]]] )

By the time you get to $associated_data, everything preceding it is a
required parameter. Yes it's verbose, but it still doesn't break BC,
and the options and return types remain the same (although this
forgoes the option to specify the tag length - another param would
just be silly ;)).