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.
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
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.
> 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.
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. :)
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.
I'm aware of the recent curve25519-donna on 32-bit MSVC research, but PHP uses a different instruction than llmul (smull), so I'm not sure if that particular research is a concern here.
I don't have any tools to objectively measure the timing differences to detect leaks on-hand. I'm not sure if any even exist for measuring PHP software.
So, the answer to your question is "No, but open to suggestions on how to measure and possibly mitigate".
