4 ms·

Show HN: Sodium_compat, a Pure PHP implementation of libsodium

62 points by CiPHPerCoder 10y ago

orbifold 10y ago
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 10y ago
  Some background reading for deeply interested parties: https://www.sitepoint.com/what-would-you-pay-to-make-27-of-the-web-more-secure/ https://www.sitepoint.com/what-would-you-pay-to-make-27-of-t... https://paragonie.com/blog/2017/01/let-s-make-2017-year-simply-secure-php-cryptography https://paragonie.com/blog/2017/01/let-s-make-2017-year-simp... 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
Mojah 10y ago
This implementation will hopefully also make it in WordPress core for signed updates: https://ma.ttias.be/wordpress-get-secure-cryptographic-updates/ https://ma.ttias.be/wordpress-get-secure-cryptographic-updat...
- rmccue 10y ago
  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!
zx2c4 10y ago
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/Core/Curve25519 https://github.com/paragonie/sodium_compat/tree/master/src/C...
- exDM69 10y ago
  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 10y ago
    > 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. :)

62 points by CiPHPerCoder 10y ago

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 10y ago
Some background reading for deeply interested parties: https://www.sitepoint.com/what-would-you-pay-to-make-27-of-the-web-more-secure/ https://www.sitepoint.com/what-would-you-pay-to-make-27-of-t... https://paragonie.com/blog/2017/01/let-s-make-2017-year-simply-secure-php-cryptography https://paragonie.com/blog/2017/01/let-s-make-2017-year-simp... 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

Mojah 10y ago

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

rmccue 10y ago
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!

zx2c4 10y ago

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/Core/Curve25519 https://github.com/paragonie/sodium_compat/tree/master/src/C...

exDM69 10y ago
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 10y ago
  > 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. :)