
Show HN: Sodium_compat, a Pure PHP implementation of libsodium - CiPHPerCoder
https://github.com/paragonie/sodium_compat
======
orbifold
Why? I thought the entire point of libsodium was to provide an expert
implementation of cryptographic primitives with a simple API. In particular it
is designed to be resistant to timing attacks, at least this property seems to
be much harder to guarantee with PHP.

~~~
CiPHPerCoder
Some background reading for deeply interested parties:

[https://www.sitepoint.com/what-would-you-pay-to-
make-27-of-t...](https://www.sitepoint.com/what-would-you-pay-to-make-27-of-
the-web-more-secure/)

[https://paragonie.com/blog/2017/01/let-s-make-2017-year-
simp...](https://paragonie.com/blog/2017/01/let-s-make-2017-year-simply-
secure-php-cryptography)

The short answer is "compatibility, and so we can get Ed25519-signed updates
into e.g. WordPress".

Important to note: If you have the libsodium PHP extension installed, then
ParagonIE_Sodium_Compat::foo() will proxy to \Sodium\foo() instead of using
our implementation.

Installing the PHP extension gets you timing-safe guarantees AND better
performance. I hope that's enough of a bargaining chip to get the extension
installed everywhere (and to drive the initiative to make libsodium a core
extension in PHP 7.2).
[https://externals.io/thread/626](https://externals.io/thread/626)

------
zx2c4
Curve25519 in pure PHP? Yikes. Have you done any measurements to verify that
the implementation is constant time?

[https://github.com/paragonie/sodium_compat/tree/master/src/C...](https://github.com/paragonie/sodium_compat/tree/master/src/Core/Curve25519)

~~~
exDM69
Yikes indeed. Implementing crypto primitives in an interpreted language is
full of hazards for side channel attacks - being constant time is just the
first step. Cache behavior, branch predictor attacks, etc are also important.
And all of the above applies to native code crypto too. When you add an
interpreter on top, a ton of new side channels are introduced.

The author (see links elsewhere ITT) seems pretty knowledgeable about basic
side channels but I'm still extremely wary about this. The motivation for this
project seems to be "not every PHP programmer can install native libs on their
$5 hosting platform", which IMO is a pretty poor justification for a new
crypto library. Feel free to disagree on this.

Good thing is that this library will use native libsodium if available, so
hopefully the impact of side channels in this isn't that great.

~~~
CiPHPerCoder
> Implementing crypto primitives in an interpreted language is full of hazards
> for side channel attacks - being constant time is just the first step. Cache
> behavior, branch predictor attacks, etc are also important. And all of the
> above applies to native code crypto too. When you add an interpreter on top,
> a ton of new side channels are introduced.

These are the sort of things I'm hoping can be addressed in the planned third-
party audit:
[https://github.com/paragonie/sodium_compat/issues/8](https://github.com/paragonie/sodium_compat/issues/8)

If it turns out that this project is helplessly insecure and there's no way to
make it reasonably secure, I'm never tagging v1.0.0. Dead stop.

> The motivation for this project seems to be "not every PHP programmer can
> install native libs on their $5 hosting platform", which IMO is a pretty
> poor justification for a new crypto library. Feel free to disagree on this.

I'm specifically more concerned with the second-order effect of what you've
described; namely, PHP projects can't require ext/libsodium because they can't
expect everyone to easily install it.

I want to get everyone off mcrypt, unauthenticated AES-CBC, RSA encryption
with PKCS1v1.5 padding, etc. I'd like to get Ed25519 signature verification
built into automatic updates throughout the entire ecosystem. Sodium_compat
was the only reasonable strategy to accomplish these goals, given real-world
constraints.

> Good thing is that this library will use native libsodium if available, so
> hopefully the impact of side channels in this isn't that great.

I'm hoping there aren't any, but if there are, that installing the PHP
extension mitigates them entirely. It'll make it easier to convince $5 hosting
platforms to install the extension. :)

~~~
exDM69
You seem to have taken a "lesser of two evils" approach and that's probably a
good idea. Side channels are not as bad as completely broken crypto, as long
as the critical infrastructure (api.wordpress.com, etc) is good. If someone's
private wordpress hosting gets knocked it's not a big deal but if the private
keys of wordpress.com leaks through side channels it spells trouble for
everyone.

In the ideal world, this project wouldn't need to exists but it's not the
world we live in.

> I'm specifically more concerned with the second-order effect of what you've
> described; namely, PHP projects can't require ext/libsodium because they
> can't expect everyone to easily install it.

This is just a sad state of affairs.

> If it turns out that this project is helplessly insecure and there's no way
> to make it reasonably secure, I'm never tagging v1.0.0. Dead stop.

This is straight and honest.

------
Mojah
This implementation will hopefully also make it in WordPress core for signed
updates: [https://ma.ttias.be/wordpress-get-secure-cryptographic-
updat...](https://ma.ttias.be/wordpress-get-secure-cryptographic-updates/)

~~~
rmccue
Here's the ticket:
[https://core.trac.wordpress.org/ticket/39309](https://core.trac.wordpress.org/ticket/39309)

There's a bunch of still to overcome still, but I'm hopeful!

