Re-Hashed: The Difference Between SHA-1, SHA-2 and SHA-256 Hash Algorithms
1 Star2 Stars3 Stars4 Stars5 Stars (6 votes, average: 5.00 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 means or why it’s important, read on. We are going to start off by explaining what a hash is, then how SSL certificates use hashes to form digital signatures. This is important background to understand 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 “07606bb6” –this result is known as a hash.

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 them 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.

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

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.

Today, all we care about are the SHA algorithms. SHA stands for Secure Hashing Algorithm – its name gives away its purpose – it’s for cryptographic security.

The most important factors for cryptographic hash algorithms is that they produce irreversible and unique hashes. Irreversible so 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 so that two different pieces of data can’t 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. The hashes you have seen thus far are NOT SHA hashes of any type.

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 do not forget that SSL also provides authentication. The SSL certificate file is tasked with providing the necessary information needed for authentication, specifically, SSL certificates connect a specific public key to an identity.

Remember that the SSL/TLS protocol secures a connection using asymmetric encryption. This means there are two encryption keys which 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.

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 data with that key would not be useful because you would not know who had 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.

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, Symantec, Comodo, DigiCert, etc). This signature provides cryptographic proof that the CA signed the SSL certificate and that the certificate has not been modified or reproduced.

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 explain 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 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

Now that you have the appropriate background, 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.”

The SSL industry has picked SHA as their 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. From 2016 onward, SHA-2 is the new standard. If you are receiving a 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

Yup. 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. 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.

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 in 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 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

Last year 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 within the next year or two we will see the vast majority of trusted SHA-1 certificates die out. Today, there are around 500,000 SHA-1 certificates still around. If you encounter a SHA-1 certificate, you will see a degraded security indicator. In Google Chrome, all SHA-1 certificates expiring in 2016 will not show the green padlock in secure connections, and instead display the same icon as an unsecured HTTP connection.  You can click the icon to get more specific information about why it’s being displayed, as 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 treat 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.

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 their next choice, or they 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 originally ran June 29, 2016, has been updated for accuracy.

1 comment

Leave a Reply

Your email address will not be published. Required fields are marked *


Vincent Lynch

The SSL Store’s encryption expert makes even the most complex topics approachable and relatable.