Checksum 2.0, coming soon..
After "The Loss", of which we shall not speak, I didn't think I'd ever see checksum's code again.Then came AI.
A job which would have taken me a painful month or more and I wouldn't even bother starting has been reduced to a couple of days with my local AI, along with help from the odd frontier model when the local agent was busy.
In short, I can see the code again. w00h00!1
Yes decades have passed, and it still works great, but the bottom line is, I backed the loser, Blake2; politics or something got involved and SHA256 won and got baked into our actual hardware, meaning using it to hash files is FAST AF.
Replacing Blake2s with SHA256 seems like a no-brainer now, and something I've been thinking checksum should be doing, for quite a while2.
I'm a bit sad to see the cryptographically-superior (I remember thinking at the time) Blake go, but happy to shave heaps of CPU energy and time off hashing files; checksum's hash.dll, while still faster than Windows built-in bcrypt.dll (in the two algorithms they share; MD5 and SHA1), can't begin to keep up with modern hardware-accelerated computations of SHA256 (and only SHA256, btw)..
10.15GB test file:
old checksum hash64.dll (SHA1) = 13.9s (now faster than MD5 on my modern hardware ~ 16.5s)
Windows cryptutil (SHA256) = 9.5s
the new bcrypt.dll routines in checksum (SHA256) = 6.7s
Basically half. I want to insert this efficiency into the brain of checksum. And I'm working on it right now, also Open Sourcing the code, so you can have fun with it.
I have also got back simple checksum, checksum's wee brother, and he is the first to take the plunge; the SHA256 hashing is working great. There's still a few things to do yet, but expect a taster binary soon.
checksum itself will take a little longer to whip into SHA256 shape. Also I still need to wipe and upgrade the actual server all this lives on3, and also it's Summer Holidays right now and the garden has many time-sensitive needs, as do the kids, so..
Now you at least know the plan.
CHANGES:
I have given checksum the ability to understand "..\" in hash files, so now it will work with FitGirl releases! That bugged me for ages.
For now..
;o)
references:
1. Due to my stupid obfuscation of the original code in the apps, many of the de-obfuscated variable and function names are, well, sub-optimal. This will take time to remedy, if I can be bothered. A few at a time, probably.
2. I have no plans to include an --upgrade-hashes flag or separate app for Blake2s hashes. checksum is making a clean break. If I used Blake I'd verify all my own hashes, delete all .hash files, and re-hash everything with the new version, once it's ready. If you use Blake hashes, you can figure out your own strategy!
3.The new-and-improved, php8-capable corz.org is currently running on a test server as I work on it, bit-at-a-time. If you want to test it out, or have a nice agent script for this, get in touch.
2. I have no plans to include an --upgrade-hashes flag or separate app for Blake2s hashes. checksum is making a clean break. If I used Blake I'd verify all my own hashes, delete all .hash files, and re-hash everything with the new version, once it's ready. If you use Blake hashes, you can figure out your own strategy!
3.The new-and-improved, php8-capable corz.org is currently running on a test server as I work on it, bit-at-a-time. If you want to test it out, or have a nice agent script for this, get in touch.