Slashdot Mirror
New SHA Functions Boost Crypto On 64-bit Chips
An anonymous reader writes "The National Institute of Standards and Technology, guardian of America's cryptography standards, has announced a new extension to the SHA-2 hashing algorithm family that promises to boost performance on modern chips. Announced this week, two new standards — SHA-512/224 and SHA-512/256 — have been created to directly replace the SHA-224 and SHA-256 standards. They take advantage of the speed improvements inherent in SHA-512 on 64-bit processors to produce checksums more rapidly than their predecessors — but truncate them at a shorter length, reducing the overall timespan and complexity of the digest."
Further details are available from NIST (PDF).
I thought this as well - you'd think being able to compute a hash faster makes it a bit easier to compute a rainbow table with the hash.
Then again, there are many other perfectly reasonable ways you'd want the hash to be faster - for instance, how git uses the sha1 hash throughout - or any hash-summing of a file to verify the contents are unchanged.
So the 'faster hash' really only means that it might be something to consider when using it for a password hash - but for data integrity checking, it can be a real boon.
-- Sometimes you have to turn the lights off in order to see.
Cryptographic hashes for a huge number of things besides protecting passwords, which indeed they are somewhat poorly suited for.
IIRC the CRC hashes are only designed to protect against accidental changes while secure hashes are designed to protect against both accidental and malicious changes. This makes them more suited to distributed systems where not every participant is trustworthy.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Different hashes are for different purposes.
No argument there.
The CRC class of hash functions actually makes certain statistical guarantees for the longest run of possible errant bytes in source data and are extremely faster, making them far more suitable for file integrity checks.
CRC is great for packet-sized input, but not so great over larger chunks of data; also, the way its design targets burst errors means that widely separated point errors aren't as effectively caught. There's a reason Ethernet jumbo frames haven't gone much over 9000 bytes -- Ethernet's CRC-32 is much less effective at message sizes over 12000 bytes or so. Cryptographically strong hashes tend to be less sensitive to input length.
...when you're writing a game...tweak the difficulty of "Easy" to something [your mother] can cope with. -- onion2k
If anyone is interested in the source material, here it is:
http://csrc.nist.gov/publications/drafts/fips180-4/Draft-FIPS180-4_Feb2011.pdf
Fresh from the press, it seems.
By the way, the SHA-512/224, SHA-512/256, SHA-384 and SHA-512 are only different in their initial hash value, so it is very easy to implement these algorithms. Just change the constant and cut the required number of output bits. Personally, I think it is at least two hash functions too many.