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:
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.
Last month, Thomas Ptacek wrote API Tokens: A Tedious Survey on the fly.io blog, which talks about all things API Token.
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:
Out of these criticisms, the first two are actionable and warrant further inspection, while the latter are Thomas's opinion.
This resulted in two types of PASETO token being defined for each version of the protocol:
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:
PASETO was designed with the philosophy of avoiding in-band negotiation, as well as recognizing that any cryptography key should always be considered to be the raw key material alongside its parameter choices. To that end, PASETO was built with versioned protocols at its foundation (and each key could only be used with a given version and purpose).
Today, we announce the next iteration of the PASETO specification, which includes two new protocols (Version 3 and Version 4).
v3.local) use AES-256-CTR + HMAC-SHA384 (Encrypt-then-MAC)
v3.public) use ECDSA over NIST P-384
v4.local) use XChaCha20 + BLAKE2b-MAC (Encrypt-then-MAC)
v4.public) use Ed25519.
Security teams will mostly be interested in the Rationale page in the PASETO Specification repository. Pay special attention to the section on ECDSA security and questions for security auditors.
Ristretto is a technique for constructing prime order elliptic curve groups with non-malleable encodings. It extends Mike Hamburg's Decaf approach to cofactor elimination to support cofactor-8 curves such as Curve25519.
Ristretto255 is Ristretto defined over Curve25519, which allows cryptographers to extend the Ed25519 signature scheme to support complex zero-knowledge proof protocols without having to deal with the cofactor.
(The cofactor in Ed25519 is what caused the multi-spend vulnerability in CryptoNote cryptocurrencies (n.b. Monero).)
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.
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.