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 job0 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, SHA-384 and SHA-512 remain pointlessly slow and currently just as secure).
Using bcrypt.dll and efficient code, we can get hashing speeds down to basically half (see inside WinCrypto.au3 for the speed tables4). I want to insert this efficiency into the brain of checksum. And I'm working on it right now, also releasing 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.
For now..
;o)
For all the latest changes, see here.
references:
0. OH FUCK NO! No way I can tell you I DE-OBFUSCATED an AutoIt app, even if it was my own app that is strictly not okay and outside license conditions and all that. How DARE I! If you had the will and a half-decent AI assistant, you could have done the very same thing! Instead you moan about bugs! Ask yourself!
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 (which you KNOW I am!). 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! An Upgrade Hashes facility for your old (read: slow and "insecure"5) hashes is in the works.
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.
4. checksum's old hash.dll can compute a SHA1 (fastest on current hardware) of a standard 10GB test file (10GB of zeros) in 12.75s, checksum 2.0 SHA256 of same file: 6.71s. BY THE WAY, in 2nd place, MD4 at 12.43s.
5. For me it's all about speed and efficiency. I don't foresee any intentional tampering with my files; it's not like I'm a target for the Chine government! Moroccan, maybe!
Faster is better.
For me it boils down to SHA256 == hardware-accelerated == less energy == good.
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 (which you KNOW I am!). 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! An Upgrade Hashes facility for your old (read: slow and "insecure"5) hashes is in the works.
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.
4. checksum's old hash.dll can compute a SHA1 (fastest on current hardware) of a standard 10GB test file (10GB of zeros) in 12.75s, checksum 2.0 SHA256 of same file: 6.71s. BY THE WAY, in 2nd place, MD4 at 12.43s.
5. For me it's all about speed and efficiency. I don't foresee any intentional tampering with my files; it's not like I'm a target for the Chine government! Moroccan, maybe!
Faster is better. For me it boils down to SHA256 == hardware-accelerated == less energy == good.