Re-Hashed: The Difference Between SHA-1, SHA-2 and SHA-256 Hash Algorithms
1 Star2 Stars3 Stars4 Stars5 Stars (30 votes, average: 4.17 out of 5)

Re-Hashed: The Difference Between SHA-1, SHA-2 and SHA-256 Hash Algorithms

SHA-1, SHA-2, SHA-256,  SHA-384 – What does it all mean!!

If you have heard about “SHA” in its many forms, but are not totally sure what it’s an acronym for or why it’s important, we’re going to try to shine a little bit of light on that here today.

Before we can get to SHA itself though, we need to run through what a hash is, and then we’ll get into how SSL certificates use hashes to form digital signatures. These are critical concepts to understand before you’ll be able to follow what SHA-1 and SHA-2 are.

Let’s begin.

What is a Hash?

A hashing algorithm is a mathematical function that condenses data to a fixed size. So, for example, if we took the sentence…

“The Quick Brown Fox Jumps Over The Lazy Dog”

…and ran it through a specific hashing algorithm known as CRC32 we would get:


This result is known as a hash or a hash value. Sometimes hashing is referred to as one-way encryption.

Hashes are convenient for situations where computers may want to identify, compare, or otherwise run calculations against files and strings of data. It is easier for the computer to first compute a hash and then compare the values than it would be to compare the original files.

One of the key properties of hashing algorithms is determinism. Any computer in the world that understands the hashing algorithm you have chosen can locally compute the hash of our example sentence and get the same answer.

The difference between Encryption, Hashing and Salting

Hashing algorithms are used in all sorts of ways – they are used for storing passwords, in computer vison, in databases, etc.

There are hundreds of hashing algorithms out there and they all have specific purposes – some are optimized for certain types of data, others are for speed, security, etc.

For the sake of today’s discussion, all we care about are the SHA algorithms. SHA stands for Secure Hash Algorithm – its name gives away its purpose – it’s for cryptographic security.

If you only take away one thing from this section, it should be: cryptographic hash algorithms produce irreversible and unique hashes. Irreversible meaning that if you only had the hash you couldn’t use that to figure out what the original piece of data was, therefore allowing the original data to remain secure and unknown. Unique meaning that two different pieces of data can never produce the same hash – the next section explains why this is so important.

Note: To make it easier to read and comprehend this article I am using an example data string and hashing algorithm that is significantly shorter than what would actually be used in practice. The hashes you have seen thus far are NOT SHA hashes of any type.

public key encryption
Digital Signatures

Now that we know what hashes are, we can explain how they are used in SSL Certificates.

The SSL/TLS protocol is used to enable secure transmission of data from one device to another across the internet. For succinctness, it seems SSL is often explained as “encryption.” But don’t forget that SSL also provides authentication. The SSL certificate file is tasked with providing the necessary information needed for authentication. Or put another way, SSL certificates bind a specific public key to an identity.

Remember that the SSL/TLS protocol facilitates a connection using asymmetric encryption. This means there are two encryption keys that each handle one half of the process: a public key for encryption, and a private key for decryption. Every SSL certificate contains a public key that can be used by the client to encrypt data, and the owner of said SSL certificate securely stores a private key on their server which they use to decrypt that data and make it readable.

Ultimately, the primary purpose of this asymmetric encryption is secure key exchange. Owing to the computing power asymmetric keys require, it’s more practical (and still safe) to use smaller symmetric keys for the actual communication portion of the connection. So the client generates a session key, then encrypts a copy of it and sends it to the server where it can be decrypted and used for communicating throughout the duration of the connection (or until it’s rotated out).

The is why Authentication is incredibly important to making sure SSL/TLS actually provides meaningful security. Imagine if your computer had no reliable way to know who owned the encryption key you were using? Encrypting your session key with that public key would not be useful because you would not know who possessed the corresponding private key that decrypts it. After all, encrypting data is of little use if you are sending it directly to a man-in-the-middle attacker or a malicious party at the other end of the connection.

Digital signatures are an important part of how SSL certificates provide authentication. When a certificate is issued, it is digitally signed by the Certificate Authority (CA) you have chosen as your certificate provider (for example Sectigo, DigiCert, etc). This signature provides cryptographic proof that the CA signed the SSL certificate and that the certificate has not been modified or reproduced. More importantly, it an authentic signature is cryptographic proof that the information contained in the certificate has been verified by a trusted third party.

Now let’s talk about how a digital signature is made, applied, affixed – you pick the terminology. The asymmetric keys we mentioned before are used again, but for the purpose of signing not encrypting. Mathematically, signing involves flipping around the way the data and keys are combined (We won’t go too far into the weeds on the specifics of how signatures are created because it gets complicated quickly. If you are interested in that, Joshua Davies has written a great post on how digital signatures work). To make it easier for computers to quickly, yet still securely, create and check these signatures, the CA first hashes the certificate file and signs the resulting hash. This is more efficient than signing the entire certificate.

That Digital signatures then provides the needed proof that the certificate you have been given is the exact certificate issued by a trusted CA to the website in question. No tricks. No spoofing. No man-in-the-middle manipulation of the SSL/TLS certificate file.

Digital signatures are incredibly sensitive – any change to the file will cause the signature to change. If we took our example sentence from the previous section and made it entirely lowercase (“the quick brown fox jumps over the lazy dog”) the resulting hash would be entirely different. That means the resulting signature of that hash would also be different. Even changing one bit of a multi-thousand gigabyte document would result in an entirely different hash.

This makes it impossible for an attacker to modify a legitimate certificate or create a fraudulent certificate that looks legitimate. A different hash means that the signature would no longer be valid, and your computer would know this when it’s authenticating the SSL certificate. If your computer encountered an invalid signature, it would trigger an error and entirely prevent a secure connection.

SHA-1 and SHA-2

pki certificate management mistake, algorithms, sha, sha-2, sha-256

Now that we have laid the foundation, we can get on to the star of the show.

As I said earlier, SHA stands for Secure Hashing Algorithm. SHA-1 and SHA-2 are two different versions of that algorithm. They differ in both construction (how the resulting hash is created from the original data) and in the bit-length of the signature. You should think of SHA-2 as the successor to SHA-1, as it is an overall improvement.

Primarily, people focus on the bit-length as the important distinction. SHA-1 is a 160-bit hash. SHA-2 is actually a “family” of hashes and comes in a variety of lengths, the most popular being 256-bit.

The variety of SHA-2 hashes can lead to a bit of confusion, as websites and authors express them differently. If you see “SHA-2,” “SHA-256” or “SHA-256 bit,” those names are referring to the same thing. If you see “SHA-224,” “SHA-384,” or “SHA-512,” those are referring to the alternate bit-lengths of SHA-2. You may also see some sites being more explicit and writing out both the algorithm and bit-length, such as “SHA-2 384.” But that’s obnoxious like making people include your middle initial when you say your name.

The SSL industry has picked SHA as its hashing algorithm for digital signatures

From 2011 to 2015, SHA-1 was the primary algorithm. A growing body of research showing the weaknesses of SHA-1 prompted a revaluation. In fact, Google has even gone so far as to create a SHA-1 collision (when two pieces of disparate data create the same hash value) just to provide. So, from 2016 onward, SHA-2 is the new standard. If you are receiving an SSL/TLS certificate today it must be using that signature at a minimum.

Occasionally you will see certificates using SHA-2 384-bit. You will rarely see the 224-bit variety, which is not approved for use with publicly trusted certificates, or the 512-bit variety which is less widely supported by software.

SHA-2 will likely remain in use for at least five years. However, some unexpected attack against the algorithm could be discovered which would prompt an earlier transition.

Here is what A SHA-1 and SHA-2 hash of our website’s SSL Certificate looks like:

SHA-1, SHA-2
Image and hash calculation from

So, yes. This is what all the fuss is about. It may not look like much – but digital signatures are incredibly important for ensuring the security of SSL/TLS.

A larger bit hash can provide more security because there are more possible combinations. Remember that one of the important functions of a cryptographic hashing algorithm is that is produces unique hashes. Again, if two different values or files can produce the same hash, you create what we call a collision.

The security of digital signatures can only be guaranteed as long as collisions do not occur. Collisions are extremely dangerous because they allow two files to produce the same signature, thus, when a computer checks the signature, it may appear to be valid even though that file was never actually signed.

The difference between Encryption, Hashing and Salting
How Many Hashes?

If a hashing algorithm is supposed to produce unique hashes for every possible input, just how many possible hashes are there?

A bit has two possible values: 0 and 1. The possible number of unique hashes can be expressed as the number of possible values raised to the number of bits. For SHA-256 there are 2256 possible combinations.

So, 2256 combinations. How many is that? Well, it’s a huge number. Seriously. It puts numbers like trillion and septillion to shame. It far exceeds the how many grains of sand are in the world.

The larger the number of possible hashes, the smaller the chance that two values will create the same hash.

There are (technically) an infinite number of possible inputs[1], yet a limited number of outputs. So, eventually, every hashing algorithm, including a secure one, produces a collision. But we are mostly concerned with how easy it would be to do so. SHA-1 was deemed insecure because, due to both its size and construction, it was feasible to produce a collision.

Note that a large bit-length does not automatically mean a hashing algorithm produces more secure hashes. The construction of the algorithm is also incredibly important – that’s why the SSL industry uses hashing algorithms specifically designed for cryptographic security.

The Move To SHA-2

In 2015 the SSL industry went through the “SHA-2 Transition.” It involved re-issuing thousands of existing certificates so that new files could be created and signed with SHA-2. It also involved major updates to the issuance software that publicly-trusted CAs operate (there are dozens of them). As expected, there were some hiccups.

The deadline for issuing new SSL certificates with SHA-1 hashes was December 31st, 2015. For the most part, the industry has stuck by that deadline. Since then, a few mistakes have been made, and a few special cases were granted.

But over the last three years SHA-1 certificates have almost entirely died out. Today, if you encounter a SHA-1 certificate, you will see an unmistakable warning. It’s been escalating. In Google Chrome, all SHA-1 certificates expiring in 2016 didn’t show the green padlock in secure connections, and instead displayed the same icon as an unsecured HTTP connection.  You can click the icon to get more specific information about why it’s being displayed, in case there are other reasons unrelated to the signature.

If you saw a SHA-1 certificate in your browser today, here is what it would look like (in Google Chrome). To see how this page looks in your browser, visit

Browsers treated SHA-1 signed certificates that expire in 2017 with a more intense warning. This is because the security of a signature is directly related to how long it’s valid.

Now, in 2018, Google just summarily executes the site owner and leaves his corpse displayed as a warning to others that might dare to commit the same sins.

Keeping Signatures Secure

As time progresses, attacks against cryptography will improve, and computer processing power will become cheaper. This makes a valid SHA-2 signature less secure in 2020 than it was in 2016. For this reason, the choice of algorithm will be much beefier than immediately necessary so that short term improvements do not result in a compromise of security. It is not unrealistic for a particular hashing algorithm to remain secure for a decade.

Industry experts and security researchers across the world are continually analyzing SHA-2 and other cryptographic hashing algorithms, so rest assured that current SSL certificates will have reliable and secure digital signatures for a while.

That does not mean that cryptographers will just sit around and wait until there is a problem. The successor to SHA-2, conveniently named SHA-3, has already been finalized. When it’s time to make another switch, the SSL industry may use SHA-3 as its next choice, or it may look to an entirely different algorithm.

It takes years to properly research and vet new cryptographic standards, and then develop software that supports them. Hopefully it is reassuring to know the industry is always at least one step ahead.

Every so often we like to re-Hash some of our best, older content in the hopes that our new readers may enjoy it. This article, which was originally written by Vincent Lynch on June 29, 2016, has been updated and revised by Patrick Nohe for 2018.

    • Nice article. The line below brought me to tears. I just kept cracking up.
      Now, in 2018, Google just summarily executes the site owner and leaves his corpse displayed as a warning to others that might dare to commit the same sins.

  • […] SHA stands for Secure Hashing Algorithm. It works by taking an input that can be any random size, and will produce an output that is a fixed size. With true SHA-512, the output will always be 512 bits. Why is this important?, […]

  • Thanks for the article – what about SHA application with respect to SFTP. Are the considerations fundamentally the same? E.g. has the PKI industry recommended against use of SHA1 over SFTP for the same time as use of SHA1 for SSL?

  • […] of years to ensure that SSL Certs become the norm. There’s been a strong push to migrate from SHA-1 to SHA-2 certificates. SHA stands for Secure Hashing Algorithm, which is a hash algorithm used for encryption. Imagine […]

  • I am astonished by the depth of technical knowledge of the author. The same stuff i have been reading for past few days on other know tech sites, but this one broke the ice. The most outstanding one liner to note:

    “If you see “SHA-2,” “SHA-256” or “SHA-256 bit,” those names are referring to the same thing”

    Kudos and hats off to you!

    • With hashing, the longer the output is, the longer it would take to compute and the more secure it is. But it’s a slide scale, the fact longer hashes take longer to compute can also harm performance. So depending on your use case, you may favor more agility and go with a shorter hash length, or security and go for a longer one.

      • Or you could add BlindHash to the function and then the length of the computational hash is not as important. Security is greatly increased and so is performance. Data hashing is the key.

  • “The most important factors for cryptographic hash algorithms is that they produce irreversible and unique hashes […] Unique so that two different pieces of data can’t produce the same hash”

    Wrong. Two pieces of data can produce the same hash. This is really fundamental stuff.
    For two pieces of differemt data to not produce the same hash, ever, your hash would have to be at least the same length as the data inputs.d

  • muito obrigado, me ajudou muito, estou com uma prova pra fazer e esse site foi o melhor na explicação. só uma coisinha podia ser melhor, é ter tradução para o português, espero que no futuro possam traduzir esse artigo para que mais brasileiros tenham acesso, obrigado pelo artigo esclarecedor.

  • This very helpful indeed, yet I feel as if I’m still conflicted a bit. I will do further reading of the links contained and hopefully have a clear picture of this process. Thank you for your time and effort. It’s greatly appreciated

  • Very Well written explanation in plain English. Wish all the tech will write like this so we all can understand. Thank You.

  • “Now, in 2018, Google just summarily executes the site owner and leaves his corpse displayed as a warning to others that might dare to commit the same sins.”

    These gems of humour made me keep reading the article. Thanks! I understand hashes a lot better now!

  • This very helpful indeed. I will do further reading of the links contained and hopefully have a clear picture of this process. Thank you for your time and effort. It’s greatly appreciated

  • Excellent article and very helpful to understand the issues caused due to various versions of SHA.

  • Nice Blog. Industry experts and security researchers across the world are continually analyzing SHA-2 and other cryptographic hashing algorithms. Thanks for sharing…

  • In a standard Certificate Cipher Suite, such as….


    What does the “SHA” at the end of the below line imply ??? SHA-1 or SHA-2 ???? and what would be it’s default number of bits ???


  • If SHA1 was considered weak in 2015, why are root CAs still signed with it for certificates created in 2020? We just got cited with this on a certificate purchased this year. Looking through the built-in root CAs in Firefox and Chrome, a large percentage (possibly half) are still signed using SHA1

  • Great article Patrick ! (almost put Mr. Fobes as if you were my high school hashing teacher)

    I appreciated the ease of comprehension, good grammer, inclusion of links of further research, and the language that accurately placed the depth of topics in the article wihin the increased complexity that each topic has. Also, each aspect of the article was well tied together.

    Definitely plan other articles of yours.


Leave a Reply

Your email address will not be published. We will only use your email address to respond to your comment and/or notify you of responses. Required fields are marked *

Captcha *


Patrick Nohe

Patrick started his career as a beat reporter and columnist for the Miami Herald before moving into the cybersecurity industry a few years ago. Patrick covers encryption, hashing, browser UI/UX and general cyber security in a way that’s relatable for everyone.