Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93674
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: <CADyq6sKr_6qi4Fnk9+yxgCA5j_xF7B7vxq7HH5_nneax5bLf5A@mail.gmail.com>
References: <CAKws9z114YcHkDaXO3o-E0JuHR10WsPzyedeF_8Q=shHDziwug@mail.gmail.com>
	<CADyq6sKr_6qi4Fnk9+yxgCA5j_xF7B7vxq7HH5_nneax5bLf5A@mail.gmail.com>
Date: Wed, 1 Jun 2016 09:45:04 -0400
Message-ID: <CAKws9z23=M51t2OnedmyrXUkjXD55bDfrwEu+YRcbkDNOmB3ww@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1149e4526af85c053437b2bb
Subject: Re: [PHP-DEV] [RFC] Libsodium - Discussion
From: scott@paragonie.com (Scott Arciszewski)

--001a1149e4526af85c053437b2bb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 ide=
a
>> and the benefits it offers.
>>
>> https://wiki.php.net/rfc/libsodium
>>
>> If the subsequent discussion goes smoothly, I would like to open voting =
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 (and=
 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 t=
he
> 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 actually
> does, like `sodium_encrypt_and_sign()`. While the naming may be emerging
> 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 just
> 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 t=
he
> 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 today =
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 automatic "=
No"
votes.

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().

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>=E2=80=8B

--001a1149e4526af85c053437b2bb--