4 ms·
They might be alluding to some of the specific examples in our blog post. Like, mbstring.func_overload, or chr() being a great way to leak crypto keys via cache
by CiPHPerCoder 10y ago
They might be alluding to some of the specific examples in our blog post. Like, mbstring.func_overload, or chr() being a great way to leak crypto keys via cache-timing.
These sort of things aren't obvious and can very easily (and justifiably) be blamed on the language itself.
A lot of PHP crypto libraries are very cavalier about using functions without understanding their implementation details.
https://github.com/devi/Salt/blob/fde775cf52402013efce81275919dcfd9f381fba/FieldElement.php#L19 https://github.com/devi/Salt/blob/fde775cf52402013efce812759...
https://github.com/phpseclib/phpseclib/blob/ab1da5ac1f2fa60ba97d6f6f6909b0123704bc36/phpseclib/Crypt/RC4.php#L327 https://github.com/phpseclib/phpseclib/blob/ab1da5ac1f2fa60b...
https://github.com/zendframework/zend-crypt/blob/9b7da4a6d4db0bfc5c1cd0910d08b3e4af6d9cc5/src/Symmetric/Padding/Pkcs7.php#L28 https://github.com/zendframework/zend-crypt/blob/9b7da4a6d4d...
Fortunately, most cryptography libraries these days just wrap OpenSSL and rarely implement their own ciphers or hash functions.
- tyingq 10y agoHmm. Most languages have some equivalent to chr() and ord(). And clunky unicode support isn't exclusive to php.
- trebor 10y agoWhat you're saying is, it's unsafe to write a crypto library in PHP without being aware of PHP internals. Which I'd agree with, in general. Thankfully the PHP community now has a group like Paragonie willing to share implementation risks. And because of that, we can help solve the problem with pull requests to those libraries.