RANGER GAMEZ

CompTIA Security+ (SY0-701) · chapter 6 of 27

Week 3: Hashes, signatures and certificates

In this chapter Objectives 1.4

  1. Hashing, salting and key stretching
  2. Digital signatures and blockchain
  3. Certificates
  4. Chapter recap

Objective 1.4

Hashing, salting and key stretching

Hashing

Hashing runs data through a one-way function that produces a fixed-length digest (a fingerprint). The same input always gives the same hash; change one character and the hash changes completely; you can't turn a hash back into the input. Uses: checking file integrity, storing passwords, building digital signatures. Use SHA-256 or stronger. MD5 and SHA-1 are broken for collision resistance, so don't use them for security.

"Dog bed 49.99" -> SHA-256
  aa5d5ec8cb55d0f5...5072fd61
"Dog bed 0.99"  -> SHA-256
  5f0649b6fda1177d...45a5fcfa
Hashing as a one-way machine. The text "Dog bed 49.99" goes into SHA-256 and comes out as a fixed-length digest beginning aa5d5ec8. Changing one character, "Dog bed 0.99", gives a completely different digest beginning 5f0649b6. An arrow back from digest to text is crossed out: there is no key and no way to reverse a hash. Uses: file integrity, password storage, digital signatures.
Same input, same hash; change one character and the hash changes completely; no way back.

Exam tip Hashing is NOT encryption: there is no key and no way back. If an option says "decrypt the hash", it's wrong.

Salting

Many users pick the same password, so plain hashes would match, and attackers use rainbow tables (precomputed hashes) to look them up. A salt is a random value added to each password before hashing, stored next to the hash. Same password plus different salt equals a different hash, so precomputed tables become useless and every password must be attacked separately.

Two users, Rosa and Tomas, both choose the password "Ranger1". Without salt, their stored hashes would be identical. Each gets a different random salt, so "Ranger1" plus salt 7f3a and "Ranger1" plus salt c91e produce two completely different hashes, which makes precomputed rainbow tables useless. The salt is stored next to the hash; it must be random and unique, not secret.
Same password + different random salt = different hash; rainbow tables stop working.

Exam tip Salt defeats rainbow tables and hides identical passwords. It doesn't need to be secret; it needs to be random and unique per password.

Key stretching

Key stretching makes a weak secret (like a password) stronger by running it through a hash or cipher many thousands of times, so every guess costs the attacker much more time. Examples: PBKDF2 and bcrypt (scrypt and Argon2 also add memory cost). One login check takes a fraction of a second for a user; billions of guesses become impractical.

Exam tip Salting stops precomputed attacks; key stretching slows brute force. Good password storage uses both.

Objective 1.4

Digital signatures and blockchain

How a digital signature works

To sign, the sender hashes the message and encrypts that hash with their private key: that is the digital signature. The receiver decrypts the signature with the sender's public key and compares it with their own hash of the message. A match proves integrity (not changed), authentication (from the key owner) and non-repudiation (only they hold the private key).

SIGN:
  hash(msg) --private key--> signature
VERIFY:
  signature --public key--> hash A
  hash(received msg) -----> hash B
  A == B ? valid : tampered/forged
Digital signature in two halves. Signing: the sender hashes the message and encrypts that hash with the sender's private key; the result is the signature, sent with the message. Verifying: the receiver decrypts the signature with the sender's public key to get hash A, hashes the received message to get hash B, and compares; if A equals B the message is unchanged and came from the key owner, giving integrity, authentication and non-repudiation.
Sign with the sender's private key; verify with the sender's public key and compare hashes.

Exam tip Signature = sender's PRIVATE key to sign, sender's PUBLIC key to verify. Encryption to someone = recipient's PUBLIC key.

Blockchain and the open public ledger

A blockchain is a distributed ledger of transactions grouped into blocks; each block contains the hash of the previous one, so changing any old block breaks every hash after it. An open public ledger means every participant holds a copy and can verify it, so there is no single place to tamper with. Uses: cryptocurrency, supply-chain tracking, digital voting, title records.

Exam tip Blockchain's security value is integrity (tamper evidence) through hashing plus many copies, not confidentiality.

Check yourself 1An attacker steals the shop's password database. Each hash was built from the password plus a unique random value. What does this random value mainly defeat?

  1. Rainbow table attacks
  2. Collision attacks
  3. Protocol downgrade attacks
  4. Replay attacks
Show the answer

Answer: A. Rainbow table attacks

A unique salt per password makes precomputed rainbow tables useless and gives identical passwords different hashes. It doesn't stop collisions, which are a weakness of the hash algorithm itself.

Objective 1.4

Certificates

CAs, third-party and self-signed

A digital certificate binds a public key to an identity and is signed by a certificate authority (CA). A third-party (public) CA is already trusted by browsers and operating systems, so use it for public sites like the online shop. A self-signed certificate is signed by its own key: fine for testing or internal use if you deploy trust yourself, but browsers warn because nothing they trust vouches for it. Many companies run their own internal CA for internal sites.

Exam tip Clue: issuer = subject means self-signed.

Root of trust and the chain

A root of trust is the component everything else relies on and that is trusted by default. In PKI it is the root CA certificate in the device's trust store; in hardware it is a TPM, HSM or secure enclave. Trust flows down a chain: root CA signs an intermediate CA, which signs the server certificate. If the chain doesn't reach a trusted root, the browser warns.

Root CA (trust store, self-signed)
 \-- Intermediate CA (signed by root)
      \-- shop.kibbleco.example
          (signed by the intermediate)
A certificate chain as three linked certificates. At the top, the root CA certificate, self-signed and stored in the device's trust store; its private key is kept offline or in an HSM. It signs the intermediate CA certificate, which signs the server certificate for shop.kibbleco.example. A browser trusts the site only if the chain reaches a trusted root.
Root CA signs the intermediate, the intermediate signs the server: trust flows down.

Exam tip Root CA private keys are kept offline or in an HSM, because a stolen root key breaks trust in everything below it.

CSR generation and wildcards

CSR generation: you create a key pair, then a certificate signing request with the public key and identity details (common name, SANs, organization) signed with your private key. The CA checks it and returns a signed certificate. The private key never leaves your server. A wildcard certificate like *.kibbleco.example covers any single-level name such as shop. or mail. but not the bare domain or deeper names like a.b.kibbleco.example (those need SAN entries).

Exam tip Trap: if anyone asks you to send the private key to the CA, something is wrong.

Revocation: CRL and OCSP

A certificate can be revoked before it expires, for example if its private key is stolen. A certificate revocation list (CRL) is a list of revoked serial numbers that the CA publishes; clients download the whole list periodically. Online Certificate Status Protocol (OCSP) lets a client ask about one certificate and get good, revoked or unknown in real time. With OCSP stapling the server attaches a fresh, CA-signed OCSP response to the handshake.

Two ways to check whether a certificate was revoked. CRL: the client downloads the CA's whole certificate revocation list on a schedule and looks for the serial number. OCSP: the client asks the CA's OCSP responder about one certificate and gets good, revoked or unknown right away. With OCSP stapling, the server attaches a fresh, CA-signed OCSP answer to its handshake.
CRL = download the whole list; OCSP = ask about one certificate now.

Exam tip CRL = the whole list, downloaded on a schedule. OCSP = ask about one certificate, right now.

Check yourself 2Dev needs a certificate for the online shop from a public CA. Which item does he send to the CA?

  1. The server's private key
  2. A certificate revocation list
  3. A certificate signing request
  4. An OCSP response
Show the answer

Answer: C. A certificate signing request

A CSR contains the public key and identity details, signed with the private key. The private key itself never leaves the server.

Practice it in Ranger's Cyber PatrolThe same lessons as a story, with drills, hands-on labs and mock exams. Free, in your browser.
Play free

CompTIA, A+, Network+, Security+ and Linux+ are trademarks of CompTIA, Inc. Ranger Gamez is not affiliated with or endorsed by CompTIA. The practice questions are written to the published exam objectives; they are not real exam questions.