Hi all,
I'm resurrecting my RFC to add libsodium as a core extension to PHP 7.2.
In response to feedback from Pierre Joye, I've outlined which parts of the
existing libsodium API I'd like exposed in the core extension. Most notably:
- Removed crypto_aead_aes256gcm_* because OpenSSL offers it
- Removed crypto_aead_chacha20poly1305_* because crypto_aead_* is awaiting
the CAESAR winner https://competitions.cr.yp.to/caesar.html - Removed crypto_pwhash_scryptsalsa208sha256_* because we have Argon2i now
If anyone would like to weigh in on this in the next few weeks, I'd greatly
appreciate it.
I'm also developing a polyfill for most of the API features (except
pwhash): https://github.com/paragonie/sodium_compat
Warm regards,
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com
On Wed, Jan 11, 2017 at 7:22 PM, Scott Arciszewski scott@paragonie.com
wrote:
Hi all,
I'm resurrecting my RFC to add libsodium as a core extension to PHP 7.2.
In response to feedback from Pierre Joye, I've outlined which parts of the
existing libsodium API I'd like exposed in the core extension. Most
notably:
- Removed crypto_aead_aes256gcm_* because OpenSSL offers it
- Removed crypto_aead_chacha20poly1305_* because crypto_aead_* is awaiting
the CAESAR winner https://competitions.cr.yp.to/caesar.html- Removed crypto_pwhash_scryptsalsa208sha256_* because we have Argon2i now
If anyone would like to weigh in on this in the next few weeks, I'd greatly
appreciate it.I'm also developing a polyfill for most of the API features (except
pwhash): https://github.com/paragonie/sodium_compat
I guess you are talking about this : https://wiki.php.net/rfc/libsodium
Huge +1.
What about libsodium usage under Windows ?
I guess under *Nix, we'll rely on the OS shipping of the library , but
that's not the same flavour for Windows, where we usually need to embed,
and maintain the library.
I see a second vote for the API , PHP is not really a language where
You\Use\Things\Like\That , I'm all +1 to use_things_like_that() instead :-)
After Mcrypt has been abandonned , we really really need such a library
binding added to Core IMO.
Julien.Pauli
On Wed, Jan 11, 2017 at 7:22 PM, Scott Arciszewski scott@paragonie.com
wrote:Hi all,
I'm resurrecting my RFC to add libsodium as a core extension to PHP 7.2.
In response to feedback from Pierre Joye, I've outlined which parts of the
existing libsodium API I'd like exposed in the core extension. Most
notably:
- Removed crypto_aead_aes256gcm_* because OpenSSL offers it
- Removed crypto_aead_chacha20poly1305_* because crypto_aead_* is awaiting
the CAESAR winner https://competitions.cr.yp.to/caesar.html- Removed crypto_pwhash_scryptsalsa208sha256_* because we have Argon2i
nowIf anyone would like to weigh in on this in the next few weeks, I'd
greatly
appreciate it.I'm also developing a polyfill for most of the API features (except
pwhash): https://github.com/paragonie/sodium_compatI guess you are talking about this : https://wiki.php.net/rfc/libsodium
Huge +1.
What about libsodium usage under Windows ?
I guess under *Nix, we'll rely on the OS shipping of the library , but
that's not the same flavour for Windows, where we usually need to embed,
and maintain the library.I see a second vote for the API , PHP is not really a language where
You\Use\Things\Like\That , I'm all +1 to use_things_like_that() instead :-)After Mcrypt has been abandonned , we really really need such a library
binding added to Core IMO.Julien.Pauli
Yep, that's the correct URL.
What about libsodium usage under Windows ?
I guess under *Nix, we'll rely on the OS shipping of the library , but
that's not the same flavour for Windows, where we usually need to embed,
and maintain the library.
I'll defer to Pierre Joye on the intricacies involved with Windows, as
that's a topic I'm mostly unfamiliar with. Sorry I can't offer much more in
response to that.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com/
On Tue, Jan 17, 2017 at 5:49 AM, Scott Arciszewski scott@paragonie.com
wrote:
On Wed, Jan 11, 2017 at 7:22 PM, Scott Arciszewski scott@paragonie.com
wrote:Hi all,
I'm resurrecting my RFC to add libsodium as a core extension to PHP 7.2.
In response to feedback from Pierre Joye, I've outlined which parts of
the
existing libsodium API I'd like exposed in the core extension. Most
notably:
- Removed crypto_aead_aes256gcm_* because OpenSSL offers it
- Removed crypto_aead_chacha20poly1305_* because crypto_aead_* is
awaiting
the CAESAR winner https://competitions.cr.yp.to/caesar.html- Removed crypto_pwhash_scryptsalsa208sha256_* because we have Argon2i
nowIf anyone would like to weigh in on this in the next few weeks, I'd
greatly
appreciate it.I'm also developing a polyfill for most of the API features (except
pwhash): https://github.com/paragonie/sodium_compatI guess you are talking about this : https://wiki.php.net/rfc/libsodium
Huge +1.
What about libsodium usage under Windows ?
I guess under *Nix, we'll rely on the OS shipping of the library , but
that's not the same flavour for Windows, where we usually need to embed,
and maintain the library.I see a second vote for the API , PHP is not really a language where
You\Use\Things\Like\That , I'm all +1 to use_things_like_that() instead :-)After Mcrypt has been abandonned , we really really need such a library
binding added to Core IMO.Julien.Pauli
Yep, that's the correct URL.
What about libsodium usage under Windows ?
I guess under *Nix, we'll rely on the OS shipping of the library , but
that's not the same flavour for Windows, where we usually need to embed,
and maintain the library.
I'll defer to Pierre Joye on the intricacies involved with Windows, as
that's a topic I'm mostly unfamiliar with. Sorry I can't offer much more in
response to that.Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com/
Hi again,
I've updated the RFC to v0.5.0:
https://wiki.php.net/rfc/libsodium
This adds crypto_aead_chacha20poly1305 which is extremely useful for
protocols like Noise, which will come in handy if anyone ever wants to
build WhatsApp bots. http://www.noiseprotocol.org/
At this point, I believe the API coverage is satisfactory. If there are no
objections, comments, or questions, I'd like to open voting soon. It's been
two weeks already, but in interest of fairness, I'll open the vote one week
from now at the earliest.
R
egards,
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com/
Hi,
On Wed, Jan 11, 2017 at 6:22 PM, Scott Arciszewski scott@paragonie.com
wrote:
Hi all,
I'm resurrecting my RFC to add libsodium as a core extension to PHP 7.2.
I'm still not sure why it needs to be in the core. As I said before, there
are lots of healthy extension that are not in the core and it certainly
doesn't make them less used (e.g. redis, xdebug or mongo driver). At the
end it's all about packaging...
I think libsodium has lots of really good features and it's a very nice
lib. However what makes me a bit uneasy about libsodium is that it's
basically a one dev library which is even clearly visible in here:
https://github.com/jedisct1/libsodium/graphs/contributors
It is certainly a bit more risky to support such lib if it all depends on
on one person rather than a team of developers. I'm not saying that it's
the same but mcrypt used to be also just one developer lib...
Cheers
Jakub
Hi,
On Wed, Jan 11, 2017 at 6:22 PM, Scott Arciszewski scott@paragonie.com
wrote:Hi all,
I'm resurrecting my RFC to add libsodium as a core extension to PHP 7.2.
I'm still not sure why it needs to be in the core. As I said before, there
are lots of healthy extension that are not in the core and it certainly
doesn't make them less used (e.g. redis, xdebug or mongo driver). At the
end it's all about packaging...I think libsodium has lots of really good features and it's a very nice
lib. However what makes me a bit uneasy about libsodium is that it's
basically a one dev library which is even clearly visible in here:https://github.com/jedisct1/libsodium/graphs/contributors
It is certainly a bit more risky to support such lib if it all depends on
on one person rather than a team of developers. I'm not saying that it's
the same but mcrypt used to be also just one developer lib...Cheers
Jakub
I erroneously replied off-list, and rather than forward messages that were
sent directly to me (on the offchance that they were not intended to be
public), I'll just reiterate what I said privately. From my original email:
Was mcrypt in core?
Is openssl still in core?
If the answer to both these questions is "Yes", then it follows that
libsodium should be in the core. Especially if everyone agrees that it
should be included by default.However what makes me a bit uneasy about libsodium is that it's
basically a one dev library which is even clearly visible in here:You're looking at it all wrong. Look here instead:
https://github.com/jedisct1/libsodium/blob/master/AUTHORSThe person who checked the code into Github may have been Frank Denis for
a lot of cases, but the code itself was written by cryptographers.Calling it "basically a one dev library" sounds simultaneously dismissive
and misinformed. (Also: There have been 58 contributors besides Frank,
which doesn't lead to your point at all.)Do you know any cryptography experts? Go ask them, "What would you rather
see devs use? OpenSSL or libsodium?" and report back what they say. To be
clear: I'm fairly confident that a large majority will not choose OpenSSL.
Furthermore, I'd like to raise an additional point.
PHP Archive signing currently has the following options:
- A hash function (forgery = trivial)
- OpenSSL signing (which I believe means RSA-PKCSv1.5 with SHA1; Daniel
Bleichenbacher had something to say about that in 2006, but e=65537 breaks
the public exploit)
Putting libsodium in core allows us to add Ed25519 signatures to Phars,
which means that we can provide a reasonable level (128 bits is what I call
reasonable) of assurance that the PHP archive is authentic (assuming you
have a trustworthy public key).
Without putting libsodium in core, can we do that? If not, that's a solid
motivation to vote YES on this RFC.
Conversely, let's discuss a hypothetical: If this motion is abandoned, can
you (or, rather, everyone on this mailing list working together) guarantee
that 100% of operating systems will bundle libsodium and the PHP extension
in PECL with PHP 7.2 out-of-the-box, by default? That includes Windows,
FreeBSD, OpenBSD, Debian, Ubuntu, RedHat, CentOS, and even obscure
Unix-like academic projects. 100% coverage. Not 99%. Not 50%. Exactly 100%.
If we can't guarantee 100% adoption without putting libsodium in the core,
given the current political climate1 and the history of unlawful
cryptography export restriction enforcement2, I'd fear that OSes
(especially Enterprise Linux distributions that hold government contracts)
could be pressured against offering secure cryptography (i.e. libsodium) in
future versions of PHP. If we make it a core extension, it's included
unless you go out of the way to compile PHP without it. This means better
security by default.
Let's be clear: Libsodium one of the highest regarded libraries that
exposes very well-studied cryptography primitives (RFC 7748, RFC 8032, RFC
7693, etc.) with a misuse-resistant interface. It's also extremely
permissively licensed (ISC).
If Frank Denis were to get hit by a bus tomorrow, anyone could pick it up
and continue his work. I wouldn't advise blindly trusting anyone who forks
it, but the cryptography community would likely certainly come together and
suggest which fork is most trustworthy. If nothing else, you could count on
the cryptographers whose work is bundled in libsodium to recommend a fork.
The bus factor, while a legitimate concern, isn't going to be a source of
liability for libsodium nor for PHP.
With respect,
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com/
In my previous email, there should have been an additional linebreak before:
Furthermore, I'd like to raise an additional point.
Sorry if that hurt readability.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com
On Mon, Jan 30, 2017 at 7:40 PM, Scott Arciszewski scott@paragonie.com
wrote:
Hi,
On Wed, Jan 11, 2017 at 6:22 PM, Scott Arciszewski scott@paragonie.com
wrote:Hi all,
I'm resurrecting my RFC to add libsodium as a core extension to PHP 7.2.
I'm still not sure why it needs to be in the core. As I said before,
there are lots of healthy extension that are not in the core and it
certainly doesn't make them less used (e.g. redis, xdebug or mongo driver).
At the end it's all about packaging...I think libsodium has lots of really good features and it's a very nice
lib. However what makes me a bit uneasy about libsodium is that it's
basically a one dev library which is even clearly visible in here:https://github.com/jedisct1/libsodium/graphs/contributors
It is certainly a bit more risky to support such lib if it all depends on
on one person rather than a team of developers. I'm not saying that it's
the same but mcrypt used to be also just one developer lib...Cheers
Jakub
I erroneously replied off-list, and rather than forward messages that
were sent directly to me (on the offchance that they were not intended to
be public), I'll just reiterate what I said privately. From my original
email:
I thought that it might have been meant to be sent publicly before so will
reply publicly again :)
Was mcrypt in core?
Yes and it was a mistake IMO (however it might have been a good idea at the
time it was added as I have no idea how it was with out of core extensions
at that time...)
Is openssl still in core?
Yes but in this case we need to consider also the TLS part that is linked
and required by other core (stream) parts so there is actually important
point to have it in the core.
If the answer to both these questions is "Yes", then it follows that
libsodium should be in the core. Especially if everyone agrees that it
should be included by default.
No it does not follow. Both extensions were added long time ago probably
for various reasons valid at that time but currently there is no need to
add new extension unless there is a some technical reason why it should be
in the core (e.g. dependency of other extension or some direct hooking to
the core parts).
However what makes me a bit uneasy about libsodium is that it's
basically a one dev library which is even clearly visible in here:You're looking at it all wrong. Look here instead:
https://github.com/jedisct1/libsodium/blob/master/AUTHORSThe person who checked the code into Github may have been Frank Denis
for a lot of cases, but the code itself was written by cryptographers.Calling it "basically a one dev library" sounds simultaneously
dismissive and misinformed. (Also: There have been 58 contributors besides
Frank, which doesn't lead to your point at all.)
I'm aware that the algorithms are taken from the public domain
implementations done by cryptographers and there are some other
contributions. What I mean by one dev lib is that there is just one
developer that maintains it which means for example regularly commit to the
extension, handles security issues and doing releases of the lib (I should
have maybe said one maintainer lib). Basically what I want to say is what
happens if Frank is not able to continue development of the library for
some reason. That raises chance that the library might become not
maintained which is more probable than with a team of developers
maintaining the lib.
Do you know any cryptography experts? Go ask them, "What would you
rather see devs use? OpenSSL or libsodium?" and report back what they say.
To be clear: I'm fairly confident that a large majority will not choose
OpenSSL.
There is nothing that should prevent anyone to use LIbsodium if it's not in
the core. You can see examples of the other popular extensions that are not
in the core and are used heavily.
Furthermore, I'd like to raise an additional point.
PHP Archive signing currently has the following options:
- A hash function (forgery = trivial)
- OpenSSL signing (which I believe means RSA-PKCSv1.5 with SHA1; Daniel
Bleichenbacher had something to say about that in 2006, but e=65537 breaks
the public exploit)Putting libsodium in core allows us to add Ed25519 signatures to Phars,
which means that we can provide a reasonable level (128 bits is what I call
reasonable) of assurance that the PHP archive is authentic (assuming you
have a trustworthy public key).
So finally some technical reason why it would be useful to have it in the
core. :) It would be really good to add this and possible some other use
cases (if you can come up with) to the RFC for example as a future scope.
Without putting libsodium in core, can we do that? If not, that's a solid
motivation to vote YES on this RFC.Conversely, let's discuss a hypothetical: If this motion is abandoned, can
you (or, rather, everyone on this mailing list working together) guarantee
that 100% of operating systems will bundle libsodium and the PHP extension
in PECL with PHP 7.2 out-of-the-box, by default? That includes Windows,
FreeBSD, OpenBSD, Debian, Ubuntu, RedHat, CentOS, and even obscure
Unix-like academic projects. 100% coverage. Not 99%. Not 50%. Exactly 100%.
Ok I see another point which is improving adoption of libsodium in the
distros. Basically sending a signal that we want to have it packaged which
is another thing that could be added to the RFC to make a bit more clear.
I'm not 100% sure if it's something that PHP should do but it's a good
point anyway.
If we can't guarantee 100% adoption without putting libsodium in the core,
given the current political climate1 and the history of unlawful
cryptography export restriction enforcement[2], I'd fear that OSes
(especially Enterprise Linux distributions that hold government contracts)
could be pressured against offering secure cryptography (i.e. libsodium) in
future versions of PHP. If we make it a core extension, it's included
unless you go out of the way to compile PHP without it. This means better
security by default.Let's be clear: Libsodium one of the highest regarded libraries that
exposes very well-studied cryptography primitives (RFC 7748, RFC 8032, RFC
7693, etc.) with a misuse-resistant interface. It's also extremely
permissively licensed (ISC).If Frank Denis were to get hit by a bus tomorrow, anyone could pick it up
and continue his work. I wouldn't advise blindly trusting anyone who forks
it, but the cryptography community would likely certainly come together and
suggest which fork is most trustworthy. If nothing else, you could count on
the cryptographers whose work is bundled in libsodium to recommend a fork.
The bus factor, while a legitimate concern, isn't going to be a source of
liability for libsodium nor for PHP.www.cnet.com/news/trump-apple-boycott-terrorist-iphone-san-bernardino-fbi/
[2]: https://en.wikipedia.org/wiki/Bernstein_v._United_States
Thanks for bringing up some good points!
Cheers
Jakub
On Mon, Jan 30, 2017 at 7:40 PM, Scott Arciszewski scott@paragonie.com
wrote:Hi,
On Wed, Jan 11, 2017 at 6:22 PM, Scott Arciszewski scott@paragonie.com
wrote:Hi all,
I'm resurrecting my RFC to add libsodium as a core extension to PHP 7.2.
I'm still not sure why it needs to be in the core. As I said before,
there are lots of healthy extension that are not in the core and it
certainly doesn't make them less used (e.g. redis, xdebug or mongo driver).
At the end it's all about packaging...I think libsodium has lots of really good features and it's a very nice
lib. However what makes me a bit uneasy about libsodium is that it's
basically a one dev library which is even clearly visible in here:https://github.com/jedisct1/libsodium/graphs/contributors
It is certainly a bit more risky to support such lib if it all depends
on on one person rather than a team of developers. I'm not saying that it's
the same but mcrypt used to be also just one developer lib...Cheers
Jakub
I erroneously replied off-list, and rather than forward messages that
were sent directly to me (on the offchance that they were not intended to
be public), I'll just reiterate what I said privately. From my original
email:I thought that it might have been meant to be sent publicly before so will
reply publicly again :)Was mcrypt in core?
Yes and it was a mistake IMO (however it might have been a good idea at
the time it was added as I have no idea how it was with out of core
extensions at that time...)Is openssl still in core?
Yes but in this case we need to consider also the TLS part that is linked
and required by other core (stream) parts so there is actually important
point to have it in the core.If the answer to both these questions is "Yes", then it follows that
libsodium should be in the core. Especially if everyone agrees that it
should be included by default.No it does not follow. Both extensions were added long time ago probably
for various reasons valid at that time but currently there is no need to
add new extension unless there is a some technical reason why it should be
in the core (e.g. dependency of other extension or some direct hooking to
the core parts).However what makes me a bit uneasy about libsodium is that it's
basically a one dev library which is even clearly visible in here:You're looking at it all wrong. Look here instead:
https://github.com/jedisct1/libsodium/blob/master/AUTHORSThe person who checked the code into Github may have been Frank Denis
for a lot of cases, but the code itself was written by cryptographers.Calling it "basically a one dev library" sounds simultaneously
dismissive and misinformed. (Also: There have been 58 contributors besides
Frank, which doesn't lead to your point at all.)I'm aware that the algorithms are taken from the public domain
implementations done by cryptographers and there are some other
contributions. What I mean by one dev lib is that there is just one
developer that maintains it which means for example regularly commit to the
extension, handles security issues and doing releases of the lib (I should
have maybe said one maintainer lib). Basically what I want to say is what
happens if Frank is not able to continue development of the library for
some reason. That raises chance that the library might become not
maintained which is more probable than with a team of developers
maintaining the lib.Do you know any cryptography experts? Go ask them, "What would you
rather see devs use? OpenSSL or libsodium?" and report back what they say.
To be clear: I'm fairly confident that a large majority will not choose
OpenSSL.There is nothing that should prevent anyone to use LIbsodium if it's not
in the core. You can see examples of the other popular extensions that are
not in the core and are used heavily.Furthermore, I'd like to raise an additional point.
PHP Archive signing currently has the following options:
- A hash function (forgery = trivial)
- OpenSSL signing (which I believe means RSA-PKCSv1.5 with SHA1; Daniel
Bleichenbacher had something to say about that in 2006, but e=65537 breaks
the public exploit)Putting libsodium in core allows us to add Ed25519 signatures to Phars,
which means that we can provide a reasonable level (128 bits is what I call
reasonable) of assurance that the PHP archive is authentic (assuming you
have a trustworthy public key).So finally some technical reason why it would be useful to have it in the
core. :) It would be really good to add this and possible some other use
cases (if you can come up with) to the RFC for example as a future scope.Without putting libsodium in core, can we do that? If not, that's a solid
motivation to vote YES on this RFC.Conversely, let's discuss a hypothetical: If this motion is abandoned,
can you (or, rather, everyone on this mailing list working together)
guarantee that 100% of operating systems will bundle libsodium and the PHP
extension in PECL with PHP 7.2 out-of-the-box, by default? That includes
Windows, FreeBSD, OpenBSD, Debian, Ubuntu, RedHat, CentOS, and even obscure
Unix-like academic projects. 100% coverage. Not 99%. Not 50%. Exactly 100%.Ok I see another point which is improving adoption of libsodium in the
distros. Basically sending a signal that we want to have it packaged which
is another thing that could be added to the RFC to make a bit more clear.
I'm not 100% sure if it's something that PHP should do but it's a good
point anyway.If we can't guarantee 100% adoption without putting libsodium in the
core, given the current political climate1 and the history of unlawful
cryptography export restriction enforcement[2], I'd fear that OSes
(especially Enterprise Linux distributions that hold government contracts)
could be pressured against offering secure cryptography (i.e. libsodium) in
future versions of PHP. If we make it a core extension, it's included
unless you go out of the way to compile PHP without it. This means better
security by default.Let's be clear: Libsodium one of the highest regarded libraries that
exposes very well-studied cryptography primitives (RFC 7748, RFC 8032, RFC
7693, etc.) with a misuse-resistant interface. It's also extremely
permissively licensed (ISC).If Frank Denis were to get hit by a bus tomorrow, anyone could pick it up
and continue his work. I wouldn't advise blindly trusting anyone who forks
it, but the cryptography community would likely certainly come together and
suggest which fork is most trustworthy. If nothing else, you could count on
the cryptographers whose work is bundled in libsodium to recommend a fork.
The bus factor, while a legitimate concern, isn't going to be a source of
liability for libsodium nor for PHP.cnet.com/news/trump-apple-boycott-terrorist-iphone-san-bernardino-fbi/
[2]: https://en.wikipedia.org/wiki/Bernstein_v._United_StatesThanks for bringing up some good points!
Cheers
Jakub
I will update the RFC as suggested.
Thank you!
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com/