After looking at BitCoin and Ethereum a Software Engineer took a peek at the Solana source code.
In the previous blog post I mentioned that I do not like seeing cryptography strength being dropped from 256 bits down to 160 bits in BitCoin and Ethereum. I was reasonably excited to look at the newer coin, based on a different curve. And written in Rust! Enter Solana.
What do you expect Ed25519 library to do with your carefully prepared 256 bits of total randomness? Something smart, no doubt. Yet the first thing it does is overwrites 3 out of those bits. It resets 2 and sets one bit at the very start, ignoring whatever values were there before. Meaning it drops the strength by the factor of 8 down to 253 bits. Well, that's how the curve is designed. Great start.
One of the scourges of Software Engineering is the NIH (Not Invented Here) syndrome. It is when smart engineers start to reinvent basic things, like writing their own HTTP client or a logging framework. And a great indicator of this syndrome is avoiding common names and patterns. If you are reading this, it means you know very well what Public and Private keys are. You will not find any in the Ed25519 library. Instead be ready to deal with a Signing Key and a Verifying Key instead. While the names may make more sense, it is a huge red flag when the core developer of the library (yes, it is just one person) has a tendency to use custom names for basic things.
But there is more. The Solana devs failed to isolate underlying library from their API, so when the cryptographer published a new version, their API suddenly broke down. Their solution was not to upgrade to a newer version. Instead, they forked the old version Ed25519 library and asked the core developer to fix it. The core developer refused, claiming the old version has an unfixable security vulnerability. So they started to update their fork on their own. And that is exactly what Solana coin is based on - a non-cryptographers' patched fork of an old vulnerable version of a cryptography library, developed by a person with a strong NIH syndrome.
Of course it does not end here. One of my gripes with BitCoin was its dropping down to 160 bits in the hash function. But at least it was double-hashed 160 bits. And then I was upset with Ethereum for repeating the 160 bits problem, but making it slightly worse by only single-hashing it. Solana devs upped the game even further. They decided to not hash anything at all. The y coordinate of the point of interest on the curve IS the public key.
This means that if you want to crack a Solana address, you can avoid doing any modular inversion. All you have to do, is generate a random point and keep adding the Generator Point (called "Base Point", because of NIH) to it in projective coordinates. You never have to convert those back to regular coordinates (which is a division by Z and requires modular inversion). Instead you just multiply target's X coordinate by Z or Y coordinate by T and compare. Multiplication is way faster than division, that is the main reason asymmetric cryptography is asymmetric.
And the final strike of genius that is Solana, is that they are in love with mono-repo. They put all their smart contracts and user interfaces and command line utilities all in the same repository. Except for the thing that matters - the underlying Ed25519 cryptography library sits in its own tiny sad separate repository.
Luckily, the starting point for all of the cyrpto cois - BitCoin - has strong enough cryptography that even all of that hackery above did not break it completely. Or maybe it did, Solana was "hacked" multiple times already.
I am not advocating for or against cryptocurrencies. But as a Software Engineer I would love the underlying codebase to be quite a bit more robust.