On Wed, Jan 6, 2016 at 2:59 PM, Jakub Zelenka <bu...@php.net> wrote: > On Wed, Jan 6, 2016 at 7:28 PM, Bishop Bettini <bis...@php.net> wrote: > >> 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. >> > > 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!
