Re: [RFC] OpenSSL AEAD support

From: 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.

« previous php.internals (#90219) next »