April 19, 2024 by P.I.E. Staff

Several years ago, we designed sodium_compat: a pure-PHP implementation of (most of) libsodium. It has since been installed over 60 million times, not counting WordPress.

Our goals with sodium_compat were as follows:

1. Ensure ease-of-adoption for ext-sodium. By providing a permissively licensed open source PHP library that implements the same algorithms, other open source projects could move faster to libsodium proper, even if their users were on shared hosting environments where they couldn't install PHP extensions from PECL.
2. Get adopted by software that supported old versions of PHP. Specifically, 5.2.4, which WordPress still supported at the time. Due to WordPress's enormous footprint on the Internet, this was not a lightly taken decision.
3. Work even on 32-bit platforms. It turns out, PHP gives you signed 32-bit integers on 32-bit platforms (or on Windows before PHP 7), and if you reach a value out of the range of those integers, your numbers are "conveniently" converted to a float instead. This is a nightmare when you're implementing cryptography.
4. Get out of your way. If you install ext-sodium, our APIs will defer all cryptography to the proper implementation. This was a core tenet of sodium_compat's design.

To repeat ourselves a bit, this was several years ago. The PHP community has evolved. WordPress now requires PHP 7.0 to function (although they do recommend 7.4). As of this writing, the oldest still-supported version of PHP is 8.2 (8.1 if you count "security fixes only"). We asked ourselves, and the /r/PHP subreddit, if anyone still even needs PHP 5 support in 2024.

The answer was a resounding, "No."

That's the background story, anyway. If you're a busy developer, the remainder of this post will be broken down into a Q&A format to explain what's changing, what's not changing, what you need to do, and whether you need to do anything.

Continue Reading this Blog Post »

June 8, 2022 by P.I.E. Staff

Since our company's inception in 2015, we've sought to make the Internet more secure for everyone.

Up front, this required doing a lot of the sort of work that benefits society but most companies wouldn't invest time or money in:

• Creating and maintaining open source libraries
• Updating tutorials, sample code, and other developer documentation to promote security best practices
• Designing new APIs and cryptographic protocols to replace error-prone standards

So why did we?

We reasoned that, in the long term, simply doing important work that benefits everyone is cheaper than airtime when it comes to advertising a security consulting company.

(And we were right! Our clients have been keeping us very busy. Hence, the drop in update frequency for our company blog for the past few years.)

However, we didn't get a lot of practice with marketing or advertising, which means some of the important work we've done over the years went unnoticed. For example: Sigstore does 2/3 of what Gossamer does, but the Sigstore team hadn't heard about it until a recent Hacker News thread.

To correct this oversight, we thought it would be helpful to provide a recap of some of the projects we've worked on since our inception that are still active today, and most importantly, why they matter for the security of the Internet.

Continue Reading this Blog Post »

January 24, 2022 by P.I.E. Staff

To assert that "There exist supply-chain security risks" in any software ecosystem doesn't require a formal analysis nor multiple experts to peer review such a notion. It's kind of a given, especially with recent tech news.

However, it's not a new problem. We were vocal about it in 2015, when it was common practice for software projects to tell you to install their widget by running curl http://some-domain | sh in a terminal window. This specific anti-pattern had already been criticized widely by others since at least 2013, but we were more interested in proposing a general solution to secure code delivery.

The only things that have really changed in the intervening years are:

1. More people are aware of the risks today than 7 years ago,
2. More disasters have been caused by the lack of supply-chain security for open source software, and
3. We know it's a solvable problem.

That last item might seem bold, but we've been laying the groundwork for elegantly solving these problems for the PHP ecosystem since our company's inception. We had briefly introduced our complete solution when we announced that WordPress would cryptographically sign its automatic updates in 2019. (If you'd like more depth into this subject, we've previously written about supply-chain security in 2017 and automatic security updates in 2016.)

Part of making an acceptable solution even possible required getting modern cryptography into PHP and writing a pure-PHP polyfill of ext/sodium for legacy versions of PHP. (These are just two of the things that we're known for in the PHP community.)

So with all that in mind, let's take a quick look at Gossamer, our proposal for securing the software supply-chain for the PHP ecosystem.

Continue Reading this Blog Post »

September 16, 2021 by P.I.E. Staff

Last month, Thomas Ptacek wrote API Tokens: A Tedious Survey on the fly.io blog, which talks about all things API Token.

His post covered JWT, PASETO (our design), and a few other token formats. He went on to clarify, on Hacker News, that:

The one thing I'm not super comfortable about here is my PASETO take. My attitude going in was that PASETO has a lot of boosters and not a lot of critical takes. I can beat up on Macaroons because we're using them, and I'm going to follow up with a post about what our Macaroons like like. I'm not doing that with PASETO. So, like, I stand by it, but take it for what it's worth.

What was his take, exactly? Our succinct understanding of the criticisms laid out in the fly.io article are as follows:

1. There are too many versions; the old ones should be deprecated.
2. PASETO's specification spells out how to avoid algorithm confusion for implementors.
3. Decide between symmetric and asymmetric; don't support both use-cases.
4. NIST algorithm support and CFRG involvement are unnecessary and possibly counterproductive.

Out of these criticisms, the first two are actionable and warrant further inspection, while the latter are Thomas's opinion.

Continue Reading this Blog Post »

August 3, 2021 by P.I.E. Staff

When we designed PASETO, our goal was to provide an easy-to-use, secure-by-default, and simple protocol that solves the same sort of problems as JSON Web Tokens (except actually secure).

This resulted in two types of PASETO token being defined for each version of the protocol:

1. Local tokens: Symmetric authenticated encryption
2. Public tokens: Asymmetric digital signatures

This solved the majority of use cases, but not all: If you wanted to use public-key encryption instead of symmetric-key encryption, you couldn't accomplish that with PASETO. Put flatly, there was no JWK-equivalent for PASETO.

With that in mind, today we'd like to announce the first PASETO extension:

Continue Reading this Blog Post »