WordPress's core development team began a discussion recently about the challenges involved in enabling plugin/theme developers to manage their own keys. This led to a discussion about Project Gossamer and our designs for zero-authority public key infrastructure (za-PKI).
And then WordPress.org, being halfway across the bridge, decided to make a sharp left turn and discuss rolling back the Ed25519 signature for core updates in favor of "SSL with checksums".
I do want to reiterate that I want to see package signing come to fruition, so rolling back the current implementation is primarily about clearing the way to ensure it's done properly, rather than trying to rush a half-baked solution.
(Emphasis mine.)
This development was accompanied by a blog post with a confusing title ("SSL for auto updates"), for which the biggest takeaway seems to be: Nobody understands server-side HTTP requests.
If that's the case, to any WordPress freelancers in the audience: you'll want to read this post to distinguish yourself from the majority of your peers.
WordPress 3.7 was released on October 24, 2013 and introduced an automatic update mechanism to ensure security fixes would be automatically deployed on all WordPress sites, in an effort to prevent recently-patched vulnerabilities from being massively exploited in the wild. This is widely regarded by security experts as a good idea.
However, the WordPress automatic update feature had one glaring Achilles' heel: If a criminal or nation state were to hack into the WordPress update server, they could trigger a fake automatic update to infect WordPress sites with malware.
This isn't just a theoretical concern, it could have happened if not for WordFence's security researchers finding and disclosing an easy attack vector into their infrastructure.
WordPress 5.2 was released on May 7, 2019 and provides the first real layer of defense against a compromised update infrastructures: offline digital signatures.
Recommended reading: What's a digital signature?
A lot has been written about cryptography key lengths from academics (e.g. Lenstra's equation) and various standard committees (ECRYPT-CSA, Germany's BSI, America's NIST, etc.) over the years.
Despite the abundance of coverage on this material on the Internet, these resources lack the clarity that we look for when drafting recommendations for software developers and system administrators. Additionally, many of them are showing their age and desperately need to be brought up to speed with a modern understanding of real world cryptography.
Back in 2017, we outlined the fundamentals of searchable encryption with PHP and SQL. Shortly after, we implemented this design in a library we call CipherSweet.
Our initial design constraints were as follows:
Today, we'd like to talk about some of the challenges we've encountered, as well as some of the features that have landed in CipherSweet since its inception, and how we believe they are beneficial for the adoption of usable cryptography at scale.
If you're not familiar with cryptography terms, you may find this page useful.
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.
Will tomorrow bring costly and embarrassing data breaches? Or will it bring growth, success, and peace of mind?
Our team of technology consultants have extensive knowledge and experience with application security and web/application development.
We specialize in cryptography and secure PHP development.
Want the latest from Paragon Initiative Enterprises delivered straight to your inbox? We have two newsletters to choose from.
The first mails quarterly and often showcases our behind-the-scenes projects.
The other is unscheduled and gives you a direct feed into the findings of our open source security research initiatives.