On Wed, Jan 6, 2016 at 11:09 AM, Jakub Zelenka <bu...@php.net> wrote:
> Hi, > > On Wed, Jan 6, 2016 at 3:35 PM, Bishop Bettini <bis...@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.
