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).)
Imagine that you want to build a brick wall.
However, instead of laying each brick deliberately and using mortar to assemble the desired structure, you are instead instructed to assemble a three-dimensional lattice of mortar, like so:
This might seem strange, so naturally you ask what the purpose is for such a design. You are told: "This will allow the inhabitants to hot-swap bricks whenever they need to. For example, if an influx of termites that can eat clay brick infest the area, they might want to switch to concrete bricks to protect their house."
Would you trust such a wall to support the weight of a roof?
So why do we expect cryptography designed this way to be secure?
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.
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?
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.