Developer tools · SHA hash calculator
Collision, Preimage and Second Preimage: The Three Hash Security Goals
· Background
sha-256 cryptography security
An advisory says an algorithm has collision problems and you need to know whether your use is affected. This post defines the three resistance properties, shows which use cases depend on which, and applies them to SHA-1.
Is my use affected? — the question an advisory rarely answers directly
An advisory arrives saying SHA-1 has collision problems, so your system must upgrade. But what if your system uses SHA-1 only for key derivation, not for authenticating messages? What if SHA-1 is only used to deduplicate identical files, not to prove authenticity? The question "is my system affected?" cannot be answered without understanding what property of the hash function is actually broken and what property your use case depends on.
A hash function provides multiple security properties: preimage resistance, second preimage resistance and collision resistance. A break in one property does not break another, and some use cases depend only on properties that remain secure. The ToolAcre SHA hash calculator displays the algorithms and their digest widths, properties that determine the bounds for each security goal. Understanding these properties is the first step in deciding whether an advisory affects your system.
Preimage resistance — given a hash, you cannot find an input that produces it
Preimage resistance means that given a digest, it should be infeasible to find an input that produces that digest. You receive the hash of a password and want to guess the password; this is a preimage attack. Second preimage resistance means that given a message and its hash, it should be infeasible to find a different message with the same hash. You have a downloaded file and its SHA-256 checksum; an attacker wants to swap the file with a different file that has the same hash; this is a second preimage attack.
Collision resistance means that it should be infeasible to find any two different messages with the same hash. You are signing a document; an attacker wants to create a different document with the same signature; this is a collision attack. These three scenarios require different amounts of work from the attacker, and the security bounds differ. Preimage resistance is the strongest property, and it is rarely the one that is broken. Given a digest, finding a preimage requires brute force search through the space of possible inputs. The digest width affects the generic search space, but this article does not state an operation count without deriving it and defining the attack model.
Second preimage resistance — given an input, you cannot find a different input with the same hash
Second preimage resistance is the next strongest, and it is also rarely broken in isolation. Given a message and its hash, finding a different message with the same hash also requires exponential work in the digest size. Second-preimage and collision searches grant the attacker different choices, so their generic bounds are not interchangeable. The qualitative distinction is sufficient here; no numerical bound is asserted without an inline derivation. An algorithm loses second preimage resistance if there is a structural attack that does not require brute force.
Collision resistance is the weakest of the three properties, and it is the one that is most often broken or bent. A collision search lets the attacker choose both inputs, unlike the other two goals, so it has a different generic bound. This article intentionally omits birthday-bound figures and hardware timelines because deriving and sourcing them is outside the verified material.
Collision resistance — you cannot find any two inputs with the same hash, and why this is the weakest of the three
Mapping the three security properties to use cases shows which property is required for each task. Deduplication relies on the assumption that if two files have the same hash, they are the same file. This requires collision resistance: if collisions are possible, an attacker can create two different files with the same hash and break the deduplication invariant. However, this is a weak requirement, because practical collisions are extremely rare even if they are theoretically possible.
Digital signatures require collision resistance in a strong form. When a signer produces a signature for a document's hash, and a verifier later checks the signature, the two must be checking the same hash. If collisions are easy, an attacker can forge a signature for a different document by finding a collision with the signed document. This is the attack that motivated upgrading from SHA-1 to SHA-256 in certificates. A certificate signed by a CA and a forged certificate with the same signature both pass verification if the hash has a collision.
Collision resistance differs from preimage goals; no birthday-bound figures appear without derivation
Content-addressed storage uses hashes as lookup keys. If a file is stored at the location determined by its hash, and later retrieved using the same hash, the two operations must reach the same file. This requires collision resistance if there are active attackers, but it only requires second preimage resistance if attackers are passive. A passive attacker cannot create a collision; they can only observe whether legitimate files collide by chance.
Download verification uses a checksum to confirm that a file retrieved from the internet is not corrupted. The checksum is usually published alongside the file from a trusted source. An attacker who modifies the downloaded file cannot update the checksum without access to the trusted source. This use case requires second preimage resistance: given the original file and its checksum, the attacker should not be able to produce a different file with the same checksum. SHA-1 second preimage resistance is still solid despite the collision breaks.
Map integrity and naming uses to required properties; plain hashes are not password storage
Password storage is the one use case where a hash function is not the right tool. If passwords are stored as SHA-256 hashes, and the hash database is leaked, an attacker can run a dictionary attack: hash millions of guesses and check whether any match the stored hashes. The attacker needs only one preimage for each password, and a fast function gives the attacker an efficient offline comparison loop without application rate limits.
Passwords need a deliberately slow, memory-hard, per-user salted function like Argon2id, scrypt or bcrypt. A unique per-user salt makes identical passwords produce different stored records, while the password function’s configured memory and time costs make each candidate deliberately more expensive. Exact parameters require local benchmarking and are not prescribed here. The ToolAcre SHA hash calculator does not do password hashing, and the guide documentation explains why SHA-256 is unsuitable for this use case.
Worked example — applying the mapping to SHA-1 in a Git repository versus SHA-1 in a certificate
A worked example: SHA-1 in a Git repository. Every Git commit has a SHA-1 hash as its object ID. If SHA-1 collision resistance is broken, is a Git repository vulnerable? The answer is: maybe. An attacker could create a commit with the same SHA-1 as an existing commit and push it to a repository server, which might then serve different commits to different clients. However, this requires choosing a specific target and computing a collision, which is expensive even with broken SHA-1.
Git project members have published a roadmap to migrate to SHA-256, but the urgency is moderate because the practical attack requires both collision techniques and server compromise. For a developer asking "does my Git repository security depend on SHA-1 collision resistance?" the answer is yes, but the practical risk is low compared to other security threats. The ToolAcre SHA hash calculator provides both SHA-1 and SHA-256, labeled appropriately, so developers can compute either and understand the difference.
Takeaway: name the property before you panic — the ToolAcre SHA hash calculator lets you see the digest lengths that set each algorithm's bounds
For any system using SHA-1, the decision to upgrade depends on whether the use case requires the specific property that is broken. If the use case is digital signatures or deduplication against active attackers, collision resistance is required, and SHA-1 is broken, so upgrade to SHA-256 immediately. If the use case is content-addressed storage or checksums, second preimage resistance is required, and SHA-1 is still secure for that purpose, though SHA-256 is preferable for future-proofing.
If the use case is key derivation or password verification, preimage resistance is required, and nothing in this toolkit should be used at all because faster functions are better for key derivation. The ToolAcre SHA hash calculator lets developers compute digests and see the properties in action. Understanding these three properties and matching them to use cases is the foundation of making secure cryptographic choices in real systems.