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? Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises <https://paragonie.com> On Tue, May 26, 2015 at 6:47 PM, Anthony Ferrara <ircmax...@gmail.com> wrote: > Scott, > > On Wed, May 20, 2015 at 9:15 PM, Scott Arciszewski <sc...@paragonie.com> > wrote: > > Hi Internals Team, > > > > I'm sure everyone is really focused (and excited) for PHP 7.0.0 later > this > > year, and many of you might not want to discuss what 7.1.x looks like > yet. > > > > The current state of cryptography in PHP is, well, abysmal. Our two main > > choices for handling symmetric cryptography are libmcrypt (collecting > dust > > since 2007) and openssl, which lacks a streaming API (e.g. > mcrypt_generic) > > and GCM support. > > > > While mcrypt is slowly decomposing in the corner and code is being > > desperately migrated towards openssl in case a critical vulnerability is > > discovered in the abandonware choice, the libsodium extension has been > > growing steadily. Thanks to Remi, it should soon be compatible with both > > PHP 5.x and 7.x (decided at compile-time). The libsodium library itself > has > > landed in Debian 8 and Ubuntu 15.04 and adoption is expected to persist > by > > the next Ubuntu LTS is released. > > > > I think now is a good time to talk about the possibility of making > > libsodium a core PHP extension, depending on where things are when we > near > > the 7.1 feature freeze. > > > > I've just opened an RFC for precisely this purpose: > > https://wiki.php.net/rfc/libsodium > > While I definitely do like libsodium and consider it a step in the > right direction, I am hesitant overall. The main reason is precisely > what happened with mcrypt. In that a library goes unmaintained, and > all of a sudden we're stuck using unsupported crypto. > > I wonder if a PDO-style approach would be better. Where we can have > multiple pluggable backends, and provide backend-specific > functionality if needed. Targetting a high-level API, not exposing > primitives. Something like: > > $enc = new SymmetricEncryption(":cipher=aes128;hash=sha256"); > // Use any available backend which can do aes128+sha256 mac > var_dump($enc->encrypt("plaintext", $key)); > > $enc = new SymmetricEncryption("openssl:cipher=arc4;mode=ctr"); > // Use any available backend which can do aes128+sha256 mac > var_dump($enc->encrypt("plaintext", $key)); > > > The concept would be that while parts of the algorithm are > controllable by the end-user (like cipher choice, possibly mode, etc), > we would attempt to prevent insecure usages (no ECB). > > If you have a need for custom encryption (web service uses a custom > format), then use primitives yourself (like openssl/mcrypt/etc). > > My one issue with libsodium is that if you need NIST compliance, it > does nothing for you (considering it uses XSalsa20+ Poly1305). While > this is an advantage for some, it's a disadvantage for many. > > Ideally, I'd like to see a prototype of this library built in PHP that > we can play with prior to making into a PECL extension (and ultimately > proposed for core). > > I'd just rather try to get this right, rather than yet another > maybe-good-enough-for-now solution. > > Anthony >
