5 ms·
What should be used instead
by xiaodai 4y ago
What should be used instead
- colordrops 4y agoSHA256 is an option. It's secure enough for Bitcoin.
- acchow 4y agoProving cryptographic security by financial incentive seems to be the most useful aspect of blockchains.
- quickthrower2 4y agoSomeone that can crack cryptocurrency needs to figure out how to extract value without spooking the entire market into collapsing. That is why I think they’ll put more effort into exploiting badly written smart contracts than the underlying blockchain. Ethereum projects get hacked every day, hackers make millions, but no one loses faith. More of a gravy train. Really you need someone with a mission to crack bitcoin, not someone looking just to make money.
- paulpauper 4y agojust break into a dormant wallet or multiple old wallets . you only need just a few thousand btc to be set for life and for it to be undetected. depends on what you mean by crack.
- Vladimof 4y agobut if bitcoin/sha256 gets cracked, it isn't a big deal, because miners will probably agree to move to something better and revert bad transactions...
- quickthrower2 4y agoBitcoin is a brand not a fixed protocol (see the Bitcoin Cash fork, for example…)
- Vladimof 4y agoPretty much... Bitcoin is whatever the majority (of miners) agrees it to be... and it could change at any time.
- postalrat 4y agoSure. But how about all the addresses out there that won't move the coins to an updated address? They would stay vulnerable.
- quickthrower2 4y agoYes this relies on some foresight, to move well in time of the zero-day.
- unobatbayar 4y agoPeople seem to overestimate the security of SHA256 as compared to SHA1. Although it is definitely better than SHA1, the improvement is ever so slightly: SHA1 : ec1623b7a94ed3d8feaffaf7580df3eca4f5f5ca SHA256 : e2b0c44298fc0c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
- michaelscott 4y agoA "mere" 2^96 improvement; the security between the two is a universe apart.
- charcircuit 4y agoblake3 if you do not have to worry about compatibility with older things that do not support it
- bombcar 4y agoDoes using and verifying multiple hash functions help? If something verifies with SHA1 and MD5 is it better than just one? Of course you’d add SHA256 and BLAKE3 or whatever. I think I’ve seen Gentoo’s portage use multiple.
- charcircuit 4y ago>Does using and verifying multiple hash functions help? Technically yes, but it takes extra time to hash something twice and it will take extra storage to store 2 hashes. This trade off is not really worth it compared to just using a good hash function alone.
- ReactiveJelly 4y agoProbably whatever the libsodium team recommends. For password hashes, looks like Argon2 https://doc.libsodium.org/password_hashing https://doc.libsodium.org/password_hashing For generic data, they're still using BLAKE2b as the default, not BLAKE3. Not sure why. Too new? https://doc.libsodium.org/hashing/generic_hashing https://doc.libsodium.org/hashing/generic_hashing SHA256 and SHA512 alone are not awful, but they're slower than BLAKE3 and vulnerable to length extension. You can add extra tricks to protect them from length extension, like a length prefix or like doing SHA512/256, but it's better not to add tricks to your crypto.
- omegalulw 4y agoWhat about bcrypt?
- duskwuff 4y agoDifferent tool for a different job. bcrypt is a password hash. It's optimized to defend against brute-force attacks on a short secret string -- which means it's slow (tens to hundreds of milliseconds), and it doesn't support inputs longer than 72 bytes at all. SHA256 and the BLAKE family are designed for hashing larger bodies of data. They're fast (~5 CPU cycles per byte) and can handle an arbitrarily long input.
- shp0ngle 4y agopassword hash is not a general hash. general hashes are to be used in other crypto constructions. Or, if you really need just a quick hash (but really think if you really need it.) Password hashes are for passwords.
- charcircuit 4y ago>but they're slower than BLAKE3 It's important to know that this currently isn't true for small inputs for SHA256 when using a cpu with dedicated instructions for it.
- trinovantes 4y ago> vulnerable to length extension I think this is only relevant if you're using a hash as a MAC, in which case you should be using HMAC-SHA256 instead which is not vulnerable to length extension attacks
- tptacek 4y agoSHA2 or Blake2; they're both fine, with an edge to Blake2 on a safer interface and better software performance.
- quaffapint 4y agoPick your poison. Here's the latest results from SMhasher listing various hashing options many even much faster than Blake3. Find one that works for you and has a stable library for your language/platform. https://rurban.github.io/smhasher/doc/ryzen3.html https://rurban.github.io/smhasher/doc/ryzen3.html
- tptacek 4y agoUnsurprisingly, the really fast ones tend to be exploiting hardware intrinsics.
- oconnor663 4y agoI don't know how that benchmark figure was measured, and I think these are more informative: https://bench.cr.yp.to/results-hash.html https://bench.cr.yp.to/results-hash.html. The specific CPU and the input length both matter a lot.
- dylan604 4y agoHow long is a string? That question is just as easy to answer as the one you posed. Your question is best answered by asking more questions. What are you doing with the hash is probably the first question. Depending on the answer will go a long way to helping pick an algo that provides the most appropriate when considering security vs expense/time to hash
- Zamicol 4y agoSHA2 and SHA3.