Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86396
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain paragonie.com from 209.85.192.48 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAAyV7nHK5E7TrAk5xzk8wRCvfjc=qpHOv_KHt7zga2bfEWmxfA@mail.gmail.com>
References: <CAKws9z0MVb8zAwmyW7ShkOjQOpJLEO_pdA=TnDT47nHa0x+wYQ@mail.gmail.com>
	<CAAyV7nHK5E7TrAk5xzk8wRCvfjc=qpHOv_KHt7zga2bfEWmxfA@mail.gmail.com>
Date: Tue, 26 May 2015 18:52:04 -0400
Message-ID: <CAKws9z3wbdQ_G_Up5DkPDGaUSOcDZtkuFPDr0WQ5EHsrLRuXdw@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11475138b168d5051703f960
Subject: Re: [PHP-DEV] [RFC] [PHP 7.1] libsodium
From: scott@paragonie.com (Scott Arciszewski)

--001a11475138b168d5051703f960
Content-Type: text/plain; charset=UTF-8

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 <ircmaxell@gmail.com>
wrote:

> Scott,
>
> On Wed, May 20, 2015 at 9:15 PM, Scott Arciszewski <scott@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
>

--001a11475138b168d5051703f960--