Re: [RFC] OpenSSL AEAD support
| From: | Bishop Bettini | Date: | Wed, 06 Jan 2016 19:28:08 +0000 |
| Subject: | Re: [RFC] OpenSSL AEAD support | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-90219@lists.php.net to get a copy of this message | ||
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.