SHA-1, SHA-2, and SHA-256: The Hash Algorithm Family Explained

Pick up any SSL certificate today and you will find SHA-256 as the signature algorithm. Check an old certificate from before 2016 and you might still find SHA-1. Open the NIST standards library and you will find SHA-224, SHA-384, SHA-512, SHA-512/256, and SHA-3 all sharing the same family tree. The naming is enough to confuse anyone who does not spend their days in cryptography specifications.

SHA stands for Secure Hash Algorithm. A hash function takes an input of any size and produces a fixed-length output called a digest or hash. The same input always produces the same output. Different inputs must produce different outputs as reliably as possible. You cannot reverse the process and recover the original input from the hash. These three properties together make hash functions the foundation of digital signature verification, certificate integrity checking, and data authentication in TLS.

SHA-1, SHA-2, and SHA-256 are not three separate competing algorithms of equal standing. SHA-1 is a single deprecated algorithm. SHA-2 is a family of six algorithms. SHA-256 is one member of that SHA-2 family. Understanding that relationship before comparing them changes everything about how the comparison makes sense.

The Complete SHA Family: Where Every Name Fits

NIST standardized SHA algorithms in four generations. Each generation addressed weaknesses found in the previous one. The table below maps every algorithm to its generation, output size, and current status.

SHA-256 and SHA-512 are not competing formats. SHA-512 is not “better” than SHA-256 in any absolute sense. They solve the same problem with different word sizes. SHA-256 operates on 32-bit words; SHA-512 operates on 64-bit words. On modern 64-bit processors without hardware SHA acceleration, SHA-512 is actually faster per byte of data hashed because it processes twice as much data per round.

SHA-1: What It Was, Why It Failed, and Why It Still Appears

SHA-1 was published by NIST in 1995 and quickly became the dominant algorithm for SSL/TLS certificates, code signing, and digital signatures across almost every protocol. It produces a 160-bit hash, processes data in 512-bit blocks, and runs through 80 rounds of compression operations per block. For most of its operational life, breaking SHA-1 required computational effort that exceeded any realistic attacker’s resources.

That changed through a series of theoretical advances and practical demonstrations. In 2005, cryptographers Xiaoyun Wang, Andrew Yao, and Frances Yao published theoretical attacks showing SHA-1 collision resistance was weaker than its 160-bit output suggested. The effective collision resistance was reduced to around 2^63 operations rather than the theoretical 2^80. In 2017, Google and CWI Amsterdam executed the SHAttered attack and produced the first practical SHA-1 collision: two different PDF files producing the identical SHA-1 hash. The computational cost was approximately 110 GPU-years of computation, achievable by a well-funded attacker.

Any system that uses SHA-1 for authentication or integrity verification is vulnerable to collision attacks today. An attacker who can produce two documents with the same SHA-1 hash can forge signatures, bypass integrity checks, and potentially intercept HTTPS connections. SHA-1 SSL certificates were banned from public trust by all major CAs in 2015-2016. Browsers began blocking them with hard errors in 2017.

Despite its deprecation, SHA-1 still appears in certain places. Old internal PKI systems that were not updated during the 2015 SHA-2 migration sometimes still issue SHA-1 signed certificates for internal use. Git historically used SHA-1 for object hashing (though not for security, but for deduplication) and is migrating to SHA-256. Some legacy enterprise applications and embedded systems still use SHA-1 for HMAC computations, where its weaknesses in collision resistance are less critical since HMAC requires knowledge of a secret key.

The distinction between collision resistance and preimage resistance

SHA-1’s broken status specifically means its collision resistance is compromised. A collision attack finds two different inputs that hash to the same output. This matters enormously for digital signatures, where an attacker can prepare a malicious document that produces the same hash as a legitimate one, then swap them after signing.

SHA-1’s preimage resistance, the property that prevents reversing a hash to find any input that produces a given output, is technically still intact. No practical preimage attack exists against SHA-1. This is why SHA-1 continues to appear in some HMAC contexts: HMAC using SHA-1 does not depend primarily on collision resistance. But this is a narrow exception, not a general endorsement, and no new system should use SHA-1 in any capacity.

The SHA-2 Family: Six Algorithms, Two Internal Architectures

SHA-2 is not a single algorithm. It is a family of six related hash functions, all designed by the NSA and published by NIST starting in 2001. The family splits into two internal architectures based on word size: the 32-bit group (SHA-224, SHA-256) and the 64-bit group (SHA-384, SHA-512, SHA-512/224, SHA-512/256).

Both groups use the Merkle-Damgard construction with Davies-Meyer compression. The fundamental structure is the same: divide the input into fixed-size blocks, process each block through a series of compression rounds, chain the output of each block into the next, and produce the final hash from the last block’s output. The difference is in the word size, block size, number of rounds, and initialization vectors used.

SHA-384 is not “between” SHA-256 and SHA-512 in any simple sense. It is a truncated version of SHA-512, meaning it runs the full SHA-512 algorithm (64-bit words, 1024-bit blocks, 80 rounds) and discards the last 128 bits of the 512-bit output. It inherits SHA-512’s performance characteristics on 64-bit hardware and its resistance to length-extension attacks, while producing a shorter digest suitable for TLS handshake contexts that prefer 384-bit values.

Why SHA-256 dominates SSL/TLS certificates despite SHA-512’s larger security margin

Three practical reasons explain SHA-256’s dominance over SHA-512 for SSL/TLS certificates, even though SHA-512 offers a larger theoretical security margin.

First, 128-bit collision resistance (SHA-256) is already computationally infeasible to attack with any foreseeable technology. Brute-forcing 128-bit collision resistance requires approximately 2^64 hash computations. The fastest known specialized hardware cannot complete this in the lifetime of the universe at current compute densities. SHA-512’s 256-bit collision resistance provides a larger margin, but not a margin that matters against any realistic threat.

Second, SHA-256 is hardware-accelerated on modern CPUs through the SHA-NI instruction set extension, available in Intel processors since Goldmont (2016) and AMD processors since Zen (2017). On these processors, SHA-256 computation is dramatically faster than software-based SHA-512, making SHA-256 the better choice for performance-sensitive applications like TLS handshakes that hash data many thousands of times per second on busy servers.

Third, SHA-256 is universally supported. Every TLS implementation, every certificate authority, every browser, and every operating system supports SHA-256. SHA-512 certificates are valid but some older systems and embedded environments have incomplete SHA-512 support, creating compatibility considerations.

SHA-512/256: The option most security discussions skip

SHA-512/256 deserves more attention than it typically receives. It runs the SHA-512 algorithm using 64-bit arithmetic but truncates the output to 256 bits. The initialization vectors are derived differently from both SHA-256 and SHA-512 using a method specified in FIPS 180-4.

This combination produces a hash with SHA-256-equivalent output size and security margin, SHA-512-equivalent performance on 64-bit hardware, and resistance to length-extension attacks that affects untruncated SHA-256 and SHA-512. On a modern 64-bit server without SHA-NI acceleration, SHA-512/256 is typically 40 to 60 percent faster than SHA-256 while providing equivalent security.

The reason it is not used for SSL/TLS certificates is purely support breadth. CA/B Forum baseline requirements specify SHA-256 as the interoperability baseline, and certificate issuance software universally supports SHA-256 rather than the less familiar SHA-512/256. For application-level hashing outside certificate contexts, SHA-512/256 is an underutilized high-performance choice.

SHA-3: Why It Exists Alongside SHA-2, Not as a Replacement

SHA-3 was standardized by NIST in 2015 after a five-year public competition that evaluated 51 candidate algorithms. The winner was Keccak, designed by Guido Bertoni, Joan Daemen, Michael Peeters, and Gilles Van Assche. Despite sharing the SHA name and producing hash outputs of the same sizes as SHA-2, SHA-3 uses a completely different internal structure.

SHA-1 and SHA-2 both use the Merkle-Damgard construction, where the input is divided into blocks and each block is fed through a compression function. The output of compressing one block becomes part of the input for the next. SHA-3 uses a sponge construction, which absorbs input into a large internal state and then squeezes output from that state. The internal state is far larger than the output, and the transformation function (Keccak-f) operates on this state using a design that is structurally unrelated to SHA-2’s compression rounds.

SHA-3 was designed not because SHA-2 is broken, but as insurance. If a fundamental weakness were discovered in the Merkle-Damgard construction that simultaneously affected all SHA-2 variants, SHA-3 would not share that weakness because it is architecturally independent. NIST recommends that systems which can support it use SHA-3 as an alternative or complement to SHA-2, not as a mandatory upgrade.

In practice, SHA-3 adoption outside of specialized cryptographic applications has been slow. The reason is straightforward: SHA-2, particularly SHA-256, has no known vulnerabilities, is hardware-accelerated on modern CPUs, and is embedded in every protocol stack and implementation. Migrating to SHA-3 has a real cost with no current security benefit. For SSL/TLS certificates specifically, SHA-3 is not used. All publicly trusted certificates use SHA-256 or SHA-384 from the SHA-2 family.

What a SHA Hash Actually Looks Like: Same Input, Different Algorithms

The output size differences between SHA algorithms are visible in the hash values themselves. Here is the string “CompareCheapSSL” hashed with three algorithms. Note that a single character change anywhere in the input produces a completely unrelated output, a property called the avalanche effect.

The avalanche effect, where changing any bit of the input changes approximately half of the output bits, is fundamental to why hash functions are useful for integrity verification. A file that has been modified in any way produces a different hash, and the original and modified hashes share no predictable relationship.

Hash Algorithms in SSL/TLS Certificates: Exactly What Gets Hashed

When a Certificate Authority issues an SSL certificate, the signature algorithm field specifies which hash function was used to create the digital signature binding all the certificate data together. The CA hashes the certificate’s to-be-signed portion (the TBSCertificate structure containing the subject, public key, validity dates, and extensions), then signs that hash with the CA’s private key using RSA or ECDSA.

This is why SHA-1 compromises certificate security. If an attacker can produce a malicious certificate whose TBSCertificate hashes to the same SHA-1 value as a legitimate CA-signed certificate, they can attach the CA’s valid signature to their fraudulent certificate. The collision makes the signature valid. With SHA-256, producing such a collision requires approximately 2^128 hash operations, which is computationally infeasible.

The hash algorithm in a certificate’s signature algorithm field is entirely separate from the TLS cipher suite used to protect the connection. The certificate signature algorithm authenticates the certificate’s authenticity during the handshake. The cipher suite determines how data is encrypted during the session. A SHA-256 certificate can be served over a connection using AES-256-GCM-SHA384 as the cipher suite, where SHA-384 is used for HMAC in the session, not certificate signing.

SHA Algorithms in TLS Cipher Suites: A Different Role

When SHA appears in a TLS cipher suite name such as ECDHE-RSA-AES256-GCM-SHA384, it refers to a Hash-based Message Authentication Code (HMAC), not a certificate signature algorithm. The HMAC function uses the hash algorithm to verify that data was not modified in transit during the encrypted session.

In TLS 1.3, the five approved cipher suites use SHA-256 or SHA-384 as part of the HKDF (HMAC-based Key Derivation Function) that derives session keys from the handshake secrets. TLS_AES_256_GCM_SHA384 uses SHA-384 for key derivation. TLS_AES_128_GCM_SHA256 uses SHA-256. Both are secure choices.

The HMAC use of SHA does not have the same collision-resistance requirements as certificate signing. HMAC security depends on the hash function’s pseudorandom function properties combined with a secret key. Even SHA-1 in HMAC (HMAC-SHA1) is considered secure in certain limited contexts because the attacker must know the secret key to exploit any weakness. This is why some old protocols still use HMAC-SHA1 and are not considered broken in the same way that SHA-1 certificate signatures are broken.

Choosing the Right Hash Algorithm: A Decision Reference

The right algorithm depends on the context. Certificate signing, password storage, file integrity, and HMAC authentication have different threat models and different performance requirements.

Password hashing with SHA-256 or any fast SHA algorithm is a security mistake. SHA algorithms are designed to be fast; a modern GPU can compute billions of SHA-256 hashes per second. Password hashing requires a deliberately slow algorithm with a memory-hard function to make brute-force attacks expensive. Argon2id (recommended by OWASP), bcrypt, and scrypt are purpose-built for this and should always be used for password storage instead of any SHA variant.

SHA Algorithms and Quantum Computing: The Grover’s Algorithm Impact

Quantum computers running Grover’s algorithm can search an unstructured database of N items in O(sqrt(N)) steps instead of the classical O(N). Applied to hash functions, this reduces the effective security of a k-bit hash from k bits to k/2 bits of security against preimage attacks.

For SHA-256, this means quantum computers theoretically reduce security from 256 bits to 128 bits of preimage resistance. For SHA-128 (if such a thing existed), it would be reduced to 64 bits, which would become practically attackable by a sufficiently large quantum computer. SHA-256 at 128-bit effective quantum security remains computationally infeasible for any foreseeable quantum hardware. SHA-384 at 192-bit effective quantum security provides a larger margin. SHA3-512 at 256-bit effective quantum security provides the most future headroom.

NIST’s Post-Quantum Cryptography standardization (finalized in 2024 with the publication of FIPS 203, 204, and 205) focused on asymmetric cryptography (key exchange and digital signatures), not hash functions. Hash algorithms are already considered relatively quantum-resistant when using 256-bit or larger outputs. The greater quantum threat is to RSA and ECDSA key pairs used in certificates, not to the SHA hash algorithms signing those certificates.

The practical takeaway for SSL certificates: SHA-256 certificate signatures are not rendered insecure by near-term quantum computers. The RSA-2048 or P-256 public keys embedded in those same certificates are more vulnerable to quantum attack than the SHA-256 hash of the certificate data. Post-quantum cryptography migration focuses on transitioning from RSA and ECDSA to lattice-based signature schemes like CRYSTALS-Dilithium, not on replacing SHA-256.

Frequently Asked Questions

What is the difference between SHA-1, SHA-2, and SHA-256?

SHA-1 is a single algorithm producing a 160-bit hash, published in 1995 and now deprecated due to demonstrated collision attacks. SHA-2 is a family of six algorithms published from 2001 onward: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256. SHA-256 is a specific member of the SHA-2 family that produces a 256-bit hash. When people say SHA-2 in the context of SSL certificates, they almost always mean SHA-256 specifically, since that is the variant used for certificate signatures. SHA-256 is not a competing standard to SHA-2; it is an instance of SHA-2.

Is SHA-256 the same as SHA-2?

No, though the terms are often used interchangeably in certificate discussions. SHA-2 is the family name encompassing six hash functions of different sizes. SHA-256 is one specific member of that family with a 256-bit output size. When a certificate authority says it issues SHA-2 certificates, it means the certificate is signed with one of the SHA-2 family algorithms, most commonly SHA-256. Saying SHA-2 without qualification is imprecise; saying SHA-256 is specific and unambiguous.

Why is SHA-1 still used anywhere if it is broken?

SHA-1 remains in limited use for two reasons. First, some legacy internal systems were never migrated during the 2015-2016 SHA-2 transition, either because they were isolated from the internet, because their operators were unaware, or because replacing them is expensive. Second, SHA-1’s specific weakness is collision resistance, not all cryptographic properties. HMAC-SHA1 is still considered secure in contexts where the attacker does not know the secret key, because HMAC requires knowing the key to exploit collision weaknesses. Some protocol specifications still permit HMAC-SHA1 in limited contexts for backward compatibility. No new deployment should use SHA-1 for any purpose.

Does my SSL certificate use SHA-1 or SHA-256? How do I check?

Open the site in a browser, click the padlock icon, view the certificate details, and look for the Signature Algorithm field. It will show sha256WithRSAEncryption for a SHA-256 signed certificate, or ecdsa-with-SHA256 for an ECDSA certificate. From the command line, run openssl x509 -in yourcert.pem -text -noout and look for the Signature Algorithm line near the top of the output. Any certificate signed with SHA-1 (sha1WithRSAEncryption) will be rejected by modern browsers with a hard error. If your certificate shows SHA-1, it needs immediate replacement.

Should I choose SHA-384 over SHA-256 for a new SSL certificate?

SHA-384 is valid and secure, but SHA-256 is the practical standard and what most systems expect. SHA-384 provides a larger security margin (192-bit effective collision resistance versus 128-bit for SHA-256) but neither margin is attackable by any current or near-future technology. The primary reason to use SHA-384 is compliance with requirements that mandate it, such as certain US government or financial sector standards. For general web certificates, SHA-256 provides sufficient security, better performance on SHA-NI-accelerated hardware, and universal compatibility.

What hash algorithm does Bitcoin use?

Bitcoin uses SHA-256 extensively. The proof-of-work mining process requires finding an input whose double-SHA-256 hash (SHA-256 applied twice) has a value below a target threshold. Transaction IDs are computed as double-SHA-256 of the transaction data. Block header hashes are also double-SHA-256. The choice of SHA-256 was made by Satoshi Nakamoto in Bitcoin’s original 2008 design, predating hardware acceleration, purely on the basis of SHA-256’s security margin and widespread implementation availability.

Is SHA-3 more secure than SHA-256?

SHA-3 and SHA-256 provide equivalent security margins against current attacks. SHA3-256 has 128-bit collision resistance, the same as SHA-256. SHA3-512 has 256-bit collision resistance, the same as SHA-512. The structural difference is that SHA-3 uses a sponge construction (Keccak) rather than the Merkle-Damgard construction shared by SHA-1 and SHA-2. This means that if a fundamental weakness were discovered in Merkle-Damgard that affected all SHA-2 variants simultaneously, SHA-3 would not be affected. SHA-3 is insurance against a structural attack on SHA-2, not a replacement driven by current SHA-2 vulnerabilities.

What hash algorithm should I use for passwords in 2025?

None of the SHA algorithms, including SHA-256, SHA-512, or SHA-3. Password hashing requires algorithms designed to be computationally expensive and memory-hard, specifically to slow down brute-force attacks. The current recommendations from OWASP and NIST are Argon2id as the first choice, with bcrypt and scrypt as acceptable alternatives. Fast hash functions like SHA-256 allow GPU arrays to test billions of passwords per second, making them fundamentally unsuitable for password storage regardless of their cryptographic strength for other purposes.