SoylentNews is people
SoylentNews
from the we're-not-really-just-procrastinating-honest! dept.
The Register covers the difficulty of putting SHA-1 crypto algorithm to bed:
The road towards phasing out the ageing SHA-1 crypto hash function is likely to be littered with potholes, security experts warn.
SHA-1 is a hashing (one-way) function that converts information into a shortened "message digest", from which it is impossible to recover the original information. This hashing technique is used in digital signatures, verifying that the contents of software downloads have not been tampered with, and many other cryptographic applications.
The ageing SHA-1 protocol – published in 1995 – is showing its age and is no longer safe from Collision Attacks, a situation where two different blocks of input data throw up the same output hash. This is terminal for a hashing protocol, because it paves the way for hackers to offer manipulated content that carries the same hash value as pukka packets of data.
Certificate bodies and others are beginning to move on from SHA-1 to its replacement, SHA-2. Microsoft announced its intent to deprecate SHA-1 in Nov 2013. More recently, Google joined the push with a decision to make changes in he latest version of its browser, Chrome version 42, so that SHA-1 certificates are flagged up as potentially insecure.
Just updating to SHA-2 is not as simple as it might seem, because of compatibility issues with Android and Windows XP. More specifically, Android before 2.3 and XP before SP3 are incompatible with the change (a fuller compatibility matrix maintained by digital certificate firm GlobalSign can be found here).
(Score: 3, Informative) by draconx on Friday May 01 2015, @06:27PM
Strictly speaking, what you describe in the first sentence is a called finding a preimage, which is different from finding a collision. A collision is simply two different inputs that hash to the same value (importantly: it does not matter what the colliding hash value is).
We want cryptographic hash functions to have three desirable properties:
Note that collisions resistance is strictly a stronger condition than second preimage resistance: if your hash is collision resistant, then it is also second preimage resistant. But the reverse is not necessarily true.
By "infeasible" we mean "you should not be able to do better than guessing randomly", which for the first two (preimage and second preimage) means we expect to test about as many inputs as there are hash values (2**n for an n-bit hash). For collisions, due to the birthday "paradox", we expect to test about as many inputs as the square root of the number of hash values (2**(n/2) for an n-bit hash).
Not all uses of hash functions require collision resistance (for example, the security of HMAC does not depend on collision resistance). The main application where collision resistance is important is digital signatures.
We consider SHA-1 to no longer be collision resistant because there are known techniques to produce a collision in significantly less than 2**80 steps. However, as far as I know nobody has actually found two colliding inputs for SHA-1 yet (and told us about them).
I don't think there are any known preimage or second preimage attacks on SHA-1.