4 ms·
Because SHA3 is the standard, we' re going to see hardware implementations of it and a lot of research will go into its software implementation. If you care ab
by shin_lao 13y ago
Because SHA3 is the standard, we' re going to see hardware implementations of it and a lot of research will go into its software implementation.
If you care about performance, stick to the standard.
Another commenter also rightly pointed out that SHA3 implementations will be more scrutinized, and therefore more secure. Exploitable security issues lie rarely in the algorithm.
Long story short: stick to the standard.
- floody-berry 13y agoSHA-1 intrinsics are going to be out in 2015-2016. You're going to be waiting a very long time before SHA-3 intrinsics hit. If you care about software performance, you will not be using SHA-3.
- shin_lao 13y agoAccelerated SHA1 has been available for a long time, this was necessary for embedded systems. The NIST is currently modifying SHA3 to make it faster, with some controversy. You are right in the sense we will have to wait for the definitive standard to get out before we see some heavily optimized implementations. If you want immediate performance, use SHA2. If you want more "future proof" security, use SHA3 (and one could say that SHA2 is still very good in terms of security). Stick to the standard, unless you know a lot about crypto.
- cyphunk 13y ago> Long story short: stick to the standard. ahem... http://en.wikipedia.org/wiki/Dual_EC_DRBG http://en.wikipedia.org/wiki/Dual_EC_DRBG when you can no longer trust the organizations setting the standards (NIST, CFRG) this argument looses water.
- mpyne 13y agoEven there the standardization process worked: The flaw in Dual EC DRBG was pointed out very quickly, precisely because there was so much cryptanalytic attention paid to it. The fact that RSA (and only RSA, AFAICT) didn't pay attention to the crypto break in exchange for $10MM doesn't change the fact that the vulnerability had been quickly discovered. If the algorithm had been left unstandardized and was simply "Foo Corp's Custom Wonderful Bit Generator™" the public may never have known of the vulnerability, while the NSA would still have the resources to have discovered the flaw on their own and use TAO to recover the priv key.
- higherpurpose 13y agoUnfortunately, last I heard NIST was trying to weaken the default SHA3 implementation, even compared to SHA2 (give it only 64 bits of security), and not implement Keccak "as is". Keccak as is should be fine, but I wouldn't touch NIST's modified Keccak "for performance" as SHA3. Also, wouldn't we rather trust software implementations than hardware implementations post-Snowden revelations? Isn't that the same logic behind PRNGs now?
- kzrdude 13y ago64 bits of security is not true
- higherpurpose 13y agoThey planned to make it 128 bits, instead of the default 256 like for SHA256. Isn't that 64 bits of security?
- tveita 13y agoThey did not plan to make it 128 bits. The standard output sizes have always been 224/256/384/512 as specified in the competition. For an ideal secure hash function with 256-bit output it takes ~ 2^128 operations to find a collision, while most other attacks, like finding preimages, takes ~ 2^256. The sponge construction Keccak uses allows you to reduce the difficulty of finding preimages in return for increased speed, by adjusting the capacity of the sponge. The idea was to have a fixed "level of security" for each hash, based on the collision resistance, and tune the other parameters based on that. So a 256-bit output would require 2^128 operation for either a collision or a preimage attack.
- kzrdude 13y agoListed to tveita and go read the keccak papers, and you will know more! Fighting against NSA is great, but don't judge a new cryptographic hash on rumors.