Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86395
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAKws9z0MVb8zAwmyW7ShkOjQOpJLEO_pdA=TnDT47nHa0x+wYQ@mail.gmail.com>
References: <CAKws9z0MVb8zAwmyW7ShkOjQOpJLEO_pdA=TnDT47nHa0x+wYQ@mail.gmail.com>
Date: Tue, 26 May 2015 18:47:35 -0400
Message-ID: <CAAyV7nHK5E7TrAk5xzk8wRCvfjc=qpHOv_KHt7zga2bfEWmxfA@mail.gmail.com>
To: Scott Arciszewski <scott@paragonie.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] [PHP 7.1] libsodium
From: ircmaxell@gmail.com (Anthony Ferrara)

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