Hashing, digital signatures, obfuscation and blockchain
Objective 1.4 in this course covers cryptographic solutions. The previous lesson took PKI, encryption and key management; this one takes the remaining items in CompTIA's scope note for it — hashing, digital signatures, obfuscation and blockchain — plus the certificate types you will meet in Domain 3.
Why this matters
Three of the four things in this lesson are routinely confused with encryption, and the exam knows it. Hashing is not encryption. Obfuscation is not encryption. A signature is not encryption of the message. Each has a property the others lack, and the questions are built on exactly those differences.
This is also the domain-1 capstone lesson, so it is where the cryptography threads from the previous lesson get pulled together into decisions.
The lesson
What a hash proves, what it does not, and why salting exists
A hash function takes input of any size and produces a fixed-size digest. Three properties matter:
- Deterministic — the same input always gives the same digest.
- One-way — you cannot recover the input from the digest.
- Collision resistant — it should be infeasible to find two inputs with the same digest.
What a hash proves is integrity: if the digest matches, the data has not changed. What it does not prove is authenticity — anyone can compute a hash, so a matching digest tells you nothing about who produced the data. If an attacker can change the file, they can usually change the published digest too. That is why download pages that publish a hash next to the file on the same server provide almost nothing, and why signed hashes (the next section) are the real control.
Know SHA-2 (SHA-256, SHA-512) as the current default and SHA-1 and MD5 as deprecated — both have practical collision attacks and appear in questions as the wrong answer.
Salting exists because hashing is deterministic. If two users have the same password, their stored hashes are identical, and a precomputed table (a rainbow table) maps common digests back to their inputs instantly. A salt is a unique random value stored alongside each hash and mixed into it before hashing: identical passwords now produce different digests, and precomputed tables are useless because they would have to be rebuilt per salt. Salting defeats precomputation, not guessing — which is why you also need key stretching from the previous lesson.
A related term: a HMAC combines a hash with a secret key, so the digest can only be produced or verified by someone holding the key. That adds authenticity to integrity, between parties who share a secret.
Digital signatures: integrity, authenticity and non-repudiation in one operation
A digital signature is the hash of the message, encrypted with the signer's private key.
Verification runs the same steps in reverse: the recipient decrypts the signature with the signer's public key to recover the digest, hashes the message themselves, and compares. If they match, three things are true at once:
- the message has not changed — integrity;
- it was signed by the holder of that private key — authenticity;
- and the signer cannot credibly deny it — non-repudiation.
Note what is not true: the message is not confidential. Signing and encrypting are separate operations, and a question describing a signed message as protected from eavesdroppers is wrong.
Hashing first is not an optimisation detail worth memorising, but the reason is testable: asymmetric operations are slow, so you sign a small fixed-size digest rather than the whole document.
Code signing is the everyday application. A signed installer lets the operating system verify both that the publisher is who they claim and that the bytes have not been altered since. It is also why a stolen code-signing key is such a severe compromise — you meet that again under supply chain attacks in Domain 2.
Steganography, tokenisation and data masking, and how they differ from encryption
These three are obfuscation: making data harder to read or less useful, by means other than encryption.
- Steganography hides the existence of the data, typically inside another file — an image, an audio track, a video, or unused space in a network packet. Encryption says "here is a secret you cannot read"; steganography says "there is nothing here". Its weakness is that the payload is not necessarily protected once found, so it is usually combined with encryption.
- Tokenisation replaces a sensitive value with a meaningless substitute — a token — and keeps the mapping in a separate, heavily protected vault. The card number never enters the application database at all. The crucial property, and the one the exam tests: there is no key and no mathematical relationship, so a stolen token database cannot be decrypted. It can only be resolved by the vault.
-
Data masking replaces part or all of a value with placeholder characters —
**** **** **** 4471. It is for display and for non-production environments. It is usually irreversible by design, and that is the point: developers get realistically shaped data without holding real data.
Where each belongs: tokenisation for storing and processing payment data, masking for test environments and screens, encryption when you need the original back with a key, steganography almost never in enterprise defence — you are more likely to meet it as an exfiltration technique in Domain 2.
The open public ledger, and the narrow set of problems it is the answer to
A blockchain is an append-only ledger, distributed across many participants, where each block contains a hash of the block before it. Changing an old record changes its hash, which breaks every subsequent block, and the other copies disagree. Consensus among participants decides what gets added.
What it gives you: a tamper-evident record that no single participant owns, with a verifiable history. The open public ledger phrase is CompTIA's, and "public" is doing real work — the resilience comes from many independent parties holding copies.
What it does not give you: confidentiality (a public ledger is public), correctness of what was written (it faithfully records nonsense), speed, or any advantage at all when one organisation controls every copy — at which point a database with good access control and signed audit logs is simpler and better.
The honest exam framing: blockchain fits where multiple mutually distrusting parties need a shared record and there is no acceptable trusted intermediary. Supply-chain provenance and distributed identity are the examples CompTIA uses. If a scenario has a single trusted owner, blockchain is the wrong answer.
Certificates, wildcard and SAN, and self-signed versus third-party
Finishing the PKI thread from the previous lesson, because these appear in Domain 3 and Domain 4 scenarios:
- A wildcard certificate (
*.example.com) covers any single-level subdomain. It is convenient and it concentrates risk: one stolen private key compromises every host using it, and it does not covera.b.example.com. - A subject alternative name (SAN) certificate lists several specific names — which may be different domains entirely. More work to issue, far less blast radius, and it is the right answer when the names are known and few.
- A self-signed certificate is signed with its own key, so nothing vouches for it. Encryption still works; identity assurance does not, and clients warn. It is legitimate for internal systems where you control the trust store, and it is the wrong answer for anything the public reaches.
- A third-party certificate from a public CA is what public services need, precisely because the client already trusts the CA.
Two operational points that generate incidents: certificates expire, and expiry causes outages that look like network faults; and a certificate is only as trustworthy as the private key, so a key on a shared file server is a compromised certificate waiting to be noticed.
What to take into the exam
- Hashing gives integrity only. Signing gives integrity, authenticity and non-repudiation. Neither gives confidentiality.
- Salting defeats precomputed tables; key stretching defeats fast guessing. They solve different problems and are used together.
- Tokenisation has no key and no reversible relationship — that is what distinguishes it from encryption, and why the token store is worthless alone.
- Masking is for display and test data and is normally irreversible.
- Blockchain answers "several distrusting parties, no trusted intermediary". One owner means use a database.
- Wildcard = one key covering many subdomains and therefore concentrated risk; SAN = named hosts, smaller blast radius.
Practise what you just read
1. A download page publishes a SHA-256 digest beside the file, on the same server. What does the digest prove?
Select one
Show answer
B. A hash gives integrity only if the reference value is protected independently. Published on the same server as the file, both can be changed together. A signed digest is the real control, because forging it requires the publisher's private key.
2. What does salting a password hash defeat?
Select one
Show answer
B. A unique salt per password means identical passwords produce different digests, so precomputed tables would have to be rebuilt for every salt. It does not slow an individual guess, which is what key stretching addresses, and it does nothing about a password that is simply weak.
3. Which property distinguishes tokenisation from encryption?
Select one
Show answer
C. A token is a meaningless substitute, and the mapping lives in a separate vault. A stolen token database cannot be decrypted because there is nothing to decrypt; it can only be resolved by the vault. That is why tokenisation is the pattern for card data.
8 more questions on this objective are part of the full course.
Hands-on labs
Part of the free CompTIA Security+ SY0-701 course — 47 lessons and 79 hands-on labs.
This is an independent study companion for CompTIA Security+ SY0-701 and is not produced by or endorsed by CompTIA.