Add JCryptCipherSodium to support libsodium #16754
Conversation
As far as I know, sodium_compat still did not had the cryptographic review that the author was strongly asking for, right? If yes, is it wise to build our crypto stuff around it? |
It has not (it's in the readme Michael linked to). I'm also unsure (but not strongly against) on whether we just require min php 7.2 in the is_supported. We do have to be very careful about documenting that clearly as a minimum in php doc blocks etc |
I would not lock it to only PHP 7.2 since as noted there is a PECL extension offering support down to PHP 5.4 and is the predecessor for the core API that will be in 7.2. So depending on your server config, the polyfill is the only way to get support for PHP 5.3 and covers the other PHP branches if you can't install the PECL extension. We do have other system components which require PECL extensions that aren't part of the core PHP distro (Memcached and Redis for cache/session support) or depend on PEAR packages (Cache_Lite), so it's not unprecedented for us to have API components with extra dependencies. Not using the polyfill though complicates this implementation quite a bit. Two main issues come to mind. First, there would be no way to support PHP 5.3 at all (in many ways that's fair, it's a dead branch anyway, but it is part of our supported version range and thus far we don't have features in core that are only available on newer PHP versions). Second, the API between PECL and core PHP 7.2 is different (PECL uses a namespaced API whereas to put the code in core everything had to move to core PHP's naming convention), so we'd have a lot of conditionals in the class for each of the functions we're using. |
Just adding sodium_compat actually nullifies that. If you're on < 7.2, it maps |
First, let's assume there's some vulnerability in sodium_compat. What might it look like? Let's begin with the attacks that have been eliminated by its design (which is enforced via unit tests and static analysis):
There is still some attack surface that sodium_compat does not, and cannot, address:
That's the crux of what the audit scope was meant to address: Is it possible to implement completely constant-time cryptography in PHP without just writing it in C as an extension? Even if the answer is "No", in practical terms, you really only need to worry about local attackers (e.g. neighbors in cloud hosting) that can do attacks on the processor's caches (e.g. FLUSH+RELOAD). If you have a high security requirement where this exposure to an unproven hypothetical risk is not acceptable, it's easily mitigated by the following command: pecl install libsodium Whether or not it's wise to use sodium_compat is really your decision, but with this knowledge in hand, I hope whatever answer you go with is a lot clearer. |
@paragonie-scott thanks a lot for the detailed explanation, that was really helpful! @mbabker based on the feedback, I'm fine with using the polyfill. |
@@ -0,0 +1,70 @@ | |||
composer/ca-bundle | |||
================== |
zero-24
Jul 24, 2017
Member
hmm is this expected to be part of this PR? As this just include a readme + a composer.json?
hmm is this expected to be part of this PR? As this just include a readme + a composer.json?
mbabker
Jul 25, 2017
Author
Contributor
Removed. It's one of those things where my local has Composer dependencies in 4.0 but not in 3.x so it added files it wasn't supposed to (composer/ca-bundle
is a dependency of joomla/http
which we added to 4.0).
Removed. It's one of those things where my local has Composer dependencies in 4.0 but not in 3.x so it added files it wasn't supposed to (composer/ca-bundle
is a dependency of joomla/http
which we added to 4.0).
I have tested this item This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/16754. |
a2a0d53
into
joomla:staging
* staging: (274 commits) Add JCryptCipherSodium to support libsodium (joomla#16754) Performance 2 (libraries/legacy) (joomla#12220) Performance 6 (templates) (joomla#12233) Fixed typehint (joomla#16425) Fix for: Repeatable field is no longer rendered with Chosen layout (joomla#16471) Fix the path for the ajax-loader.gif (joomla#16701) Menu items list parent filter (joomla#17060) Text Filters layout (joomla#17113) mod_login showon option (joomla#17153) com_banners incorret tooltip (joomla#17157) fix joomla.content.options_default (joomla#17123) remove the never working limitstart call (joomla#17184) Update phpDocumentor build set 3.8.0 Dev State Prepare 3.7.4 Stable Release fixed a logic change in joomla#12294, thanks @Hoffi1 Update sv-SE.ini Update pt-BR.ini Update lv-LV.ini Update fa-IR.ini ...
Pull Request for Issue #13568
Summary of Changes
PHP 7.2 will be removing
ext/mcrypt
from the core distribution andext/sodium
will be added to core as a new encryption library. As theJCryptCipher
classes are primarily built aroundmcrypt
(and inherently what is present in PHP core), we should add support for the new library as well.ext/sodium
isn't restricted to PHP 7.2 installations only. There is also a PECL extension providing support for PHP 5.4 through 7.1 and the sodium_compat polyfill providing support down to PHP 5.2.4. The polyfill is included in this PR to make things usable for all of our supported environments, and the polyfill already has logic in place to support working with either the native PHP API or the PECL extension, so we can just arbitrarily call into the polyfill API without doing extra work on our own.Testing Instructions
The unit test coverage for the class best demonstrates its use:
One thing to note here. Unlike our other ciphers, a nonce must be set and used for both the encryption and decryption of data, and must be the same value on both ends of the process. Otherwise, this is no different than the existing API.
Documentation Changes Required
Document the added class and its use.
//cc @joomla/security