Module 1: PKI Fundamentals
Lesson 1.3: Hash Functions and Digital Signatures
15–20 minutes
Reading + Quiz
Lesson 3 of 18Module 1 of 5
How to Use This Lesson
- 1.Read each section in order — they build on each other.
- 2.Use "Listen to This Lesson" for optional audio narration.
- 3.Study the hash algorithm comparison table and signature flow diagrams.
- 4.Complete the knowledge check at the bottom.
- 5.Mark the lesson complete.
- 6.Continue to Lesson 1.4: The PKI Trust Hierarchy.
Lesson Summary
Hash functions produce a fixed-size fingerprint of data that cannot be reversed. Digital signatures combine hashing with asymmetric cryptography to prove integrity, authenticity, and non-repudiation. Certificate signature validation — where clients verify the CA's signature on every certificate — is the operational core of the PKI trust model.
Learning Objectives
- Explain what a hash function does and why it is one-way.
- Identify the current and deprecated hash algorithms used in PKI.
- Describe how a digital signature is created and verified.
- Explain the three security properties a digital signature provides.
- Describe how certificate signature validation works in the PKI trust chain.
A
Hash Functions in Plain English
A hash function is a one-way mathematical algorithm. You feed it any amount of data — a single character, a 10 GB file, an entire certificate — and it produces a fixed-size output called a hash, digest, or fingerprint.
Hash functions have four critical properties that make them useful in PKI:
Deterministic
The same input always produces the same output. SHA-256("hello") always produces the same 256-bit hash.
Fixed output size
Regardless of input size, the output is always the same length. SHA-256 always produces a 256-bit (32-byte) hash.
One-way (pre-image resistant)
You cannot reverse a hash to recover the original input. Given the hash, you cannot determine what data produced it.
Avalanche effect
A tiny change to the input — even one bit — produces a completely different hash. This makes tampering detectable.
Avalanche Effect — One Character Change
Original input
Input: "Hello, PKI"
SHA-256: a3f2c1d8e4b7f9a0c2d5e8f1b4a7c0d3e6f9a2b5c8d1e4f7a0b3c6d9e2f5a8b1
Added one period — completely different hash
Input: "Hello, PKI."
SHA-256: 7b9e2f4a1c6d8b3e5f0a2c7d9b4e1f6a3c8d5b2e7f4a1c6d3b8e5f2a9c4d7b0e
Note: These are illustrative hash values for demonstration purposes.
Key Concept
Hashing is not encryption
Encryption is reversible — given the key, you can decrypt the ciphertext to recover the plaintext. Hashing is one-way — there is no key, and you cannot reverse the hash. This distinction matters in PKI: certificates are signed (hashed + asymmetrically encrypted), not encrypted. The certificate data is public; the signature proves it has not been tampered with.
B
Hash Algorithms in PKI
Not all hash algorithms are equal. The security of a hash function depends on its resistance to collision attacks — where two different inputs produce the same hash. Older algorithms have been broken; modern PKI requires SHA-2 or stronger.
AlgorithmOutput SizeStatusPKI Use
MD5128 bitsBrokenNever use
SHA-1160 bitsDeprecatedLegacy only — migrate away
SHA-256256 bitsCurrentMinimum for new PKI
SHA-384384 bitsCurrentRecommended for CA certs
SHA-512512 bitsCurrentHigh-security deployments
Common Mistake
SHA-1 certificates are still in production environments
Many legacy enterprise PKI deployments still have SHA-1 signed certificates or CAs. SHA-1 was deprecated by Microsoft in 2017 and by the CA/Browser Forum for publicly trusted certificates. Audit your PKI for SHA-1 usage using certutil or PKIView. Any SHA-1 signed CA certificate or end-entity certificate must be replaced with SHA-256 or stronger.
C
How Digital Signatures Work
A digital signature combines a hash function with asymmetric cryptography. It is a two-step process: signing (done by the signer with their private key) and verification (done by anyone with the signer's public key).
Signing Process (Signer's Side)
1
Compute hash of the data
The signer runs the data through a hash function (e.g., SHA-256) to produce a fixed-size digest.
2
Encrypt the hash with the private key
The signer encrypts the hash using their private key. This encrypted hash is the digital signature.
3
Attach the signature to the data
The signature is bundled with the original data and the signer's certificate (containing the public key).
Verification Process (Recipient's Side)
1
Obtain the signer's public key
The recipient retrieves the signer's certificate (containing the public key) from the signature bundle or a certificate store.
2
Decrypt the signature with the public key
The recipient decrypts the digital signature using the signer's public key to recover the original hash.
3
Independently compute the hash
The recipient runs the received data through the same hash function to produce their own hash.
4
Compare the two hashes
If the decrypted hash matches the independently computed hash, the signature is valid — the data is unchanged and the signer holds the private key.
Key insight: If an attacker modifies even one byte of the signed data, the independently computed hash will not match the decrypted hash. The signature verification fails immediately.
D
Security Properties of Digital Signatures
A valid digital signature provides three distinct security guarantees. These are separate from the confidentiality that encryption provides.
Integrity
The signed data has not been modified since it was signed. Any change — even a single bit — invalidates the signature.
Authenticity
The data came from the claimed source. Only the holder of the private key could have created a valid signature.
Non-repudiation
The signer cannot later deny having signed the data. The private key is unique to the signer — no one else could have produced the signature.
Key Concept
Digital signatures do not provide confidentiality
Signing data does not hide it. The signed data is still readable by anyone. If you need both confidentiality and integrity, you must both encrypt and sign the data. In S/MIME email, for example, you can sign (for integrity and non-repudiation), encrypt (for confidentiality), or both.
E
Certificate Signature Validation
Every X.509 certificate contains a digital signature from the CA that issued it. This signature is what makes the certificate trustworthy. When a client validates a certificate, it is performing digital signature verification — the same process described in Section C.
X.509 Certificate Signature Structure
TBSCertificate (To-Be-Signed Data)
Version: v3
Serial Number: 4A:B2:C8:...
Subject: CN=webserver.northstar.local
Issuer: CN=Northstar Issuing CA
Validity: 2025-01-01 to 2026-01-01
Subject Public Key: [RSA 2048-bit]
Extensions: SAN, EKU, CDP, AIA...
↑ This entire block is hashed by the CA (SHA-256)
CA signs the hash with its private key
Signature Algorithm + Value
signatureAlgorithm: sha256WithRSAEncryption
signatureValue: [encrypted SHA-256 hash of TBSCertificate]
↑ Clients verify this signature using the CA's public key
How a Client Validates a Certificate Signature
1
Locate the issuing CA certificate
The client finds the CA certificate (from the AIA extension or local store) to get the CA's public key.
2
Decrypt the signature
The client decrypts the certificate's signature value using the CA's public key to recover the original hash.
3
Recompute the hash
The client independently hashes the TBSCertificate data using the algorithm specified in signatureAlgorithm.
4
Compare hashes
If the decrypted hash matches the recomputed hash, the CA's signature is valid — the certificate has not been tampered with.
5
Repeat up the chain
The client repeats this process for the issuing CA certificate (validated against the Root CA) until the Root CA is reached.
Security Consideration
The CA private key is the root of all signature trust
Every certificate in the hierarchy is trusted because of the CA's digital signature. If the CA private key is compromised, an attacker can sign fraudulent certificates that pass signature validation. This is why Root CA private keys are kept offline and protected by HSMs — the entire trust model depends on their integrity.
F
Where Digital Signatures Appear in PKI
Digital signatures are not limited to certificates. They appear throughout the PKI ecosystem wherever integrity and authenticity must be proven.
X.509 Certificates
Every certificate is signed by the issuing CA. The signature binds the public key to the subject identity.
Certificate Revocation Lists (CRLs)
CRLs are signed by the CA. Clients verify the CRL signature before trusting the revocation data.
OCSP Responses
OCSP responses are signed by the OCSP responder. Clients verify the signature to ensure the response has not been tampered with.
Code Signing
Executables, scripts, drivers, and packages are signed with code signing certificates. Windows verifies the signature before execution.
S/MIME Email
Email messages are signed with S/MIME certificates. Recipients verify the signature to confirm the message has not been modified.
Authenticode
Microsoft's code signing standard. Drivers, Windows updates, and software installers are signed and verified via Authenticode.
TLS Handshake
During TLS, the server signs a portion of the handshake with its private key. The client verifies the signature to confirm the server holds the private key matching the certificate.
Timestamping
A Timestamp Authority (TSA) signs a timestamp token proving that a signature existed at a specific time — allowing signed code to remain valid after the signing certificate expires.
G
Enterprise Example: Northstar Manufacturing
Here is how hash functions and digital signatures work in a real Northstar Manufacturing code signing scenario:
Northstar — PowerShell Script Signing Flow
1
Developer signs the deployment script
The developer runs Set-AuthenticodeSignature on deploy.ps1 using their code signing certificate. Windows hashes the script with SHA-256 and encrypts the hash with the developer's private key.
2
Signature is embedded in the script
The digital signature block is appended to the script file. The script is now signed and ready for deployment.
3
Script is deployed to production servers
The signed script is copied to 200 production servers via a deployment pipeline.
4
Windows verifies the signature before execution
PowerShell execution policy is set to AllSigned. Before running the script, Windows verifies the signature: decrypts the hash with the developer's public key, recomputes the hash of the script, compares them.
5
Tampered script is blocked
An attacker modifies one line of the script on a compromised server. When Windows verifies the signature, the hashes do not match. Execution is blocked and an alert is generated.
H
PKI Engineer Notes
Common Mistake
Auditing for SHA-1 in your PKI
Run
certutil -store -enterprise Root and certutil -store -enterprise CA to list CA certificates and their signature algorithms. Any certificate showing sha1RSA must be replaced. Also check CRL signing algorithms — a SHA-256 certificate signed by a SHA-1 CRL is still a SHA-1 dependency.Security Consideration
Timestamping code signatures is not optional
Without a timestamp, a signed executable becomes untrusted the moment the signing certificate expires. With a valid RFC 3161 timestamp from a trusted Timestamp Authority, the signature remains valid indefinitely — even after the signing certificate expires. Always timestamp code signatures in production. Use a public TSA (DigiCert, Sectigo, GlobalSign) or your own internal TSA.
Production Note
CRL signature algorithm must match your CA certificate
When you renew a CA certificate with a new key and algorithm, the CRL signing algorithm must also be updated. A mismatch between the CA certificate signature algorithm and the CRL signature algorithm can cause validation failures on strict clients. Test CRL validation after any CA renewal.
Key Concept
Post-quantum cryptography will change hash and signature algorithms
Current digital signature algorithms (RSA, ECDSA) are vulnerable to quantum computers running Shor's algorithm. NIST has standardized post-quantum signature algorithms: ML-DSA (CRYSTALS-Dilithium), SLH-DSA (SPHINCS+), and FN-DSA (FALCON). Hash functions (SHA-256, SHA-384) are considered quantum-resistant with doubled output sizes. PKI migrations to post-quantum algorithms will be covered in the Post-Quantum Cryptography module.
Key Terms Glossary
Hash Function
A one-way mathematical algorithm that produces a fixed-size output (hash/digest) from any input. The same input always produces the same output. Cannot be reversed.
Hash / Digest / Fingerprint
The fixed-size output of a hash function. Used interchangeably. Represents the "fingerprint" of the input data.
SHA-2
Secure Hash Algorithm 2 — a family of hash functions including SHA-256, SHA-384, and SHA-512. The current standard for PKI. SHA-256 is the minimum for new deployments.
SHA-1
An older hash algorithm now deprecated for PKI use. Collision attacks have been demonstrated. Must not be used for new certificates, signatures, or CRLs.
MD5
A broken hash algorithm. Collisions are trivially computed. Must never be used in PKI or any security context.
Collision
When two different inputs produce the same hash output. A collision attack exploits this to forge signatures or certificates. SHA-1 and MD5 are vulnerable to collision attacks.
Digital Signature
A cryptographic value created by hashing data and encrypting the hash with a private key. Verified using the matching public key. Proves integrity, authenticity, and supports non-repudiation.
Integrity
The assurance that data has not been modified. A valid digital signature proves the signed data is unchanged since it was signed.
Authenticity
The assurance that data came from the claimed source. A valid digital signature proves the signer holds the private key associated with the signing certificate.
Non-repudiation
The inability of a signer to deny having signed data. Because only the private key holder can create a valid signature, the signer cannot later claim they did not sign it.
TBSCertificate
To-Be-Signed Certificate — the portion of an X.509 certificate that the CA hashes and signs. Contains the subject, issuer, public key, validity period, and extensions.
Certificate Signature Algorithm
The algorithm field in an X.509 certificate that identifies the hash and signature algorithm used by the CA to sign the certificate (e.g., sha256WithRSAEncryption).
Knowledge Check
Question 1 of 5
Which of the following best describes a cryptographic hash function?
Question 2 of 5
A CA signs a certificate. What exactly does the CA sign?
Question 3 of 5
Which hash algorithm is deprecated and must NOT be used for new PKI certificates or signatures?
Question 4 of 5
A developer signs a PowerShell script. An attacker later modifies one line of the script. What happens when Windows attempts to verify the signature?
Question 5 of 5
Which three security properties does a valid digital signature provide?
Lesson Completion
Downloads
Hash Functions & Signatures Quick Reference
Hash algorithm comparison, signing/verification flows, and certificate signature validation steps.
Coming Soon
Module 1 Lessons
Your Progress
Not yet complete
2 of 18 lessons complete (est.)