Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90240
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.43 as permitted sender)
MIME-Version: 1.0
Reply-To: bishop@php.net
Sender: bishop.bettini@gmail.com
In-Reply-To: <CAEKnhAGU=OEA54xRzZ4djtCGaQsndxpT5zXBenRFYisH654abA@mail.gmail.com>
References: <CAEKnhAHGK0Uj-nGyGGXWXS1jE6P+nqLgLMJjje3pyT78hVUBLA@mail.gmail.com>
 <CAEYWF=7tMegJ9GDA8ZQBpybp6JNec65-hF+j1Z=X_UxY_i5Z7Q@mail.gmail.com>
 <CAEKnhAFFazCoVct5gMs9NGAUwWm6YEDY2+j2HDhr8k2U=QwMiA@mail.gmail.com>
 <CAEYWF=4R2_JdNwOOSXyL2C706FvdK7B39gTN+csfX=KKHAFA-Q@mail.gmail.com> <CAEKnhAGU=OEA54xRzZ4djtCGaQsndxpT5zXBenRFYisH654abA@mail.gmail.com>
Date: Wed, 6 Jan 2016 16:32:17 -0500
Message-ID: <CAEYWF=5xfr2+feMJYbnybDVxz-4ibhYXuGQdpk7dv5vGivPA-g@mail.gmail.com>
To: Jakub Zelenka <bukka@php.net>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11443f0a61cbc90528b118dc
Subject: Re: [PHP-DEV] [RFC] OpenSSL AEAD support
From: bishop@php.net (Bishop Bettini)

--001a11443f0a61cbc90528b118dc
Content-Type: text/plain; charset=UTF-8

On Wed, Jan 6, 2016 at 2:59 PM, Jakub Zelenka <bukka@php.net> wrote:

> On Wed, Jan 6, 2016 at 7:28 PM, Bishop Bettini <bishop@php.net> wrote:
>
>> On Wed, Jan 6, 2016 at 11:09 AM, Jakub Zelenka <bukka@php.net> wrote:
>>
>>> Hi,
>>>
>>> On Wed, Jan 6, 2016 at 3:35 PM, Bishop Bettini <bishop@php.net> wrote:
>>>
>>>>
>>>> I think the API might need to be more generic so that any future cipher
>>>> modes with different parameters could also be passed in.
>>>>
>>>> Please see note in
>>> https://wiki.php.net/rfc/openssl_aead#rejected_features . Any context
>>> related features will add a lot to the size of the implementation. In this
>>> case it would also mean introducing an object with dimension handler to the
>>> openssl ext which doesn't really match with the rest of the extension API.
>>> The proposed API is more conformant to the rest and the code addition is
>>> also limited which is very important from the maintenance point of view.
>>>
>>
>> Ok, a context resource may not be pragmatic. Perhaps a compromise in the
>> form of a thin wrapper:
>>
>> string openssl_encrypt_aead(string $data , string $method , string
>> $password [, int $options = 0 [, string $iv = "" [, string &$tag = "" [,
>> string $aad = "" [, int $tag_length = 16 ]]]])
>>
>> string openssl_decrypt_aead(string $data , string $method , string
>> $password [, int $options = 0 [, string $iv = "" [, string $tag = "" [,
>> string $aad = "" ]]]] )
>>
>> This actually feels more right anyway: openssl_encrypt only does
>> encryption, whereas openssl_encrypt_aead does encryption *and*
>> integrity.  I would hate for users to pass a method of aes128 and think
>> they can forgo an HMAC because they thought PHP would give them back a
>> valid tag.
>>
>
> This is a good point. I would probably go with a bit different and maybe
> simpler solution. How about emitting notice when $tag param is supplied for
> non aead mode?
>

I think the need for a message highlights an API design problem, and I'd
rather eliminate the need with a purpose-built API.

Still, AEAD is a valuable addition to the API.  Thanks for submitting the
RFC!

--001a11443f0a61cbc90528b118dc--