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
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.
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
HI Scott,
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 Scott,
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
HI Scott,
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,
PierreHi 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 haverandom_bytes()there is
nothing redeemable about it.
Full ack.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
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,
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
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
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
--
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
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
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:
- 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. - 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
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:
- 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.- 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
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]
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]--
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
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]
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]--
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
Hi Scott,
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]
On Sun, Jan 10, 2016 at 4:59 PM, Rowan Collins rowan.collins@gmail.com
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]--
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.
Hi Scott,
questions inline.
I've updated the RFC to make libsodium a core PHP extension in 7.1, to
include references to the online documentation.
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
Hi Scott,
questions inline.
I've updated the RFC to make libsodium a core PHP extension in 7.1, to
include references to the online documentation.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_random16If 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
Hi Scott,
questions inline.
I've updated the RFC to make libsodium a core PHP extension in 7.1, to
include references to the online documentation.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_random16If 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
RouvenThe 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
-----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.
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
Can we call that extension "sodium" please without the "lib" prefix?
David
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
Can we call that extension "sodium" please without the "lib" prefix?
David
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--
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