110 Digital Life Security #14: Encryption, Hashing and Digital Signatures — Three Tools That Do Very Different Jobs

Digital Life Security Series ...Practical ways to protect your devices, accounts, privacy, information and home

Encryption.

Hashing.

Digital signatures.

These three terms appear constantly in cybersecurity.

They are all based on cryptography.

They sometimes appear together in the same security system.

And because of that, they are easy to confuse.

But they solve very different problems.

Let's begin with a simple framework:

Encryption protects secrecy.

Hashing creates a fingerprint.

Digital signatures provide evidence about authenticity and integrity.

That is greatly simplified, but it gives us a map.

Start With the Security Question

Instead of beginning with complicated mathematics, begin with the problem we are trying to solve.

Suppose we have some information.

We might ask:

Can someone else read this?

That is primarily a confidentiality question.

Encryption can help.

Or we might ask:

Has this information changed?

That is an integrity question.

Cryptographic hashing can help.

Or we might ask:

Can I verify that this information was signed using the private key associated with a particular identity?

That is an authentication and integrity question.

Digital signatures can help.

Different questions require different cryptographic tools.

Encryption: Protecting Confidentiality

Let's start with encryption.

Imagine a message:

The meeting begins at 3:00.

If we send that message in readable form, anyone who can appropriately observe the communication may be able to read it.

Encryption transforms readable information, called plaintext, into an unreadable form called ciphertext.

Conceptually:

Plaintext + encryption algorithm + key → ciphertext

Someone with the appropriate key can recover the plaintext.

This ability to recover the original information is a defining characteristic of encryption.

Encryption Is Reversible — With the Right Key

This distinction is extremely important.

Encryption is designed to be reversible for someone who possesses the appropriate key.

If you encrypt a file because you want to read it again tomorrow, there must be a legitimate way to decrypt it.

If your phone encrypts stored information, the system must be able to decrypt that information when you properly unlock and use the device.

If HTTPS encrypts web communication, the browser and server need to decrypt the protected information at their respective endpoints.

Encryption hides information without intentionally destroying it.

Symmetric Encryption

In symmetric encryption, the communicating parties use shared secret key material.

Symmetric encryption is extremely fast and efficient.

That makes it well suited for protecting large amounts of data.

For example, modern TLS uses symmetric encryption to protect the bulk of an HTTPS session after secure session keys have been established.

Your browser may transfer:

• HTML
• Images
• Cookies
• Form submissions
• Application data
• Other web content

Symmetric cryptography can protect that traffic efficiently.

The Shared-Secret Problem

Symmetric encryption creates an obvious question.

If two computers need the same secret key material, how do they safely establish it?

They cannot simply shout the secret across an untrusted network.

Anyone listening could obtain it.

This problem helped motivate the development and use of public-key cryptography.

Asymmetric Cryptography

Asymmetric cryptography uses mathematically related keys:

A public key

and:

A private key.

The public key can be distributed.

The private key must remain protected.

Depending on the cryptographic system, these keys can be used for operations such as authentication, digital signatures, or establishing shared secrets.

Public-key cryptography does not mean that every byte of Internet traffic is encrypted directly with a public key.

As we learned with TLS, asymmetric and symmetric cryptography can work together.

Encryption Answers a Confidentiality Question

The main question encryption helps answer is:

How can we keep this information secret from parties who are not authorized to read it?

That applies to:

• Data traveling across networks
• Files stored on disks
• Phone storage
• Backups
• Messages
• Database information
• Other sensitive data

Encryption is one of our primary confidentiality tools.

Now Hashing

Hashing solves a different problem.

A cryptographic hash function accepts input data and produces a fixed-size output commonly called a hash or digest.

Conceptually:

Data → hash function → digest

Unlike encryption, cryptographic hashing is designed to be one-way.

You do not normally take a hash and decrypt it back into the original data.

There is no ordinary decryption key.

A Hash Is Like a Digital Fingerprint

Suppose we have a large file.

We calculate its cryptographic hash.

We get a relatively small digest representing that exact data.

If even a tiny part of the file changes, a strong cryptographic hash function should produce a dramatically different digest.

That makes hashes useful for detecting changes.

Instead of comparing every byte of two enormous files manually, we can calculate their hashes.

If the hashes differ, the files differ.

A Tiny Change Produces a Big Difference

Imagine hashing:

The payment is $100.

Then change one character:

The payment is $900.

A cryptographic hash function should produce a completely different digest.

This sensitivity to changes is one of the reasons hashing is so useful for integrity checking.

Hashes Are Fixed Length

A cryptographic hash function produces an output of a defined size regardless of whether the input is:

One sentence.

A photograph.

A software installer.

A database export.

An entire disk image.

The input can be enormous.

The resulting digest has the fixed size defined by the hash algorithm.

Can Two Inputs Ever Have the Same Hash?

Because a hash output has a finite number of possible values while the possible inputs are effectively unlimited, two different inputs can theoretically produce the same hash.

This is called a collision.

A secure cryptographic hash function is designed to make finding useful collisions computationally impractical.

If researchers discover practical ways to create collisions in an older algorithm, that algorithm may no longer be suitable for important security purposes.

This is one reason cryptographic algorithms change over time.

Old Hash Algorithms Can Become Obsolete

Algorithms such as MD5 and SHA-1 were once widely used.

Cryptographic weaknesses were eventually demonstrated that made them inappropriate for many modern security uses.

That does not mean every old MD5 value suddenly became meaningless for every non-security purpose.

It means we should not rely on broken or obsolete algorithms when adversarial collision resistance matters.

Cryptography has a lifespan.

Hashing and Passwords

We encountered hashing when we discussed password security.

A properly designed authentication system does not need to store everyone's plaintext password so that it can later read it back.

Instead, it can store information derived from the password using an appropriate password-hashing process.

When the user logs in, the system processes the entered password and determines whether it matches the stored authentication information.

The server does not need to decrypt the stored value back into the password.

That is why password storage is fundamentally different from encrypting a document.

Why Not Simply Use a Fast Hash?

This is an important twist.

For many applications, fast cryptography is desirable.

For password hashing, extreme speed can help attackers.

If an attacker steals a password-hash database, the attacker may attempt enormous numbers of password guesses offline.

A password-hashing function is therefore intentionally designed to make guessing more computationally expensive.

Modern password storage uses specialized password-hashing or key-derivation approaches rather than simply applying a general-purpose fast hash once.

Salt

Password hashing commonly uses a random value called a salt.

The salt is combined with the password as part of the password-hashing process.

Different users therefore should not automatically receive identical stored password hashes merely because they chose the same password.

The salt does not need to be secret.

Its job is different.

It helps defeat certain forms of precomputation and makes attackers deal with password hashes individually.

The Salt Is Not an Encryption Key

This is another useful distinction.

A salt can be stored alongside the password hash.

It does not unlock the hash.

There is no normal operation:

Use the salt to decrypt the password.

Again:

Hashing is not encryption.

Hashing Can Verify Downloads

Suppose you download a large software file.

The software publisher may provide a cryptographic hash for the expected file.

You calculate the hash of the file you downloaded.

If your result matches the expected value, you have evidence that the bytes match the file represented by that published hash.

But there is an important security question.

Where did the expected hash come from?

A Hash Alone Does Not Prove Who Created the File

Imagine an attacker replaces both:

The legitimate download.

And the hash displayed beside it.

You calculate the hash.

Perfect match!

Unfortunately, you may simply have confirmed that the malicious file matches the attacker's malicious hash.

This reveals an important limitation.

A hash can help demonstrate integrity relative to a trusted expected value.

A hash by itself does not prove who created or approved the data.

For that, we need authentication.

Enter Digital Signatures

A digital signature combines cryptographic techniques to provide evidence about the authenticity and integrity of data.

Conceptually, the signer uses a private key to create a signature associated with the data.

Someone with the corresponding public key can verify the signature.

If the data changes, signature verification should fail.

If the signature was not created with the appropriate private key, verification should fail.

Digital Signatures Are Not Scanned Handwriting

A picture of your handwritten signature pasted into a PDF is a digital image of a signature.

That is not what cryptographers mean by a digital signature.

A cryptographic digital signature is mathematical evidence associated with data and a private key.

It can be automatically verified by software.

Hashing and Digital Signatures Work Together

Digital-signature systems commonly use cryptographic hashing as part of the process.

Instead of performing the signature operation directly over an enormous document, the system can hash the data and perform the appropriate signature operation involving that digest.

Conceptually:

Document → Hash → Digital Signature

The verifier can hash the received document and verify the signature using the signer's public key.

If the document changes, the verification fails.

The Private Key Signs

In a digital-signature system:

The private key is used to sign.

The corresponding public key is used to verify.

This is very different from keeping a shared password secret.

The public key can be widely distributed.

People can use it to verify signatures without gaining the ability to create valid signatures as the private-key holder.

This Is Why Private-Key Protection Matters

If someone steals a signing private key, that person may be able to create signatures that verify as coming from that key.

The mathematics may work perfectly.

The problem is that the wrong person now controls the key.

This teaches us another critical security lesson:

Cryptography cannot compensate for stolen keys.

Key protection is part of cryptographic security.

We Have Already Used Digital Signatures

Digital signatures have appeared repeatedly in our course.

Remember DKIM?

The sending mail system signs information associated with an email using a private key.

The receiving mail system obtains the corresponding public key through DNS.

It verifies the signature.

That helps provide evidence that the message was signed by infrastructure controlling the relevant private key and that signed portions of the message were not improperly changed.

That is a digital-signature application.

TLS Certificates Use Digital Signatures

Certificate Authorities sign certificates.

Your browser verifies those signatures while building the certificate chain.

A website certificate may be signed by an intermediate CA.

The intermediate certificate may be signed by another trusted authority in the chain.

Digital signatures allow your browser to validate those relationships.

The certificate system we discussed in the previous topic depends heavily on signatures.

Passkeys Use Public-Key Cryptography Too

Passkeys also use public/private key cryptography.

The private credential material remains protected on the user's device or within an appropriate credential system.

The service stores information associated with the public key.

Authentication can then involve proving possession of the appropriate private key without sending a reusable password to the website.

Again:

Private key proves.

Public key verifies.

Three Tools, Three Questions

Let's put our three tools side by side.

Encryption

Question:

How do I prevent unauthorized people from reading this?

Primary security goal:

Confidentiality.

Hashing

Question:

Can I create a compact cryptographic fingerprint of this data?

Primary uses include:

Integrity checking and cryptographic building blocks.

Digital Signatures

Question:

Can I verify that this data was signed using the expected private key and has not been improperly changed?

Primary goals include:

Authentication and integrity.

Encryption Does Not Automatically Prove Integrity

This is worth understanding carefully.

The fact that something is encrypted does not, by itself, automatically provide every security property we might want.

Modern authenticated-encryption systems are designed to provide both confidentiality and integrity protection.

But conceptually, encryption and integrity are different security goals.

This is why cryptographic protocols combine multiple techniques rather than relying on one primitive for everything.

Hashing Does Not Provide Confidentiality

A hash is not an encrypted secret.

It is not designed to be decrypted.

And hashing something does not necessarily keep the original information confidential.

For example, if an attacker sees the hash of a weak password, the attacker can guess possible passwords, hash those guesses appropriately, and test for a match.

The attacker does not need to reverse the hash mathematically.

The attacker can simply guess the input.

This Is Why Strong Passwords Still Matter

Imagine the password is:

dog

An attacker does not need a magical hash-reversing algorithm.

The attacker can try:

cat

dog

password

and millions or billions of other guesses, depending on the circumstances.

When one produces the expected result, the password has effectively been discovered.

Strong unique passwords, salts, and appropriately designed password-hashing algorithms work together to make this much harder.

Digital Signatures Do Not Provide Secrecy

A digitally signed document does not necessarily become secret.

Anyone may still be able to read it.

The signature provides evidence about authenticity and integrity.

If secrecy is also required, encryption may be needed.

This is another reason cryptographic systems combine tools.

Signed and Encrypted Are Different

Consider an email message.

We might want to:

Sign it so the recipient can verify its authenticity and integrity.

We might want to:

Encrypt it so unauthorized people cannot read it.

Or we might want both.

Those are separate operations serving separate security goals.

Confidentiality, Integrity and Authentication

We can now connect cryptography to our broader security framework.

Confidentiality:

Encryption helps prevent unauthorized reading.

Integrity:

Hashes and authenticated cryptographic mechanisms help detect modification.

Authentication:

Digital signatures and public-key systems can help verify identities or possession of cryptographic keys.

Different cryptographic tools support different parts of the security problem.

Where Does Availability Fit?

Remember the CIA triad:

Confidentiality.

Integrity.

Availability.

Cryptography can strongly support confidentiality and integrity.

But encryption cannot help you access a server that has crashed.

A digital signature cannot restore a deleted database.

A hash cannot provide electricity to a failed router.

Availability requires additional systems:

• Backups
• Redundancy
• Reliable infrastructure
• Disaster recovery
• Power protection
• Monitoring
• Operational planning

Security is broader than cryptography.

Cryptography Is Mathematics; Security Is a System

This may be one of the most important lessons in this topic.

You can use excellent encryption and still have terrible security.

Perhaps the encryption key is stored in an unprotected text file.

Perhaps the user's password is stolen through phishing.

Perhaps malware is running on the computer after the information has been decrypted.

Perhaps an administrator accidentally exposes the database.

The cryptography may be mathematically excellent.

The system surrounding it may fail.

Strong cryptography does not automatically create a secure system.

The Endpoint Problem

Suppose you send a perfectly encrypted message.

While traveling across the network, nobody can read it.

It reaches the recipient's computer.

The computer decrypts it.

Now the message must become readable so the recipient can see it.

If malware has compromised that computer, the attacker may capture the information after decryption.

The encryption did its job perfectly.

The endpoint failed.

This is why endpoint security remains important even when communication is encrypted.

Encryption at Rest and Encryption in Transit

You will often hear two phrases:

Encryption in transit

and:

Encryption at rest.

Encryption in transit protects information while it moves between systems.

HTTPS is a familiar example.

Encryption at rest protects stored information.

Examples can include encrypted phone storage, encrypted computer disks, encrypted backups, or encrypted databases.

Both matter because data exists in different states throughout its life.

What About Data in Use?

There is also a third state worth recognizing:

Data in use.

At some point, a computer usually needs to process information in a usable form.

That may require the information to be available in memory to authorized software.

Protecting data while it is actively being processed creates another set of security challenges.

Again, encryption is powerful but not magical.

Key Management May Be Harder Than Encryption

Modern cryptographic algorithms can be extraordinarily strong.

But organizations still have to answer:

Where are the keys stored?

Who can access them?

How are they backed up?

When are they rotated?

What happens if one is compromised?

How is it revoked?

What happens if the key is lost?

How do we know which key belongs to whom?

This is called key management.

In real systems, managing cryptographic keys securely can be as important as choosing strong cryptographic algorithms.

If You Lose the Encryption Key

Good encryption creates an interesting problem.

If nobody possesses the correct decryption key, the encrypted information may become effectively unrecoverable.

That is excellent when an attacker does not have the key.

It is less excellent when the legitimate owner loses it.

Security therefore has to balance:

Keeping keys away from attackers.

and:

Making sure authorized users do not permanently lose access.

Security and availability meet again.

Let's Identify the Tool

Now let's test our understanding.

A website protects communication from network eavesdropping.

Encryption.

A server stores password-verification information without needing to recover the plaintext password.

Password hashing.

A software publisher wants users to detect whether a downloaded file differs from an expected file.

Cryptographic hashing can help.

A Certificate Authority wants browsers to verify that it issued a certificate.

Digital signature.

An email server wants to verify a DKIM signature.

Digital signature.

A phone protects stored data when locked.

Encryption.

A browser wants to establish protected HTTPS communication.

A combination of cryptographic tools.

Most Real Security Systems Use More Than One Tool

TLS combines:

Public-key cryptography.

Digital signatures.

Key exchange.

Symmetric encryption.

Cryptographic integrity protection.

Password systems combine:

Random salts.

Password-hashing functions.

Authentication logic.

Rate limiting.

Multifactor authentication.

Passkeys combine:

Public-key cryptography.

Digital signatures or related cryptographic authentication operations.

Device security.

User verification.

Security systems are built from combinations of primitives.

Do Not Invent Your Own Cryptography

This leads to a famous lesson in computer security.

Cryptography is extremely difficult to design correctly.

A system can look clever and still contain devastating mathematical or implementation weaknesses.

Developers should use well-studied modern cryptographic libraries, protocols, and established designs rather than inventing homemade encryption schemes.

Good security engineering uses proven building blocks correctly.

Now Read Security Language Differently

When you encounter phrases such as:

The password is encrypted.

you can ask:

Should it actually be encrypted, or should password verification use a password-hashing scheme?

When someone says:

The file has a hash, so we know who created it.

you can ask:

Where did the trusted hash come from, and is there a signature?

When someone says:

The website uses HTTPS, so it must be legitimate.

you can ask:

Does HTTPS authenticate the domain connection, or the honesty of the person operating the site?

You are learning to ask the cryptographically correct question.

Three Tools to Remember

If you remember nothing else from this topic, remember this:

Encryption protects secrecy.

The original information can be recovered with the appropriate key.

Hashing creates a fingerprint.

It is designed as a one-way transformation and is useful for integrity and many other cryptographic constructions.

Digital signatures provide evidence about authenticity and integrity.

The private key signs.

The public key verifies.

And Now the Security World Looks Different

HTTPS is no longer simply “encrypted web browsing.”

We can see certificates, signatures, key establishment, and symmetric session encryption.

Password storage is no longer simply “the password is scrambled.”

We can see salts and password hashing.

DKIM is no longer simply “email authentication.”

We can see a private signing key, a public verification key in DNS, and a cryptographic signature.

Passkeys are no longer simply “a replacement for passwords.”

We can see public/private key cryptography being used for authentication.

The terminology is beginning to reveal the machinery underneath.

And that is one of the goals of this entire series:

We do not need to become cryptographers.

But we should understand what the cryptography is trying to accomplish.