Hi,
I like Anthony's idea of a crypto framework (abstracting away whatever
underlying library is actually used). Not sure yet how this could be
implemented though.
For what it's worth, I started playing with libtomcrypt (yet another
crypto API) a few weeks ago as an attempt to replace the old mcrypt
extension for my own needs. I found it quite easy to work with, plus the
license is very permissive (WTFPL).
The result can be seen at https://github.com/fpoirotte/tomcrypt.
This is basically a thin wrapper around libtomcrypt's API.
The code still has many issues I need to resolve (lack of unit tests,
parameter parsing using improper types, not ready for PHP 7 yet, etc.)
but I found it to be pretty usable already.
Would there be any wider interest for such an extension?
Regards,
François
On 05/27/2015 01:44 AM, Rowan Collins wrote:
On 26/05/2015 23:52, Scott Arciszewski wrote:
That's fair, and one of the reasons I wanted to make ext/libsodium
part of
the core was so that segueing into a PDO-style cryptography API would be
more natural. Instead of "wrap openssl and maybe wrap libsodium if it's
already installed" it would be "wrap what the language already has".
Am I mistaken in believing this would be the way forward?
Well, it doesn't quite match how PDO works, as I understand it -
ext/pdo_pgsql isn't implemented on top of ext/pgsql, the two are
separate extensions built on top of the libPQ library which Postgres
provides. The "PHP Crypto Objects" equivalent would be "wrap openssl in
ext/pco_openssl, wrap libsodium in ext/pco_sodium".
The dependency management would be no different between ext/openssl and
ext/pco_openssl - PHP doesn't *provide* OpenSSL or mcrypt, it
*optionally* depends on them, and the same would be true of libsodium,
whatever the bindings looked like.
As such, bundling an extension which directly exposes libsodium's
functions isn't really a pre-requisite for a pluggable architecture, and
could harm the effort by being "too good" and allowing the short-term
"good enough" solution that Anthony is afraid of.
Regards,
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
