Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93676
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain paragonie.com designates 209.85.218.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADyq6s+E96sncKxoTzJ8cOvJSUF4xy6ZShn3O1aXe5T=-_GRtw@mail.gmail.com>
References: <CAKws9z114YcHkDaXO3o-E0JuHR10WsPzyedeF_8Q=shHDziwug@mail.gmail.com>
	<CADyq6sKr_6qi4Fnk9+yxgCA5j_xF7B7vxq7HH5_nneax5bLf5A@mail.gmail.com>
	<CAKws9z23=M51t2OnedmyrXUkjXD55bDfrwEu+YRcbkDNOmB3ww@mail.gmail.com>
	<CADyq6s+E96sncKxoTzJ8cOvJSUF4xy6ZShn3O1aXe5T=-_GRtw@mail.gmail.com>
Date: Wed, 1 Jun 2016 09:53:01 -0400
Message-ID: <CAKws9z34EdbcLCZB65c4jtqymbYRbeHefwm5oYwHbeCHSoFK5Q@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11352d74e04572053437ce78
Subject: Re: [PHP-DEV] [RFC] Libsodium - Discussion
From: scott@paragonie.com (Scott Arciszewski)

--001a11352d74e04572053437ce78
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 1, 2016 at 9:46 AM, Marco Pivetta <ocramius@gmail.com> wrote:

> On 1 June 2016 at 15:45, Scott Arciszewski <scott@paragonie.com> wrote:
>
>> On Wed, Jun 1, 2016 at 6:48 AM, Marco Pivetta <ocramius@gmail.com> wrote=
:
>>
>>> Hey Scott,
>>>
>>> On 1 June 2016 at 09:49, Scott Arciszewski <scott@paragonie.com> wrote:
>>>
>>>> Hi PHP Internals Team,
>>>>
>>>> Let's begin discussing the prospect of adding libsodium as a core
>>>> extension
>>>> in PHP 7.1. I've updated the RFC to explain why this would be a good
>>>> idea
>>>> and the benefits it offers.
>>>>
>>>> https://wiki.php.net/rfc/libsodium
>>>>
>>>> If the subsequent discussion goes smoothly, I would like to open votin=
g
>>>> on
>>>> June 15.
>>>>
>>>> Together, let's make PHP cryptography so safe that it becomes boring.
>>>>
>>>
>>> First, thanks for providing better alternatives to crypto in PHP!
>>>
>>> I also agree with Remi on naming: let's avoid calling the extension
>>> `libsodium`.
>>>
>>> I have some concerns that are just about code quality, not about
>>> functionality. Consider that I didn't look at the underlying library (a=
nd I
>>> really care little about it, from a consumer perspective).
>>>
>>>  1. is there a particular reason why abbreviations are used? For
>>> instance, why `sodium_randombytes_buf()` instead of
>>> `sodium_random_bytes_buffer()`?
>>>  2. from a naming perspective, I'd expect `sodium_randombytes_buf()` to
>>> give me a buffer of random bytes (probably as a stream), but it returns=
 the
>>> actual string of random bytes. Again: confusing naming
>>>  3. can we avoid using "themed" naming? For example, instead of
>>> `sodium_crypto_secretbox()`, it would be best to express what it actual=
ly
>>> does, like `sodium_encrypt_and_sign()`. While the naming may be emergin=
g
>>> from lower layers, I still (like I did with other RFCs) disagree with
>>> inheriting confusing naming. This will just cause users to look up the
>>> naming up when reading or writing code, and ultimately add up to silly
>>> bugs. I can already foresee that people will use the API incorrectly ju=
st
>>> because of the naming.
>>>  4. can't we just keep it namespaced under `Sodium`, instead of adding
>>> more stuff to the root level namespace? Does anyone have a reference to=
 the
>>> coding standards that would cause the rename?
>>>
>>> Cheers,
>>>
>>> Marco Pivetta
>>>
>>> http://twitter.com/Ocramius
>>>
>>> http://ocramius.github.com/
>>>
>>>
>> =E2=80=8BI'd love to just keep the namespace personally
>> =E2=80=8B (
>> Ke
>> =E2=80=8Beping \Sodium\foo() and \SODIUM\FOO means code I've written tod=
ay will
>> work in 7.1 for non-PECL users
>> =E2=80=8B, and less work we thrust on Frank Denis)=E2=80=8B
>> =E2=80=8B
>> but it was previously expressed that doing so violates the coding
>> standard.
>> =E2=80=8B Changing to sodium_* would mean less bikeshedding and automati=
c "No"
>> votes.
>>
>
> Weird... I guess we could add a subsection to the vote?
>
>
>> As for the function names, that's what they were called in NaCl.
>> https://nacl.cr.yp.to/secretbox.html
>>
>> I believe randombytes_buf() was named in a similar spirit to OpenBSD's
>> arc4random_buf().
>>
>
> Yeh, that is software archaeology though, not software design ;-)
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>

Strictly speaking,
=E2=80=8B our=E2=80=8B
random_bytes()=E2=80=8B
=E2=80=8B is every bit good enough without \Sodium\randombytes_buf(), for t=
he PHP
use case. We might be able to trim some redundant features (however, unless
we make all the PHP encoding functions cache-timing-safe, will insist on
keeping \Sodium\bin2hex and \Sodium\hex2bin).

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>

--001a11352d74e04572053437ce78--