Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90468
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain paragonie.com from 209.85.217.171 cause and error)
MIME-Version: 1.0
In-Reply-To: <5692D424.2010908@gmail.com>
References: <CAKws9z1g24rD=t92+9xKtO=3PuwQ3_N=L36gmVMqCC84CoqipQ@mail.gmail.com>
	<CAEZPtU7-Lk=jGsTQgRZOvBpcPPgdX3V-23=3_k9CXbmxU77V1A@mail.gmail.com>
	<CAKws9z248Kj=0qTLPZik0Ki1_zGPq+4fr6HQi_keeVCso1S4eQ@mail.gmail.com>
	<5692CDB6.5050905@gmail.com>
	<CAKws9z1e_+XOzsojz9gW-zzswhaK7h+HothhTWWVSvDQXri2zA@mail.gmail.com>
	<5692D424.2010908@gmail.com>
Date: Sun, 10 Jan 2016 17:22:00 -0500
Message-ID: <CAKws9z15+U6F+ywskEfxVqhmqgTWUrmXtZERuKsHjusE+SanyQ@mail.gmail.com>
To: Rowan Collins <rowan.collins@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 Sun, Jan 10, 2016 at 4:59 PM, Rowan Collins <rowan.collins@gmail.com> wrote:
> On 10/01/2016 21:41, Scott Arciszewski wrote:
>>
>> Hi Rowan,
>>
>>> >I think what people are suggesting is not that libsodium shouldn't be
>>> >supported under-the-hood, just that the fact you're using it shouldn't
>>> > be
>>> >exposed to userland.
>>
>> These are separate concerns. Let's call them Sodium and SimpleSodium.
>>
>> With Sodium, power users gain the ability to write software that
>> directly uses low-level primitives in PHP without requiring their
>> users to install dependencies (i.e. from PECL). [
>>
>> SimpleSodium is a driver for the simple cryptography wrapper.
>
>
> As noted on the other thread, I think what people are looking for is
> actually somewhere between the two - something for power users to use
> *without tying their code to libsodium*. Code written using mcrypt_*
> functions is now facing an annoying upgrade path; code written with sodium_*
> functions now may face the same some years in the future, who knows?
>
> PHP should not be maintaining its own low-level implementations of crypto,
> but it should seem to the user as though it does - they should be asking PHP
> for a particular cipher / mode / etc, not asking libsodium for one via a
> thin PHP wrapper.
>
>
>> You can have SimpleSodium without Sodium, but if we don't get Sodium into
>> core
>> I will, personally, not be putting forth one more ounce of time or
>> effort into helping the PHP core so who knows maybe not?
>
>
> Obviously, this is entirely your prerogative, but it seems quite a
> black-and-white stance - maybe leave a bit of leeway for understanding other
> people's concerns before threatening to abandon work which would be very
> much appreciated.
>
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Hi Rowan,

> As noted on the other thread, I think what people are looking for is
> actually somewhere between the two - something for power users to use
> *without tying their code to libsodium*. Code written using mcrypt_*
> functions is now facing an annoying upgrade path; code written with sodium_*
> functions now may face the same some years in the future, who knows?

And I'm of the opinion that most users need a library that does
everything for them, and power users need a toolkit, and we shouldn't
try to solve both use cases with the same library. Some people might
be allergic to having two separate tools for two separate jobs, but I
am not one of them. Power-users will need low-level cipher
implementations, most developers will only write insecure code if we
let them.

If libsodium gets obsoleted (unlikely), it will be because of the
availability of practical quantum computers, which also obsoletes
openssl and all existing public-key cryptography. Mcrypt is unique in
that it was completely abandoned (and poorly designed, to boot) after
adoption. I don't think this is a meaningful discussion to have right
now, given how widespread it is.

https://download.libsodium.org/doc/bindings_for_other_languages/index.html

> PHP should not be maintaining its own low-level implementations of crypto,
> but it should seem to the user as though it does - they should be asking PHP
> for a particular cipher / mode / etc, not asking libsodium for one via a
> thin PHP wrapper.

There is little in common between openssl and libsodium. Go look at
the cipher options in libsodium; it forces you to use conservative,
secure ciphers. OpenSSL lets you encrypt in DES-ECB without complaint.

> Obviously, this is entirely your prerogative, but it seems quite a
> black-and-white stance - maybe leave a bit of leeway for understanding other
> people's concerns before threatening to abandon work which would be very
> much appreciated.

I'm just letting it be known now where I stand with this now rather
than later, so if this libsodium initiative doesn't pass and I
suddenly drop off internals and delete the relevant Github
repositories for the other projects I proposed, there will be no
question as to why.

I believe in being explicit and forthcoming.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>