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? Thanks for the feedback! Jakub
