Everything

php

Home » Project » Newsgroups » php.internals » [RFC] Libsodium »

[RFC] Libsodium

php.internals

Scott Arciszewski

10 years ago

Hi everyone,

I've updated the RFC to make libsodium a core PHP extension in 7.1, to
include references to the online documentation.

https://wiki.php.net/rfc/libsodium

All new functions and classes would exist in the Sodium namespace. e.g.

$ciphertext = \Sodium\crypto_box($message, $nonce, $keypair);

This is part of an overall effort to improve PHP's cryptography; up
next will be the pluggable crypto API that supports multiple backends
(with a scope limited to openssl and libsodium at the time of release)
but always provide conservative defaults. Then I'd like to look at
deprecating ext/mcrypt back to PECL and add more hash functions to
ext/hash.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>

Bishop Bettini

10 years ago

On Thu, Jan 7, 2016 at 8:26 AM, Scott Arciszewski <scott@paragonie.com>
wrote:

> I've updated the RFC to make libsodium a core PHP extension in 7.1, to
> include references to the online documentation.
>
> https://wiki.php.net/rfc/libsodium
>
> All new functions and classes would exist in the Sodium namespace. e.g.
>
>     $ciphertext = \Sodium\crypto_box($message, $nonce, $keypair);
>
> This is part of an overall effort to improve PHP's cryptography; up
> next will be the pluggable crypto API that supports multiple backends
> (with a scope limited to openssl and libsodium at the time of release)
> but always provide conservative defaults. Then I'd like to look at
> deprecating ext/mcrypt back to PECL and add more hash functions to
> ext/hash.
>

+1. Only comment is on namespace: how about \Php\Ext\Sodium?  I don't know
if namespacing PHP engine components has been standardized, but I feel we
should limit how often the engine consumes names in the global namespace.
E.g, I could see a user wanting "Sodium" for an app name, but couldn't use
it simultaneously with the libsodium extension.

Scott Arciszewski

10 years ago

On Thu, Jan 7, 2016 at 10:20 AM, Bishop Bettini <bishop@php.net> wrote:

> On Thu, Jan 7, 2016 at 8:26 AM, Scott Arciszewski <scott@paragonie.com>
> wrote:
>>
>> I've updated the RFC to make libsodium a core PHP extension in 7.1, to
>> include references to the online documentation.
>>
>> https://wiki.php.net/rfc/libsodium
>>
>> All new functions and classes would exist in the Sodium namespace. e.g.
>>
>>     $ciphertext = \Sodium\crypto_box($message, $nonce, $keypair);
>>
>> This is part of an overall effort to improve PHP's cryptography; up
>> next will be the pluggable crypto API that supports multiple backends
>> (with a scope limited to openssl and libsodium at the time of release)
>> but always provide conservative defaults. Then I'd like to look at
>> deprecating ext/mcrypt back to PECL and add more hash functions to
>> ext/hash.
>
>
> +1. Only comment is on namespace: how about \Php\Ext\Sodium?  I don't know
> if namespacing PHP engine components has been standardized, but I feel we
> should limit how often the engine consumes names in the global namespace.
> E.g, I could see a user wanting "Sodium" for an app name, but couldn't use
> it simultaneously with the libsodium extension.

Originally it was Sodium::function_name, but people complained.

I don't personally have a stake in this course of discussion. I'm fine
with almost anything, but the PECL extension, which has a "stable"
release, uses \Sodium\* already.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>

Pierre Joye

10 years ago

HI Scott,

On Thu, Jan 7, 2016 at 8:26 PM, Scott Arciszewski <scott@paragonie.com> wrote:

> Hi everyone,
>
> I've updated the RFC to make libsodium a core PHP extension in 7.1, to
> include references to the online documentation.
>
> https://wiki.php.net/rfc/libsodium
>
> All new functions and classes would exist in the Sodium namespace. e.g.
>
>     $ciphertext = \Sodium\crypto_box($message, $nonce, $keypair);

As much as I like libsodium, yet another extension with yet another
library in the core sounds like a risk to me, long term. I would
rather prefer to focus on a larger effort to provide the necessary
features in the most easiest way using new APIs or existing
extensions, as you mentioned already in previous discussions and in
this mail. That's why I won't be in favor of bundling this one.

> This is part of an overall effort to improve PHP's cryptography; up
> next will be the pluggable crypto API that supports multiple backends
> (with a scope limited to openssl and libsodium at the time of release)
> but always provide conservative defaults. Then I'd like to look at
> deprecating ext/mcrypt back to PECL and add more hash functions to
> ext/hash.

This is definitely the way. Thanks for your great work :)

Cheers,
Pierre

Scott Arciszewski

10 years ago

On Thu, Jan 7, 2016 at 10:51 AM, Pierre Joye <pierre.php@gmail.com> wrote:

> HI Scott,
>
> On Thu, Jan 7, 2016 at 8:26 PM, Scott Arciszewski <scott@paragonie.com> wrote:
>> Hi everyone,
>>
>> I've updated the RFC to make libsodium a core PHP extension in 7.1, to
>> include references to the online documentation.
>>
>> https://wiki.php.net/rfc/libsodium
>>
>> All new functions and classes would exist in the Sodium namespace. e.g.
>>
>>     $ciphertext = \Sodium\crypto_box($message, $nonce, $keypair);
>
> As much as I like libsodium, yet another extension with yet another
> library in the core sounds like a risk to me, long term. I would
> rather prefer to focus on a larger effort to provide the necessary
> features in the most easiest way using new APIs or existing
> extensions, as you mentioned already in previous discussions and in
> this mail. That's why I won't be in favor of bundling this one.
>
>> This is part of an overall effort to improve PHP's cryptography; up
>> next will be the pluggable crypto API that supports multiple backends
>> (with a scope limited to openssl and libsodium at the time of release)
>> but always provide conservative defaults. Then I'd like to look at
>> deprecating ext/mcrypt back to PECL and add more hash functions to
>> ext/hash.
>
> This is definitely the way. Thanks for your great work :)
>
> Cheers,
> Pierre

Hi Pierre,

> As much as I like libsodium, yet another extension with yet another
> library in the core sounds like a risk to me, long term. I would
> rather prefer to focus on a larger effort to provide the necessary
> features in the most easiest way using new APIs or existing
> extensions, as you mentioned already in previous discussions and in
> this mail. That's why I won't be in favor of bundling this one.

Even if we axe mcrypt and in with a net-gain of 0 extensions, you'd
see it as a risk?

----------------

Let me state this clearly: I'm personally not going to bother pushing
for a pluggable crypto API if the only option is to use OpenSSL and
all its legacy cruft. I especially don't have lukewarm feelings
towards RSA or ECDSA, which are your only real options with it.

I feel that it simply would not be a worthwhile use of my time to do
so. If Internals decides "no libsodium" but "yes pluggable crypto
API", you'll have to find someone else to spearhead it.

And I've said everything that needs to be said about mcrypt when I
said, "Kill it with fire!" Now that we have random_bytes() there is
nothing redeemable about it.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>

Pierre Joye

10 years ago

On Thu, Jan 7, 2016 at 11:11 PM, Scott Arciszewski <scott@paragonie.com> wrote:

> On Thu, Jan 7, 2016 at 10:51 AM, Pierre Joye <pierre.php@gmail.com> wrote:
>> HI Scott,
>>
>> On Thu, Jan 7, 2016 at 8:26 PM, Scott Arciszewski <scott@paragonie.com> wrote:
>>> Hi everyone,
>>>
>>> I've updated the RFC to make libsodium a core PHP extension in 7.1, to
>>> include references to the online documentation.
>>>
>>> https://wiki.php.net/rfc/libsodium
>>>
>>> All new functions and classes would exist in the Sodium namespace. e.g.
>>>
>>>     $ciphertext = \Sodium\crypto_box($message, $nonce, $keypair);
>>
>> As much as I like libsodium, yet another extension with yet another
>> library in the core sounds like a risk to me, long term. I would
>> rather prefer to focus on a larger effort to provide the necessary
>> features in the most easiest way using new APIs or existing
>> extensions, as you mentioned already in previous discussions and in
>> this mail. That's why I won't be in favor of bundling this one.
>>
>>> This is part of an overall effort to improve PHP's cryptography; up
>>> next will be the pluggable crypto API that supports multiple backends
>>> (with a scope limited to openssl and libsodium at the time of release)
>>> but always provide conservative defaults. Then I'd like to look at
>>> deprecating ext/mcrypt back to PECL and add more hash functions to
>>> ext/hash.
>>
>> This is definitely the way. Thanks for your great work :)
>>
>> Cheers,
>> Pierre
>
> Hi Pierre,
>
>> As much as I like libsodium, yet another extension with yet another
>> library in the core sounds like a risk to me, long term. I would
>> rather prefer to focus on a larger effort to provide the necessary
>> features in the most easiest way using new APIs or existing
>> extensions, as you mentioned already in previous discussions and in
>> this mail. That's why I won't be in favor of bundling this one.
>
> Even if we axe mcrypt and in with a net-gain of 0 extensions, you'd
> see it as a risk?

Except that we already refused to kill mcrypt, and it is not like I
did not try to convince us to kill it.

Does your extension provide a compatibility layer? I may have missed that :)

> ----------------
>
> Let me state this clearly: I'm personally not going to bother pushing
> for a pluggable crypto API if the only option is to use OpenSSL and
> all its legacy cruft. I especially don't have lukewarm feelings
> towards RSA or ECDSA, which are your only real options with it.
>
> I feel that it simply would not be a worthwhile use of my time to do
> so. If Internals decides "no libsodium" but "yes pluggable crypto
> API", you'll have to find someone else to spearhead it.

Sorry, my point was not clear.

I do like the concept of a pluggable crypto API. Very much. I said it
before and I say it again. I love the concept and will do what I can
to support it :)

What I do not like too much is the addition of an extension with
(relatively) low level functions for one specific library. It does not
really matter how good is this specific library, I simply do not see
such addition as a good strategic move.

> And I've said everything that needs to be said about mcrypt when I
> said, "Kill it with fire!" Now that we have random_bytes() there is
> nothing redeemable about it.

Full ack.

Cheers,

--
Pierre

@pierrejoye | http://www.libgd.org

Anthony Ferrara

10 years ago

Pierre,

>> Even if we axe mcrypt and in with a net-gain of 0 extensions, you'd
>> see it as a risk?
>
> Except that we already refused to kill mcrypt, and it is not like I
> did not try to convince us to kill it.

We decided not to kill it for 7.0. That doesn't mean it got a permanent buy...

>> Let me state this clearly: I'm personally not going to bother pushing
>> for a pluggable crypto API if the only option is to use OpenSSL and
>> all its legacy cruft. I especially don't have lukewarm feelings
>> towards RSA or ECDSA, which are your only real options with it.
>>
>> I feel that it simply would not be a worthwhile use of my time to do
>> so. If Internals decides "no libsodium" but "yes pluggable crypto
>> API", you'll have to find someone else to spearhead it.
>
> Sorry, my point was not clear.
>
> I do like the concept of a pluggable crypto API. Very much. I said it
> before and I say it again. I love the concept and will do what I can
> to support it :)
>
> What I do not like too much is the addition of an extension with
> (relatively) low level functions for one specific library. It does not
> really matter how good is this specific library, I simply do not see
> such addition as a good strategic move.

I agree with you in principle, but in this particular case I think
that there's enough justification considering how measurably bad
mcrypt is, and how little some people trust openssl. That leaves no
room in core. So in this case I think it *may* be worth it to add it.

Anthony

Pierre Joye

10 years ago

On Thu, Jan 7, 2016 at 11:30 PM, Anthony Ferrara <ircmaxell@gmail.com> wrote:

> Pierre,
>
>>> Even if we axe mcrypt and in with a net-gain of 0 extensions, you'd
>>> see it as a risk?
>>
>> Except that we already refused to kill mcrypt, and it is not like I
>> did not try to convince us to kill it.
>
> We decided not to kill it for 7.0. That doesn't mean it got a permanent buy...

It is pretty much a 7.x permanent buy, yes. And that's why we pushed
hard to kill it before. Unless we consider killing extensions in minor
releases a non BC break ;-)

>>> Let me state this clearly: I'm personally not going to bother pushing
>>> for a pluggable crypto API if the only option is to use OpenSSL and
>>> all its legacy cruft. I especially don't have lukewarm feelings
>>> towards RSA or ECDSA, which are your only real options with it.
>>>
>>> I feel that it simply would not be a worthwhile use of my time to do
>>> so. If Internals decides "no libsodium" but "yes pluggable crypto
>>> API", you'll have to find someone else to spearhead it.
>>
>> Sorry, my point was not clear.
>>
>> I do like the concept of a pluggable crypto API. Very much. I said it
>> before and I say it again. I love the concept and will do what I can
>> to support it :)
>>
>> What I do not like too much is the addition of an extension with
>> (relatively) low level functions for one specific library. It does not
>> really matter how good is this specific library, I simply do not see
>> such addition as a good strategic move.
>
> I agree with you in principle, but in this particular case I think
> that there's enough justification considering how measurably bad
> mcrypt is, and how little some people trust openssl. That leaves no
> room in core. So in this case I think it *may* be worth it to add it.

If the pluggable API one won't show up before 7.2/3, yes. If we
potentially can sort it out for 7.1/2/3, then no.

Cheers,

--
Pierre

@pierrejoye | http://www.libgd.org

Jan Ehrhardt

10 years ago

Anthony Ferrara in php.internals (Thu, 7 Jan 2016 11:30:14 -0500):

>I agree with you in principle, but in this particular case I think
>that there's enough justification considering how measurably bad
>mcrypt is, and how little some people trust openssl.

OTH, OpenSSL has made progress and the quality is improving as far as I
can tell as a bystander.

--
Jan

Scott Arciszewski

10 years ago

On Thu, Jan 7, 2016 at 11:58 AM, Jan Ehrhardt <phpdev@ehrhardt.nl> wrote:

> Anthony Ferrara in php.internals (Thu, 7 Jan 2016 11:30:14 -0500):
>>I agree with you in principle, but in this particular case I think
>>that there's enough justification considering how measurably bad
>>mcrypt is, and how little some people trust openssl.
>
> OTH, OpenSSL has made progress and the quality is improving as far as I
> can tell as a bystander.
> --
> Jan
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Their cipher implementations are OK.

Their userspace "CS"PRNG needs to be [any violent metaphor for
"deleted" here] in favor of using the kernel's. Then again, LibreSSL
is also guilty of this. BoringSSL does it right.

Their certificate validation code, last I checked, is the stuff of
nightmares. I recall an 800+ line C function. (Have fun auditing
that!)

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>

Tom Worster

10 years ago

On 1/7/16 11:24 AM, Pierre Joye wrote:

> What I do not like too much is the addition of an extension with
> (relatively) low level functions for one specific library. It does not
> really matter how good is this specific library, I simply do not see
> such addition as a good strategic move.

I also worry that it's yet another thing to maintain. The more API you
offer to the PHP programmer, the more responsibility you take on.

Tom

Scott Arciszewski

10 years ago

On Sun, Jan 10, 2016 at 3:18 PM, Tom Worster <fsb@thefsb.org> wrote:

> On 1/7/16 11:24 AM, Pierre Joye wrote:
>>
>> What I do not like too much is the addition of an extension with
>> (relatively) low level functions for one specific library. It does not
>> really matter how good is this specific library, I simply do not see
>> such addition as a good strategic move.
>
>
> I also worry that it's yet another thing to maintain. The more API you offer
> to the PHP programmer, the more responsibility you take on.
>
> Tom

Except two things:

1. I'm trying to get rid of mcrypt, bringing the net change of
cryptography libraries to maintain to 0, but still improving the
cryptography library availability significantly.
2. I'm willing to maintain it, so you're gaining manpower with this change.

I'd argue that, strategically, what I've proposed across several RFCs
is superior to maintaining the status quo.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>

Tom Worster

10 years ago

On 1/10/16, 3:39 PM, "Scott Arciszewski" <scott@paragonie.com> wrote:

>On Sun, Jan 10, 2016 at 3:18 PM, Tom Worster <fsb@thefsb.org> wrote:
>> On 1/7/16 11:24 AM, Pierre Joye wrote:
>>>
>>> What I do not like too much is the addition of an extension with
>>> (relatively) low level functions for one specific library. It does not
>>> really matter how good is this specific library, I simply do not see
>>> such addition as a good strategic move.
>>
>>
>> I also worry that it's yet another thing to maintain. The more API you
>>offer
>> to the PHP programmer, the more responsibility you take on.
>>
>> Tom
>
>Except two things:
>
>1. I'm trying to get rid of mcrypt, bringing the net change of
>cryptography libraries to maintain to 0, but still improving the
>cryptography library availability significantly.
>2. I'm willing to maintain it, so you're gaining manpower with this
>change.
>
>I'd argue that, strategically, what I've proposed across several RFCs
>is superior to maintaining the status quo.

A high-level API that plugs into Sodium, Open,Libre,BoringSSL (and maybe
etc.) in addition to a low-level libsodium API is more responsibility in
total than only high-level API. So "relative to the status quo" isn't the
only interesting perspective.

Unless I misunderstand your proposal. Are you saying that you are only
interested in working on the high-level API if libsodium moves to core? In
that case the other perspective isn't relevant.

Tom

Rowan Collins

10 years ago

On 07/01/2016 16:11, Scott Arciszewski wrote:

> I'm personally not going to bother pushing
> for a pluggable crypto API if the only option is to use OpenSSL and
> all its legacy cruft.

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. A PDO-like encryption interface (which as I
understand it is not what you proposed in your other thread) would allow
us to add libsodium in such a way that a relatively painless migration
path can be created if it goes the way of mcrypt. So the pluggable API
removes the need for any of the sodium_* / Sodium::* / \Sodium\* functions.

Regards,

--
Rowan Collins
[IMSoP]

Scott Arciszewski

10 years ago

On Sun, Jan 10, 2016 at 4:31 PM, Rowan Collins <rowan.collins@gmail.com> wrote:

> On 07/01/2016 16:11, Scott Arciszewski wrote:
>>
>> I'm personally not going to bother pushing
>> for a pluggable crypto API if the only option is to use OpenSSL and
>> all its legacy cruft.
>
>
> 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. A PDO-like encryption interface (which as I understand
> it is not what you proposed in your other thread) would allow us to add
> libsodium in such a way that a relatively painless migration path can be
> created if it goes the way of mcrypt. So the pluggable API removes the need
> for any of the sodium_* / Sodium::* / \Sodium\* functions.
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

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). Halite 2.0.0 is going
to ship with an API for Axolotl, which is the ratcheting protocol used
by Signal (formerly TextSecure + RedPhone). Being able to offer Signal
integration in SMS-based two factor authentication schemes is a very
attractive proposition; even moreso if Sodium is a core extension.

SimpleSodium is a driver for the simple cryptography 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?

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>

Rowan Collins

10 years ago

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]

Scott Arciszewski

10 years ago

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>

Rowan Collins

10 years ago

Hi Scott,

On 10/01/2016 22:22, Scott Arciszewski wrote:

> 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.

I don't think anyone is arguing against that, they just see a different
pair of tools: a toolkit which is abstracted slightly away from
libsodium but still has all its flexibility, and a crypto-for-dummies
interface on top of that.

> 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.

OpenSSL was incredibly widespread when Heartbleed was uncovered; it
still is, and from your other mails you're still not a fan. Without a
crystal ball, we can't know that Sodium is going to last forever, so are
looking for a way to integrate its functionality into PHP in such a way
that if an alternative comes along later, it is relatively easy to port
code from one to the other, rather than tying PHP code directly to
Sodium's API.

It may even turn out - I honestly don't know - that the only thing we
need to change in Sodium's API is the word "Sodium", and we could simply
present the functions as "a toolbox of encryption primitives, currently
implemented using libsodium".

Regards,

--
Rowan Collins
[IMSoP]

Pierre Joye

10 years ago

On Jan 11, 2016 5:22 AM, "Scott Arciszewski" <scott@paragonie.com> wrote:

>
> 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.

This is a valid and good point.

Also agree on the need of the two. Now whether the toolkit should be an
extension or userland can be discussed as well.

Whether sodium (or other) are in the core or  not, the discussions about a
more powerful (also proposing a wider range of options for various tasks,
even using bad cyphers) sound like a good thing and may as well answer the
question about your libsodium binding proposal.

> Some people might
> be allergic to having two separate tools for two separate jobs,

On the other hand they have things in common. But I totally agree on the
userland side. PHP needs a password-like APIs for crypto, where users will
have a hard time to do it wrong.

> 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
>

> 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.

This is your choice and you are indeed free to do it.

I cannot agree on both the killing of repositories in general and even less
of threatens to do so if a given proposal is not accept. It goes against my
principles.

In any case, given that we can have a constructive discussions about the
design and needs, I am sure we will find answers to these questions in the
next couple of weeks.

Rouven Weßling

10 years ago

Hi Scott,

questions inline.

> On 07 Jan 2016, at 14:26, Scott Arciszewski <scott@paragonie.com> wrote:
>
> I've updated the RFC to make libsodium a core PHP extension in 7.1, to
> include references to the online documentation.
>
> https://wiki.php.net/rfc/libsodium

I know this is made difficult by the fact that this is an existing, stable PECL extension, which also supports older PHP versions but I don’t think it’s a good idea to introduce more functions that duplicate things handled already in core (I don’t mean in ext-openssl as lib sodium would be an alternative to that extension). I’d rather see less duplication, not more.

From a quick glance the following functions seems to be already covered:
\Sodium\memcmp
\Sodium\bin2hex
\Sodium\hex2bin
\Sodium\randombytes_buf
\Sodium\randombytes_uniform
\Sodium\randombytes_random16

If their implementation is better than the core implementation, core should be fixed.

Do the hashing functions have any advantage over those provided by ext-hash?

There are also a couple of other functions whose value I’d question, I’ll send an email about those later.

> This is part of an overall effort to improve PHP's cryptography; up
> next will be the pluggable crypto API that supports multiple backends
> (with a scope limited to openssl and libsodium at the time of release)
> but always provide conservative defaults.

A more general question: I haven’t looked at your prototype for a higher level API yet, but I’m wondering if it’s still necessary to introduce another low level API? When would I choose to use the latter?

Best regards
Rouven

Scott Arciszewski

10 years ago

On Thu, Jan 7, 2016 at 10:52 AM, Rouven Weßling <me@rouvenwessling.de> wrote:

> Hi Scott,
>
> questions inline.
>
>> On 07 Jan 2016, at 14:26, Scott Arciszewski <scott@paragonie.com> wrote:
>>
>> I've updated the RFC to make libsodium a core PHP extension in 7.1, to
>> include references to the online documentation.
>>
>> https://wiki.php.net/rfc/libsodium
>
> I know this is made difficult by the fact that this is an existing, stable PECL extension, which also supports older PHP versions but I don’t think it’s a good idea to introduce more functions that duplicate things handled already in core (I don’t mean in ext-openssl as lib sodium would be an alternative to that extension). I’d rather see less duplication, not more.
>
> From a quick glance the following functions seems to be already covered:
> \Sodium\memcmp
> \Sodium\bin2hex
> \Sodium\hex2bin
> \Sodium\randombytes_buf
> \Sodium\randombytes_uniform
> \Sodium\randombytes_random16
>
> If their implementation is better than the core implementation, core should be fixed.
>
> Do the hashing functions have any advantage over those provided by ext-hash?
>
> There are also a couple of other functions whose value I’d question, I’ll send an email about those later.
>
>> This is part of an overall effort to improve PHP's cryptography; up
>> next will be the pluggable crypto API that supports multiple backends
>> (with a scope limited to openssl and libsodium at the time of release)
>> but always provide conservative defaults.
>
> A more general question: I haven’t looked at your prototype for a higher level API yet, but I’m wondering if it’s still necessary to introduce another low level API? When would I choose to use the latter?
>
> Best regards
> Rouven

The high-level API ties the user's hands and doesn't give them direct
access to primitives. You can't use it for AES-256-ECB, you can only
use it for AES-256-CTR+HMAC-SHA-384, with an encoded and
version-tagged output, for example.

You still need ext/libsodium if you need to use any of its features
directly, such as \Sodium\memzero().

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>

Scott Arciszewski

10 years ago

On Thu, Jan 7, 2016 at 10:54 AM, Scott Arciszewski <scott@paragonie.com> wrote:

> On Thu, Jan 7, 2016 at 10:52 AM, Rouven Weßling <me@rouvenwessling.de> wrote:
>> Hi Scott,
>>
>> questions inline.
>>
>>> On 07 Jan 2016, at 14:26, Scott Arciszewski <scott@paragonie.com> wrote:
>>>
>>> I've updated the RFC to make libsodium a core PHP extension in 7.1, to
>>> include references to the online documentation.
>>>
>>> https://wiki.php.net/rfc/libsodium
>>
>> I know this is made difficult by the fact that this is an existing, stable PECL extension, which also supports older PHP versions but I don’t think it’s a good idea to introduce more functions that duplicate things handled already in core (I don’t mean in ext-openssl as lib sodium would be an alternative to that extension). I’d rather see less duplication, not more.
>>
>> From a quick glance the following functions seems to be already covered:
>> \Sodium\memcmp
>> \Sodium\bin2hex
>> \Sodium\hex2bin
>> \Sodium\randombytes_buf
>> \Sodium\randombytes_uniform
>> \Sodium\randombytes_random16
>>
>> If their implementation is better than the core implementation, core should be fixed.
>>
>> Do the hashing functions have any advantage over those provided by ext-hash?
>>
>> There are also a couple of other functions whose value I’d question, I’ll send an email about those later.
>>
>>> This is part of an overall effort to improve PHP's cryptography; up
>>> next will be the pluggable crypto API that supports multiple backends
>>> (with a scope limited to openssl and libsodium at the time of release)
>>> but always provide conservative defaults.
>>
>> A more general question: I haven’t looked at your prototype for a higher level API yet, but I’m wondering if it’s still necessary to introduce another low level API? When would I choose to use the latter?
>>
>> Best regards
>> Rouven
>
> The high-level API ties the user's hands and doesn't give them direct
> access to primitives. You can't use it for AES-256-ECB, you can only
> use it for AES-256-CTR+HMAC-SHA-384, with an encoded and
> version-tagged output, for example.
>
> You still need ext/libsodium if you need to use any of its features
> directly, such as \Sodium\memzero().
>
> Scott Arciszewski
> Chief Development Officer
> Paragon Initiative Enterprises <https://paragonie.com>

To clarify: You can swap out AES-256 for AES-192, or SHA-384 for SHA-256, etc.

You cannot swap out the protocol construction for anything other than
Encrypt then MAC.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>

Remi Collet

10 years ago

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 07/01/2016 14:26, Scott Arciszewski a écrit :

> Hi everyone,
>
> I've updated the RFC to make libsodium a core PHP extension in 7.1,
> to include references to the online documentation.
>
> https://wiki.php.net/rfc/libsodium

Nice extension.

IMHO it can be simpler to keep such extension in PECL, especially as
libsodium (the library) is quite active, and have recently introduce
some API changes (soname bump). I mean, if the extension API have to
change, it is easier to do this "outside" of PHP [1].

I only hate the extension name. libsodium is not a library (and
libsodium.so on linux is very confusing, for users, and for build system
)

I really prefer a non confusing name, like "sodium" (which also match
the used namespace).


Remi.


[1] this didn't means I'm against the idea to have it in core php-src.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlaOlW4ACgkQYUppBSnxahh8rACgj71wFRl1te+jbzhYYhfoMz2f
Ky8An1a4zwYOn09o7RgdSH2UIxxtnvVy
=ZXOi
-----END PGP SIGNATURE-----

David Zuelke

10 years ago

Can we call that extension "sodium" please without the "lib" prefix?

David

Scott Arciszewski

10 years ago

On Sun, Jan 10, 2016 at 6:56 PM, David Zuelke <dz@heroku.com> wrote:

> Can we call that extension "sodium" please without the "lib" prefix?
>
> David
>
>
>> On 07.01.2016, at 08:26, Scott Arciszewski <scott@paragonie.com> wrote:
>>
>> Hi everyone,
>>
>> I've updated the RFC to make libsodium a core PHP extension in 7.1, to
>> include references to the online documentation.
>>
>> https://wiki.php.net/rfc/libsodium
>>
>> All new functions and classes would exist in the Sodium namespace. e.g.
>>
>>    $ciphertext = \Sodium\crypto_box($message, $nonce, $keypair);
>>
>> This is part of an overall effort to improve PHP's cryptography; up
>> next will be the pluggable crypto API that supports multiple backends
>> (with a scope limited to openssl and libsodium at the time of release)
>> but always provide conservative defaults. Then I'd like to look at
>> deprecating ext/mcrypt back to PECL and add more hash functions to
>> ext/hash.
>>
>> Scott Arciszewski
>> Chief Development Officer
>> Paragon Initiative Enterprises <https://paragonie.com>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>

Yes, I don't think that would be controversial. The underlying library
is libsodium, but we don't have to refer to our bindings as such.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>