+1 thanks Jakub! On Wed, Jan 6, 2016 at 6:09 PM, Jakub Zelenka <bu...@php.net> wrote:
> Hi, > > On Wed, Jan 6, 2016 at 3:35 PM, Bishop Bettini <bis...@php.net> wrote: > > > Hi Jakub, > > > > On Wed, Jan 6, 2016 at 10:01 AM, Jakub Zelenka <bu...@php.net> wrote: > >> > >> https://wiki.php.net/rfc/openssl_aead > > > > > > I think the API might need to be more generic so that any future cipher > > modes with different parameters could also be passed in. > > > > The reference model I'd suggest is the "context" parameter passed to > > stream related-functions. Userland creates a context, then passes the > > context to the encrypt/decrypt functions. The context is specific to the > > wrapper and drives specific behavior. Encrypt can add to the context any > > specific cipher state that needs to be passed along to decrypt. > > > > Using this model, the openssl API might look like: > > > > $context = openssl_context_create([ 'aead' => [ 'aad' => '...', > > 'tag_length' => '...' ]]); > > $ciphertext = openssl_encrypt( > > $data, $method, $password, $options, $iv, > > $context // here is the new parameter, encapsulating all cipher > > specifics > > ); > > > > echo $context['aead']['tag']; // populated by openssl_encrypt > > > > $plaintext = openssl_decrypt( > > $ciphertext, $method, $password, $options, $iv, > > $context // fully-reversible, because all necessary data are in > context > > ); > > > > > 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. > > I have got already an extension where you can do all of this context > related stuff ( see https://github.com/bukka/php-crypto ) but I don't > think > that anything like this should be part of the openssl ext. I think we > should concentrate on adding just the most important features with minimal > code addition to openssl ext and also concentrate on the fixing the actual > bugs. Bare in mind that all of this has to be maintained for very long time > and when you look to the regular contributors to openssl ext, you won't see > too many people... > > To sum it up this is a minimal proposal to add AEAD support to openssl ext. > Anything context related is out of scope of this RFC. > > Cheers > > Jakub >
