It's been more than eight years since Javascript Cryptography Considered Harmful was published.
It's just as true today as it was eight years ago that JavaScript cryptography in a web browser is dangerous. But the ecosystem itself has changed immensely in this time.
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.
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.