4 ms·

Curve25519 in pure PHP? Yikes. Have you done any measurements to verify that the implementation is constant time? https://github.com/paragonie/sodium_compat/tr

by 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. :)
  - exDM69 10y ago
    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.
CiPHPerCoder 10y ago
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".
- CiPHPerCoder 10y ago
  I forgot to include a link to said research! https://research.kudelskisecurity.com/2017/01/16/when-constant-time-source-may-not-save-you/ https://research.kudelskisecurity.com/2017/01/16/when-consta...

by zx2c4 10y ago

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

CiPHPerCoder 10y ago

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".

CiPHPerCoder 10y ago
I forgot to include a link to said research! https://research.kudelskisecurity.com/2017/01/16/when-constant-time-source-may-not-save-you/ https://research.kudelskisecurity.com/2017/01/16/when-consta...