Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90260
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain paragonie.com from 209.85.215.54 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAEZPtU7-Lk=jGsTQgRZOvBpcPPgdX3V-23=3_k9CXbmxU77V1A@mail.gmail.com>
References: <CAKws9z1g24rD=t92+9xKtO=3PuwQ3_N=L36gmVMqCC84CoqipQ@mail.gmail.com>
	<CAEZPtU7-Lk=jGsTQgRZOvBpcPPgdX3V-23=3_k9CXbmxU77V1A@mail.gmail.com>
Date: Thu, 7 Jan 2016 11:11:06 -0500
Message-ID: <CAKws9z248Kj=0qTLPZik0Ki1_zGPq+4fr6HQi_keeVCso1S4eQ@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Libsodium
From: scott@paragonie.com (Scott Arciszewski)

On Thu, Jan 7, 2016 at 10:51 AM, Pierre Joye <pierre.php@gmail.com> wrote:
> HI Scott,
>
> On Thu, Jan 7, 2016 at 8:26 PM, Scott Arciszewski <scott@paragonie.com> wrote:
>> Hi everyone,
>>
>> I've updated the RFC to make libsodium a core PHP extension in 7.1, to
>> include references to the online documentation.
>>
>> https://wiki.php.net/rfc/libsodium
>>
>> All new functions and classes would exist in the Sodium namespace. e.g.
>>
>>     $ciphertext = \Sodium\crypto_box($message, $nonce, $keypair);
>
> As much as I like libsodium, yet another extension with yet another
> library in the core sounds like a risk to me, long term. I would
> rather prefer to focus on a larger effort to provide the necessary
> features in the most easiest way using new APIs or existing
> extensions, as you mentioned already in previous discussions and in
> this mail. That's why I won't be in favor of bundling this one.
>
>> This is part of an overall effort to improve PHP's cryptography; up
>> next will be the pluggable crypto API that supports multiple backends
>> (with a scope limited to openssl and libsodium at the time of release)
>> but always provide conservative defaults. Then I'd like to look at
>> deprecating ext/mcrypt back to PECL and add more hash functions to
>> ext/hash.
>
> This is definitely the way. Thanks for your great work :)
>
> Cheers,
> Pierre

Hi Pierre,

> As much as I like libsodium, yet another extension with yet another
> library in the core sounds like a risk to me, long term. I would
> rather prefer to focus on a larger effort to provide the necessary
> features in the most easiest way using new APIs or existing
> extensions, as you mentioned already in previous discussions and in
> this mail. That's why I won't be in favor of bundling this one.

Even if we axe mcrypt and in with a net-gain of 0 extensions, you'd
see it as a risk?

----------------

Let me state this clearly: I'm personally not going to bother pushing
for a pluggable crypto API if the only option is to use OpenSSL and
all its legacy cruft. I especially don't have lukewarm feelings
towards RSA or ECDSA, which are your only real options with it.

I feel that it simply would not be a worthwhile use of my time to do
so. If Internals decides "no libsodium" but "yes pluggable crypto
API", you'll have to find someone else to spearhead it.

And I've said everything that needs to be said about mcrypt when I
said, "Kill it with fire!" Now that we have random_bytes() there is
nothing redeemable about it.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>