Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90883
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.49 as permitted sender)
MIME-Version: 1.0
Sender: jakub.php@gmail.com
In-Reply-To: <CADyq6sKcmXSm9ouGS-K_+0hNm=vnUq4Fa_BpW=OHYZ1+b4V4uA@mail.gmail.com>
References: <CAEKnhAHJW_v-yHx8ZJwu8O63Yfwc+9+bJnRoJwH7qXdzWE8T=w@mail.gmail.com>
	<CADyq6sKcmXSm9ouGS-K_+0hNm=vnUq4Fa_BpW=OHYZ1+b4V4uA@mail.gmail.com>
Date: Sun, 24 Jan 2016 12:08:00 +0000
Message-ID: <CAEKnhAFeMj0RgpjjZgOxzBwFRj0z6NbYPJL6WfR0EuT0daXCwA@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11439d40c3367d052a134dec
Subject: Re: [PHP-DEV] [RFC][VOTE] OpenSSL AEAD support
From: bukka@php.net (Jakub Zelenka)

--001a11439d40c3367d052a134dec
Content-Type: text/plain; charset=UTF-8

Hi,

On 23 Jan 2016 21:01, "Marco Pivetta" <ocramius@gmail.com> wrote:
>
> Just FYI, I'm voting against this proposal, as the number of parameters
is simply growing out of control, which involves:
>  - more BC breaks if default parameters change

What bc breaks? There are no defaults except tag length and that will never
change for the curent cipher algs.

>  - more security issues if the defaults are unsafe (or become unsafe, for
whatever reason)

The tag length default can be dependent on a cipher algorithm of course.
That would address all concerns because the current value (16) is effective
maximum for the currently supported AEAD cipher algs and it cannot change.
Another solution could be to have no default but that would make it much
harder for users to use as it would require an understanding what the max
and min is for the selected cipher algs.

In any case I'm not sure how it is related to the growing number of
function parameters...

>  - more cognitive load (it's arguably more complex)
>
> In general, this simply pushes too many responsibilities on the interface.
> Support for AEAD can be moved to a separate function, which involves a
minor BC break: collision with pre-existing functions, if anybody was
crazy/stupid enough to implement crypto in userland, and even worse in the
global namespace.

I'm not sure what your idea about AEAD function is but if you mean an
adding of a new function with the proposed signature, then you would still
have the same number of arguments and the same defaults. It would just be a
new function that would work only for selected cipher algs. It wouldn't
address any of your concerns and would just duplicate things.

If you mean some fancy context related set of functions, then it would
require some special handling and much more work. It would add to the
maintenance effort as well. As I said before I have a crypto pecl extension
that does exactly that. Personaly I think that such decision would probably
mean that we won't have AEAD support in openssl ext for quite a long time
as it won't be done anytime soon.

That being said I know that the current proposal is not the nicest but I
think it fits to the current openssl ext API which is not the nicest
either. I think that the main thing is that it adds the AEAD support and
the users could finally use it with just openssl ext.

Cheers

Jakub

--001a11439d40c3367d052a134dec--