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