Asymmetric encryption, hashing, and digital signatures solve two fundamental problems that symmetric encryption alone cannot: how to securely share a secret key over an insecure channel, and how to prove that a message truly came from a specific person and was not altered in transit. For an SSCP candidate, understanding these concepts is critical because they underpin secure email, HTTPS websites, code signing, and the entire public key infrastructure (PKI) that keeps modern business communication safe.
Jump to a section
A simple way to picture Asymmetric Encryption, Hashing, and Digital Signatures
1250 kilometres. That is the distance your sealed diary travels when you send it from London to Edinburgh by courier. You and your friend each own a unique diary with a special lock. Your lock has two keys: one that only you can use to lock it (your private key), and one that you give to everyone (your public key). Your friend has the same setup.
When you write a secret message, you do not use your own lock to seal it. Instead, you ask your friend to send you their public lock-key. You use that to lock your diary, so only your friend can open it with their private key. This is asymmetric encryption: the key to lock is different from the key to unlock.
But how does your friend know the message truly came from you? This is where hashing comes in. Before you lock the diary, you write a summary of your message—a unique, short fingerprint—using a special formula (a hash algorithm). You then lock that summary in a small, separate box using your own private key. This sealed fingerprint is your digital signature.
When your friend receives the locked diary, they first unlock the main message with their private key. Then they use your public key to open the small box and read the fingerprint. They independently run the same formula on your message to create a new fingerprint. If both fingerprints match, they know two things: the message was not tampered with during the 1250-kilometre journey (integrity), and it truly came from you, because only you could seal that fingerprint with your private key (authenticity and non-repudiation).
To understand asymmetric encryption, hashing, and digital signatures, you must first understand the problem they solve. Imagine you want to send a secret message to a colleague in another city. If you both share the same key to lock and unlock the message, that is symmetric encryption. The problem is: how do you get that shared key to your colleague safely? If an attacker intercepts the key during transmission, they can read all your future encrypted messages. Asymmetric encryption eliminates this problem entirely.
Asymmetric encryption (also called public-key cryptography) uses two mathematically related but different keys: a public key and a private key. The public key can be shared with anyone—it is like a lock that anyone can use to seal a message. The private key is kept secret by its owner—it is the only key that can open messages locked with the corresponding public key. This means anyone can send you an encrypted message using your public key, but only you can decrypt it using your private key. The most common algorithms in use today include RSA (Rivest-Shamir-Adleman, named after its inventors) and Elliptic Curve Cryptography (ECC). RSA relies on the difficulty of factoring large prime numbers, while ECC relies on the mathematics of elliptic curves. Both achieve the same goal: secure communication without sharing a secret key beforehand.
Hashing is a completely different concept. A hash function takes any input data—a password, a document, a video file—and produces a fixed-size string of characters, called a hash value or digest. The hash is a fingerprint of the data. Good hash functions have four essential properties:
Deterministic: the same input always produces the same hash output.
Fast to compute: generating the hash from any input is very quick.
Preimage resistant: given a hash value, it is computationally infeasible to find any input that produces that hash (one-way function).
Collision resistant: it is extremely unlikely that two different inputs produce the same hash value.
Common hash algorithms include SHA-256 (Secure Hash Algorithm with 256-bit output) and SHA-3. Hashing is not encryption—you cannot 'decrypt' a hash back to the original data. It is used to verify integrity: if you compute the hash of a downloaded file and it matches the hash published by the software vendor, you know the file was not tampered with during download.
A digital signature combines asymmetric encryption and hashing to provide authenticity, integrity, and non-repudiation. Here is how it works step by step:
The sender creates a message (e.g., a contract).
The sender runs the message through a hash function to produce a hash digest.
The sender encrypts that hash digest with their own private key. This encrypted hash is the digital signature.
The sender sends the original message and the digital signature to the recipient.
The recipient uses the sender's public key to decrypt the digital signature, recovering the hash digest.
The recipient independently computes the hash of the received message.
If the two hash values match, the recipient knows the message was not altered and it genuinely came from the sender.
Non-repudiation means the sender cannot later deny having signed the message, because only they possess the private key that created the signature.
Digital certificates are the final piece of the puzzle. A digital certificate is an electronic document that binds a public key to an identity (a person, organisation, or device). It is issued by a trusted third party called a Certificate Authority (CA). When you visit a secure website (HTTPS), the server presents its digital certificate. Your browser checks that the certificate was signed by a trusted CA, that it has not expired, and that the domain name matches. If all checks pass, your browser uses the public key from the certificate to establish an encrypted session. This entire system is called Public Key Infrastructure (PKI).
Key management is a major concern for IT professionals. Private keys must be stored securely—often in hardware security modules (HSMs) or trusted platform modules (TPMs). If a private key is compromised, the attacker can decrypt all messages intended for that key holder and forge digital signatures. That is why certificate revocation lists (CRLs) and the Online Certificate Status Protocol (OCSP) exist: to check whether a certificate has been revoked before its expiration date.
Key Pair Generation
The user (or system) generates a mathematically linked public key and private key pair using an algorithm such as RSA or Elliptic Curve Cryptography. The private key is stored securely and never shared, while the public key is freely distributed.
Message Hashing
The sender applies a cryptographic hash function (e.g., SHA-256) to the original message. This produces a fixed-size digest that uniquely represents the message content. Any change in the message produces a completely different digest.
Digital Signature Creation
The sender encrypts the hash digest with their own private key. The resulting encrypted digest is the digital signature. This step binds the sender's identity to the message because only the sender possesses the private key.
Transmission of Message and Signature
The sender transmits the original message along with the digital signature to the recipient. The message itself may be in plain text or encrypted separately for confidentiality, but the signature travels alongside.
Signature Verification
The recipient uses the sender's public key to decrypt the digital signature, recovering the original hash digest. The recipient then independently computes the hash of the received message. If both digests match, the message is authentic and unaltered; if they differ, the message was tampered with or the signature is invalid.
An IT professional deals with asymmetric encryption, hashing, and digital signatures daily, often without thinking about it. Consider the scenario of a financial services firm onboarding a new client via a secure web portal.
First, the IT security engineer ensures the company's web server has a valid TLS (Transport Layer Security) certificate. The engineer generates a private key on the server, then creates a Certificate Signing Request (CSR) containing the public key and company details. The CSR is sent to a trusted CA like DigiCert or Let's Encrypt. The CA verifies the company's identity and issues a digital certificate signed with the CA's private key. The engineer installs this certificate and its matching private key on the web server. When a client visits the portal (e.g., https://secure.firm.com), their browser performs the TLS handshake:
The server sends its digital certificate.
The browser verifies the certificate chain (checking signatures up to a trusted root CA).
The browser generates a session key for symmetric encryption and encrypts it with the server's public key.
Only the server can decrypt this session key with its private key.
The rest of the session uses fast symmetric encryption.
Meanwhile, the IT engineer sets up email signing for client communications. Using a tool like Microsoft Outlook or GnuPG, the engineer generates an S/MIME (Secure/Multipurpose Internet Mail Extensions) certificate linked to the company email domain. Every outgoing email to the client is hashed and signed with the engineer's private key. The client's email client verifies the signature using the engineer's public key, confirming the email was genuinely sent by the firm and not modified by a phishing attacker.
For internal security, the IT team uses hashing to verify software integrity. Before deploying a critical patch from a vendor, the engineer downloads the file and computes its SHA-256 hash using a command like: certutil -hashfile patch.exe SHA256. They compare this hash to the one published on the vendor's website. If the hashes match, the file has not been tampered with. If they differ, the engineer investigates immediately—a mismatch could indicate a malicious file injected during the download.
The engineer also manages digital certificates for code signing. When the firm develops its own mobile app, the engineer signs the application binary with a private key from a code-signing certificate. The mobile operating system (iOS or Android) verifies this signature before allowing the app to run. This prevents users from installing trojan horse versions of the app that have been modified by attackers.
Finally, the engineer monitors certificate expiration dates. If an SSL/TLS certificate expires, users will see a browser warning that the connection is not private—damaging client trust. The engineer uses tools like Certify (for Windows) or certbot (for Linux) to automate renewal. They also maintain a Certificate Revocation List (CRL) distribution point and ensure OCSP stapling is enabled for faster revocation checks.
In summary, an IT professional's daily tasks with these technologies include:
Generating and installing TLS certificates for web servers.
Enabling S/MIME or PGP (Pretty Good Privacy) for email signing and encryption.
Verifying file hashes before installing software.
Signing application code to ensure authenticity.
Managing private key storage in HSMs or secure vaults.
Monitoring certificate expiration and automating renewals.
Configuring OCSP and CRL distribution.
The SSCP exam tests your understanding of asymmetric encryption, hashing, and digital signatures primarily through scenario-based questions and definition-matching items. You will not be asked to perform mathematical calculations or write cryptographic code. Instead, you must recognise when each technology is appropriate and understand their security properties.
The exam loves to test the following concepts:
Symmetric vs. asymmetric encryption: You must know that symmetric encryption (e.g., AES) is faster and used for bulk data encryption, while asymmetric encryption (e.g., RSA) is slower and used for key exchange and digital signatures. A typical question describes a performance constraint and asks which should be used.
Hash properties: Expect at least one question about collision resistance (two inputs producing the same hash) and preimage resistance (inability to reverse a hash). They might ask: 'Which property ensures an attacker cannot find a different message with the same hash?'
Digital signature process: You must be able to order the steps correctly: hash the message, encrypt the hash with the sender's private key, send message and signature, decrypt with sender's public key, compare hashes. A wrong answer often suggests encrypting the entire message with the private key, which is not standard.
Non-repudiation: This is a keyword. Questions will ask which technology provides non-repudiation—the answer is digital signatures, because only the signer possesses the private key.
Certificate Authority roles: Know the difference between a root CA (self-signed, top of trust chain), an intermediate CA (signed by root, issues end-entity certificates), and a registration authority (verifies identity before CA issues certificate).
Public Key Infrastructure (PKI) components: The exam tests components like Certificate Revocation Lists (CRLs), OCSP, digital certificates (X.509 standard), and certificate policies. A question may ask: 'What is used to check if a certificate is still valid before its expiration?' Answer: OCSP or CRL.
Key management: You should know that private keys must never be shared, while public keys can be freely distributed. Questions about key compromise will test your understanding of revocation and reissuance.
Common traps and answer patterns:
Trap: A question asks which encryption method provides 'confidentiality and non-repudiation'. Many candidates choose 'symmetric encryption' because they know it provides confidentiality, but symmetric encryption does not provide non-repudiation. The correct answer is 'asymmetric encryption with digital signatures'.
Trap: The question describes using a private key to encrypt data and a public key to decrypt. Beginners think this is wrong, but it is exactly how digital signatures work. The exam expects you to know that encryption with a private key provides authentication, not confidentiality (since anyone with the public key can decrypt).
Trap: Hashing is confused with encryption. A question might ask: 'Which algorithm is used to ensure data integrity?' Some test-takers choose AES. The correct answer is a hash algorithm like SHA-256.
Trap: The exam might list RSA, DES, and MD5. It asks which is used for encryption. DES is symmetric encryption, RSA is asymmetric encryption, and MD5 is an outdated hash. Know these categories.
Key definitions to memorise exactly:
Symmetric encryption: single shared key for encryption and decryption.
Asymmetric encryption: pair of keys (public and private).
Hash function: one-way mathematical function producing a fixed-size digest.
Digital signature: encrypted hash of a message using the sender's private key.
Certificate Authority (CA): trusted entity that issues and manages digital certificates.
Non-repudiation: inability to deny having performed an action (e.g., signing).
Collision: when two different inputs produce the same hash output.
Finally, be prepared for questions that ask which algorithm is appropriate for a specific use case. For example: 'Which algorithm would you use to encrypt a large file for storage?' Answer: AES (symmetric). 'Which would you use to verify the authenticity of a downloaded update?' Answer: a digital signature (e.g., using RSA to verify the signature against a hash).
Symmetric encryption uses a single shared key for both encryption and decryption, while asymmetric encryption uses a matched pair of a public key and a private key.
A hash function produces a fixed-size digest that acts as a unique fingerprint of data, and it is a one-way operation that cannot be reversed.
A digital signature is created by encrypting the hash of a message with the sender's private key, providing authenticity, integrity, and non-repudiation.
Public Key Infrastructure (PKI) relies on Certificate Authorities (CAs) to issue digital certificates that bind public keys to verified identities.
Asymmetric encryption is computationally slow, so it is typically used only to exchange a session key for faster symmetric encryption.
Non-repudiation is provided only by digital signatures because only the signer possesses the private key that created the signature.
These come up on the exam all the time. Here's how to tell them apart.
Symmetric Encryption
Uses one shared key for both encryption and decryption
Faster and suitable for bulk data encryption (e.g., AES)
Does not provide non-repudiation on its own
Asymmetric Encryption
Uses a mathematically linked public-private key pair
Slower, ideal for key exchange and digital signatures (e.g., RSA)
Provides non-repudiation through digital signatures using the private key
Hash Function
One-way operation; irreversible
Produces a fixed-size digest regardless of input size
Used for integrity verification and password storage
Encryption Algorithm
Two-way operation; reversible with the correct key
Output size varies based on input and algorithm (e.g., AES block size)
Used for confidentiality of data
Digital Signature
Uses asymmetric keys (private key to sign, public key to verify)
Provides non-repudiation because only the signer has the private key
Does not require a shared secret between parties
Message Authentication Code (MAC)
Uses a symmetric key shared between sender and receiver
Does not provide non-repudiation; both parties can compute the MAC
Requires a pre-shared secret key
Certificate Authority (CA)
Issues and signs digital certificates
Operates the root infrastructure and manages certificate revocation
Is the ultimate trust anchor in PKI
Registration Authority (RA)
Verifies the identity of certificate requestors
Does not issue certificates itself; forwards requests to the CA
Acts as a gatekeeper for identity validation
Mistake
Asymmetric encryption is always better than symmetric encryption because it uses two keys.
Correct
Asymmetric encryption is slower and computationally more expensive than symmetric encryption. In practice, systems use asymmetric encryption to securely exchange a temporary symmetric key, then use symmetric encryption for the actual data.
The two-key concept sounds more secure, so beginners assume it must replace symmetric encryption entirely, not understanding the performance trade-off.
Mistake
A hash can be decrypted to reveal the original message.
Correct
Hashing is a one-way function. You cannot 'decrypt' a hash to get the original data. Hashes are used for integrity checking, not confidentiality.
Because hashing outputs a seemingly random string, beginners confuse it with encryption, which can be reversed with the correct key.
Mistake
A digital signature encrypts the entire message with the sender's private key.
Correct
A digital signature encrypts only the hash of the message with the sender's private key. The original message may be sent in plain text or encrypted separately with a symmetric key.
The word 'signature' suggests you are marking the whole message, but cryptographic efficiency requires working with a fixed-size hash.
Mistake
If my public key is exposed, an attacker can decrypt all messages sent to me.
Correct
An exposed public key only allows others to encrypt messages to you or verify signatures you created. Decryption requires the private key, which must remain secret.
Beginners think that because the public key is 'public', it must weaken security. They forget the mathematical separation between the two keys.
Mistake
Digital certificates and public keys are the same thing.
Correct
A digital certificate is a document that binds a public key to an identity (e.g., a domain name or person) and is signed by a Certificate Authority. The public key is just one field inside the certificate.
The terms are used interchangeably in casual conversation, but the exam distinguishes between the key itself and the trusted document that vouches for it.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, the same RSA key pair can be used for both, but best practise is to use separate key pairs for encryption and signing to limit exposure if one is compromised.
If a private key is compromised, anyone with that key can decrypt messages intended for you and forge your digital signature. You must immediately revoke the associated digital certificate and generate a new key pair.
Encryption is a two-way process: encrypted data can be decrypted back to the original using a key. Hashing is a one-way process: given a hash, you cannot recover the original input. Hashes also produce fixed-length output regardless of input size.
SHA-256 stands for Secure Hash Algorithm with a 256-bit output. The 256 indicates the digest length (32 bytes), which provides strong collision resistance for modern security requirements.
The browser checks that the certificate is signed by a trusted Certificate Authority (CA) included in its root store, verifies the domain name matches, confirms the certificate is not expired, and checks revocation status via OCSP.
A Certificate Revocation List (CRL) is a periodically published list of revoked certificates that a client downloads and checks against. OCSP (Online Certificate Status Protocol) provides a real-time check of a single certificate's status without downloading a full list.
You've finished Asymmetric Encryption, Hashing, and Digital Signatures. Continue through the SSCP study guide to build a complete picture of the exam.
Done with this chapter?