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

SHA-256 Hash Algorithms

thesslstore.com/blog/difference-sha-1-sha-2-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
1/6
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
2/6
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:

3/6
 Image and hash calculation from MD5File.com

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

4/6
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 https://sha1-2016.badssl.com

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.
5/6
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.

#Hashing
#SHA-1
#SHA-2
#SHA-256

6/6