As stated in this forum post: https://portableapps.com/news/2019-04-15--most-secure-portable-project-g..., the packages are SHA256 sum checked.
As I understand it, SHA256 is now being recommended as insecure by the US government (fails around 41% of the time in testing), and is presenting SHA384 as a minimum.
I propose we upgrade to SHA384, SHA512 or even BLAKE3 checks to keep up with advancing security demands. b3sum hash is the same size as SHA256 to store on a hash table, but is many times faster and more secure of an algorithm. It's even faster than MD5, as I understand.
https://crates.io/crates/blake3
As always, thank you for your time and efforts.
As far as I can recall, the only issue with SHA-256 is when using it for signing specific data with a secret in which case it can be vulnerable to a length extension attack. To mitigate, slightly modifying the sign and check code can get around this with relative ease.
The hashes you're referencing aren't signing anything. We're generating an SHA-256 hash of a file to ensure the file hasn't been altered (file integrity). As far as I'm aware, an actual collision has not yet happened under SHA-256. I find no reference to the US government stating what you did unless you're referring to SHA-1.
Fun fact: Every website you visit is using SHA256 for security.
Sometimes, the impossible can become possible, if you're awesome!
on fun facts: lol I know.
https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FA...
I may be misunderstanding the document, but this is the interpretation I have and is congruent with the article/videos I found it in.
So using a better hashing function here wouldn't help in any way? If not, then what would be the point of using SHA256 over MD5? Should I be bothering with SHA512 in the descriptions?
Other fun fact: SHA256 is based on SHA1.
That document is talking about digital signatures not file hashing being future-proofed against quantum attacks. They recommend upgrading from SHA-256 for long-lived root signatures (the ones used by root authorities that handle signing the stuff that then signs our stuff) beginning next year. The rationale behind this is because these are often used for a decade or more and embedded in the OS itself. The transition from CNSA 1.0 (current recommendations) to 2.0 (the document you linked) is planned to occur sometime between 2025 and 2030.
For simple file hashing (what we're doing and publishing), there's no need to switch from SHA-256. SHA-256 collisions will happen but aren't expected for quite a while still. Once that happens, we can switch to a more robust algorithm with relative ease and speed. Upgrading now would be complete overkill for the use case especially considering that SHA-256 is what keeps the entire internet secure.
You can hash files with MD5 if your sole purpose is to ensure the user made a complete download. If you're using it to verify file integrity, SHA-256 should be used. MD5 and SHA-1 both have collisions so someone could fake a file that has the same MD5 and SHA-1 as the one intended but has malicious cargo. They can not currently do that with SHA-256 and won't be able to for some time.
Clarification: SHA-256 is a part of SHA-2, not SHA-1. SHA-2 shares roots with SHA-1 in MD5. SHA-3 is different.
Sometimes, the impossible can become possible, if you're awesome!
I hope it's fine that I'll be introducing the b3sum on the applications I've been portablizing. At least to start getting folks exposed to it.
Also, the first couple of apps I've checksummed..it actually is a LOT faster. It's almost instant. Pretty crazy.