Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98049
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain paragonie.com designates 74.125.82.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEKnhAFrgh30fj8Hjm-OEOKkdyPkGbYfeSbxci4a9+5sja-c_Q@mail.gmail.com>
References: <CAKws9z2x1wz_WA9_XWOjbf-M9m917DN=zWzhXw3JNqdewyL_9g@mail.gmail.com>
 <CAEKnhAFrgh30fj8Hjm-OEOKkdyPkGbYfeSbxci4a9+5sja-c_Q@mail.gmail.com>
Date: Mon, 30 Jan 2017 14:40:18 -0500
Message-ID: <CAKws9z2WmHs-gpae8pxdZKM5BMFbte_tvh83Jv5MOVuyY0+Lvg@mail.gmail.com>
To: Jakub Zelenka <bukka@php.net>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113e4aac41b90b054754fc2c
Subject: Re: [PHP-DEV] [RFC] libsodium (PHP 7.2)
From: scott@paragonie.com (Scott Arciszewski)

--001a113e4aac41b90b054754fc2c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, Jan 29, 2017 at 2:04 PM, Jakub Zelenka <bukka@php.net> wrote:

> Hi,
>
> On Wed, Jan 11, 2017 at 6:22 PM, Scott Arciszewski <scott@paragonie.com>
> wrote:
>
>> Hi all,
>>
>> I'm resurrecting my RFC to add libsodium as a core extension to PHP 7.2.
>>
>>
> I'm still not sure why it needs to be in the core. As I said before, ther=
e
> are lots of healthy extension that are not in the core and it certainly
> doesn't make them less used (e.g. redis, xdebug or mongo driver). At the
> end it's all about packaging...
>
> I think libsodium has lots of really good features and it's a very nice
> lib. However what makes me a bit uneasy about libsodium is that it's
> basically a one dev library which is even clearly visible in here:
>
> https://github.com/jedisct1/libsodium/graphs/contributors
>
> It is certainly a bit more risky to support such lib if it all depends on
> on one person rather than a team of developers. I'm not saying that it's
> the same but mcrypt used to be also just one developer lib...
>
> Cheers
>
> Jakub
>

=E2=80=8BI erroneously replied off-list, and rather than forward messages t=
hat were
sent directly to me (on the offchance that they were not intended to be
public), I'll just reiterate what I said privately. From my original email:

> =E2=80=8BWas mcrypt in core?
>
> Is openssl still in core?=E2=80=8B
>
> If the answer to both these questions is "Yes", then it follows that
libsodium should be in the core. Especially if everyone agrees that it
should be included by default.
>
> > =E2=80=8B=E2=80=8BHowever what makes me a bit uneasy about libsodium is=
 that it's
basically a one dev library which is even clearly visible in here:=E2=80=8B
>
> You're looking at it all wrong. Look here instead:
https://github.com/jedisct1/libsodium/blob/master/AUTHORS
>
> The person who checked the code into Github may have been Frank Denis for
a lot of cases, but the code itself was written by cryptographers.
>
> Calling it "basically a one dev library" sounds simultaneously dismissive
and misinformed.=E2=80=8B (Also: There have been 58 contributors besides Fr=
ank,
which doesn't lead to your point at all.)
>
> Do you know any cryptography experts? Go ask them, "What would you rather
see devs use? OpenSSL or libsodium?" and report back what they say. To be
clear: I'm fairly confident that a large majority will not choose OpenSSL.=
=E2=80=8B
Furthermore, I'd like to raise an additional point.

PHP Archive signing currently has the following options:

- A hash function (forgery =3D trivial)
- OpenSSL signing (which I believe means RSA-PKCSv1.5 with SHA1; Daniel
Bleichenbacher had something to say about that in 2006, but e=3D65537 break=
s
the public exploit)

Putting libsodium in core allows us to add Ed25519 signatures to Phars,
which means that we can provide a reasonable level (128 bits is what I call
reasonable) of assurance that the PHP archive is authentic (assuming you
have a trustworthy public key).

Without putting libsodium in core, can we do that? If not, that's a solid
motivation to vote YES on this RFC.

Conversely, let's discuss a hypothetical: If this motion is abandoned, can
you (or, rather, everyone on this mailing list working together) guarantee
that 100% of operating systems will bundle libsodium and the PHP extension
in PECL with PHP 7.2 out-of-the-box, by default? That includes Windows,
FreeBSD, OpenBSD, Debian, Ubuntu, RedHat, CentOS, and even obscure
Unix-like academic projects. 100% coverage. Not 99%. Not 50%. Exactly 100%.

If we can't guarantee 100% adoption without putting libsodium in the core,
given the current political climate[1] and the history of unlawful
cryptography export restriction enforcement[2], I'd fear that OSes
(especially Enterprise Linux distributions that hold government contracts)
could be pressured against offering secure cryptography (i.e. libsodium) in
future versions of PHP. If we make it a core extension, it's included
unless you go out of the way to compile PHP without it. This means better
security by default.

Let's be clear: Libsodium one of the highest regarded libraries that
exposes very well-studied cryptography primitives (RFC 7748, RFC 8032, RFC
7693, etc.) with a misuse-resistant interface. It's also extremely
permissively licensed (ISC).

If Frank Denis were to get hit by a bus tomorrow, anyone could pick it up
and continue his work. I wouldn't advise blindly trusting anyone who forks
it, but the cryptography community would likely certainly come together and
suggest which fork is most trustworthy. If nothing else, you could count on
the cryptographers whose work is bundled in libsodium to recommend a fork.
The bus factor, while a legitimate concern, isn't going to be a source of
liability for libsodium nor for PHP.

[1]:
https://web.archive.org/web/20170127070926/https://www.cnet.com/news/trump-=
apple-boycott-terrorist-iphone-san-bernardino-fbi/
[2]: https://en.wikipedia.org/wiki/Bernstein_v._United_States

With respect,

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>
=E2=80=8B

--001a113e4aac41b90b054754fc2c--