Since our inception, we've typically published retrospective blog posts every year:
A recurring theme of these posts has been, "We have an ambitious plan to make the Internet more secure."
At the end of 2015 looking towards 2016, we wanted to emphasize "secure-by-default" as the best attitude towards security.
Our goal for 2017 was to get libsodium into the PHP core (which we did! The vote passed 37 to 0) and write a pure-PHP polyfill library we call sodium_compat.
Our goal in 2018 was to kickstart an ecosystem-wide clean-up effort to address the discoverability problem: It's much easier for new PHP developers to discover bad security advice than good security advice. We wanted to flip the script on this problem and make new developers learn tools and techniques that are, at a base, far more conducive to developing secure applications.
This was somehow even more ambitious than our 2017 goal, and unsurprisingly, we didn't have the same measure of success this time around. But the campaign is still young, and may take several years to play out in full, and we believe a recent announcement from another organization shines a light of hope on our efforts. More on that in a minute.
The Year 2019 Will Be a Game-Changer for PHP Security
PHP 5 has reached End-of-Life
According to the list of supported PHP versions, PHP 5 has reached the end of its life. After PHP 5.6.40 is released, it will no longer receive security fixes from the PHP team.
There are a lot of advantages to PHP 7, and we've previously committed to generally only supporting PHP 7 for non-polyfill libraries.
In particular, PHP 7.2 brings you the Sodium cryptography library as a standard library, and removes the dangerous and abandoned mcrypt extension. PHP 7.2 is also currently the minimum version of PHP with active non-security support from the PHP team.
WordPress Commits to Requiring PHP 7 at the End of 2019
According to Jenny Wong at WordCamp US, WordPress is committed to dropping PHP 5 support by the end of 2019. She also says that the team could aim for a minimum of PHP 7.2 by the end of 2019.
In an effort to help plugin developers migrate any of their cryptography features to use the new Sodium extension in PHP 7.2, we've opened a new WordPress ticket to add sodium_compat to WordPress that we hope will land in time for the 5.1 release.
In addition to allowing WordPress plugin developers immediate access to the new sodium_ functions even when their plugin is deployed on older versions of PHP, it also removes a huge obstacle towards adding Ed25519 signatures to WordPress's automatic update mechanism.
Paragon Initiative Enterprises to Bring Modern Cryptography to Everyone
In addition to our efforts to make WordPress 5.1 expose secure cryptography to the millions of WordPress users (regardless of their PHP version), sodium_compat has landed in a few other projects recently.
- Joomla since 3.8.0 has supported libsodium through sodium_compat.
- Magento Open Source 2.3.0 released last month with PHP 7.2 support, and also uses sodium_compat to polyfill these feature for projects installed on versions of PHP older than 7.2.
With WordPress expected to adopt sodium_compat, this means that modern cryptography (Curve25519, XSalsa20-Poly1305, etc.) will soon be available to two thirds of the installed content management systems* on the Internet, according to W3Techs's statistics.
We expect this trend to continue, and for the application-layer encryption used by most PHP frameworks to drastically improve in 2019 either through supporting ext/sodium and requiring PHP 7.2 or higher... or through our polyfill library.
* This figure is equivalent to roughly 37% of the websites on the Internet, at the time of this writing.
Towards the Standardization of an Extended-Nonce AEAD Cipher
Last year, we proposed a draft Internet Standard to the Crypto Forum Research Group (CFRG), the part of the Internet Engineering Task Force (IETF) dedicated to evaluating and recommending cryptographic functions for new protocols, to standardize XChaCha20 and an AEAD mode that combines XChaCha20 with the Poly1305 one-time authentication function.
XChaCha20 is an eXtended-nonce variant of ChaCha20, which uses another function called HChaCha20 to derive a subkey from the key and the first 128 bits of the 192-bit extended nonce, then uses ChaCha20 with the subkey and remainder of the nonce to encrypt messages.
You can read the XChaCha20 RFC draft online.
After an adoption call that received an overwhelmingly positive response, our RFC draft was accepted as a CFRG work item.
In the near future, XChaCha20 and AEAD_XCHACHA20_POLY1305 will become Internet Standards with a formal RFC number attached to them. Once this happens, libsodium's crypto_aead_encrypt() and crypto_aead_decrypt() will use XChaCha20-Poly1305. Assuming the IETF moves at a reasonable speed, this libsodium update should soon follow, and the updated sodium API should be safe to land in PHP 7.4.
Our work on making XChaCha20 an Internet Standard also opens the door to future RFCs for WireGuard and PASETO. The consequences of this work will extend far beyond the PHP ecosystem, and the Internet will be much more secure for it.
Projects We Intend to Launch in 2019
A lot of the security game changers we outlined above are either already in motion or do not directly involve our company. So you might be wondering, "What's PIE doing this year?"
Searchable Encryption for your ORMs: CipherSweet Integrations
In 2017, we wrote a blog post about searchable encryption, which also got syndicated by SitePoint.
What might not have gotten as much air time is that we actually implemented our design as a standalone library we call CipherSweet.
We spent a lot of time on fleshing out the threat model and exact security properties of CipherSweet's design. It should now be almost trivial to implement it securely in any PHP software that uses a relational database.
This year, we're going to be building integrations with Object-Relational Mappers, such as Doctrine and Eloquent, which should immediately make CipherSweet more accessible to Symfony and Laravel developers.
Why "CipherSweet"?
It was originally designed to be integrated into SuiteCRM, and Scott often relies on puns for naming new projects.
Sodium-JVM: Sodium_Compat for the Java Ecosystem
To not too fine a point on it, we're planning on doing to Java what we already did to PHP.
Re-implementing libsodium in pure Java (hence, Sodium-JVM) is a massive undertaking, but it offers a lot of nice benefits over the existing Java bindings.
Sodium-JVM will be portable. You can use the same classes and code on Java servers that you use on desktop software or Android devices. Other languages with runtimes written in Java will also be able to seamlessly bind to the same common codebase.
The existing bindings just wrap the library written in C. Like with the PHP polyfill, we would want to use libsodium proper if it's available.
Enterprise Support Contracts
This isn't really something conceptually new; we've always offered enterprise support contracts for our open source software.
What is new, however, is that we launched a new portal for streamlining the process.
If you're stuck on PHP 5 because your systems are married to a Long-Term Support version of an Enterprise Linux, and you were using any of our open source libraries to improve your company's website security, you'll probably rest easier at night knowing that your company has a support contract with ours that ensures any bugs that only affect the PHP 5-compatible versions of our software will be fixed.
Clients with existing support contracts will not need to take any action at this time. (You should have already received an email from us explaining this change.)