Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93805
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain paragonie.com designates 209.85.218.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <d083b26b-2fb2-42a9-eb3d-1c4d63db3bec@fleshgrinder.com>
References: <CAKws9z114YcHkDaXO3o-E0JuHR10WsPzyedeF_8Q=shHDziwug@mail.gmail.com>
	<f19972fa-353f-dc6c-6184-9f1c72ad2ce7@gmail.com>
	<CAEZPtU4aSoe3rDWWFssBx95pgqXe=TXT52bGi_85X+cYmqjH0A@mail.gmail.com>
	<CAKws9z0qrT2etrx5K3xFLOEPfeV0E7Z_F5nDDc-PmYqck8++Cg@mail.gmail.com>
	<8ebf9e48-62e5-fae5-d234-448be3c1f9d2@fleshgrinder.com>
	<CAKws9z3zCUPtsCu6QsFBMG4DOPE-ecsnOMaYP_TOgf5O-7UNAQ@mail.gmail.com>
	<d083b26b-2fb2-42a9-eb3d-1c4d63db3bec@fleshgrinder.com>
Date: Sun, 5 Jun 2016 04:35:41 -0400
Message-ID: <CAKws9z3tW8w+2+27fx9DcojqCY5EScQPUVMqHGBuZA8b9BBJoQ@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Libsodium - Discussion
From: scott@paragonie.com (Scott Arciszewski)

On Sun, Jun 5, 2016 at 4:31 AM, Fleshgrinder <php@fleshgrinder.com> wrote:
> On 6/5/2016 10:23 AM, Scott Arciszewski wrote:
>> I'm trying to keep concerns separate. I do want to make the pluggable
>> crypto API happen, but I barely have time for this libsodium RFC and I
>> don't want to conflate the two. (Even worse: I wouldn't want the mere
>> thought of an abstract high-level API to block libsodium from getting
>> accepted.)
>>
>> Instead of /completely redesigning/ the libsodium API, what are some
>> changes that need to be made to alleviate the majority of concerns
>> ("it's not the pluggable crypto API" notwithstanding)?
>>
>> Two things to keep in mind:
>>
>> 1. If it breaks existing code that uses libsodium-php in a nontrivial
>> way, I'm going to resist the change unless it can be proven necessary
>> for the sake of everyone's sanity.
>> 2. If it greatly deviates from the experience of using libsodium in
>> other programming languages (e.g. renaming crypto_box), you no longer
>> have libsodium and thus I will resist it.
>>
>> Getting rid of redundant features (by improving existing ones, not
>> just cutting them!) is fine. Dropping scrypt, etc. is fine.
>>
>
> Keeping sodium as an extension solves all your problems. You can keep
> evolving it in any way you like without having to argue with others. No
> breaking changes, nothing. It can even be used after another API is
> introduced in core.

All my problems? How do I get non-root users to install it?

> We can achieve this by introducing a different API in core that uses
> sodium in the background. This also allows us to exchange it without any
> interruptions in userland in the future.

That's the pluggable crypto API RFC, which I probably won't be able to
propose until 7.2. Feel free to pick it up if you'd rather advocate
for that.

> If existing functions like bin2hex or hex2bin are really not good enough
> than let us patch them. No need to introduce another function that does
> exactly the same. Whether the two are consistent in time or not does not
> change anything for userland. The resulting string is always the same. I
> think that the patch for aforementioned functions would even be possible
> without an RFC.

Okay, that's fine by me.

> The usage of names like secret box and box is simply not known to the
> average user and that makes them really bad. People will have to search
> the manual and dig deep until they find out that it is just about
> asymmetric and symmetric encryption. We already have enough stuff that
> makes no sense to the general public but to some.

Put yourself in the shoes of, say, a Python developer who uses
libsodium all the time who comes to PHP. If they don't find crypto_box
and crypto_secretbox, they're going to get confused.

> --
> Richard "Fleshgrinder" Fussenegger
>

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>