11.2 Hashing, Salting, Symmetric, Asymmetric, and ECC

Apply cryptography concepts: start with the primitive, not the product name

Knowledge area 5.2 is Apply cryptography concepts. The first cluster on the October 2025 outline is hashing, salting, and symmetric / asymmetric encryption / elliptic curve cryptography (ECC). Product marketing will say "the VPN is encrypted" or "the database is hashed." The CAT item will ask whether that sentence is even using the right primitive.

This section stays on those primitives and on the operations choice among them. Digital signatures, HMAC as a non-repudiation cousin, algorithm strength, and cryptanalysis continue in 11.3. Public key infrastructure and protocol use cases are Domain 5.3–5.4.

Hashing

A cryptographic hash function maps arbitrary input to a fixed-length digest. Properties you must be able to name in operations language:

• One-way (preimage resistance): given the digest, you cannot recover the original file or password in feasible time.
• Deterministic: the same input always yields the same digest, which is why hashes work as integrity fingerprints — and why unsalted password hashes leak equality.
• Avalanche: a one-bit change in the file changes the digest beyond recognition.
• Collision resistance: it should be infeasible to find two different inputs with the same digest. This is the property MD5 and SHA-1 lost.
• Second-preimage resistance: given this firmware image, it should be infeasible to craft a different image with the same digest.

Hashing is not encryption. There is no hash key that "decrypts" SHA-256(payroll.csv) back into the spreadsheet. If the exam stem wants confidentiality of that spreadsheet, hash is the wrong answer.

SHA-256 versus MD5 and SHA-1

A still-common operations failure is using MD5 to fingerprint firmware "because it is fast." Speed is the opposite of what you want against an attacker who will grind collisions. For password storage, even SHA-256 is the wrong construction if you hash the password once with no salt and no work factor — that is the next heading.

Scenario. Imaging laptops from win11-gold.iso. You publish the SHA-256 on an internal page that is itself TLS-protected and editable only by the build team. Before every imaging job, Get-FileHash must match. If someone swaps the ISO on the file server and you only compare MD5 printed on the same share, a collision-capable attacker (or a simple "edit both files" intern) can make a backdoored image verify. SHA-256 does not fix a digest stored next to the malware; it does stop cheap accidental and many adversarial collisions. Pair the hash with a trusted channel or a signature (11.3).

Salting and password storage

A salt is a unique, per-credential random value mixed into a password before (or as part of) hashing and then stored next to the hash. Salting is on the outline because password files are the hash use SSCP candidates most often get backward.

What salt does:

• Two users with Winter2026! no longer share a hash, so you cannot see reused passwords at a glance.
• Precomputed rainbow tables no longer apply to the whole database; the attacker must recompute per salt.
• A global company-wide salt (one value for every row) is a weak substitute. The outline's idea is per-password uniqueness.

What salt does not do:

• It is not a secret key. You store it in the clear beside the hash. Secrecy of the password file still matters, but the salt's job is uniqueness, not confidentiality.
• It does not slow a modern GPU much if you still use a single round of SHA-256. That is why production verifiers use a password-based key derivation function (KDF) with a work factor: PBKDF2, bcrypt, scrypt, or Argon2. Those constructions include salt. "Salted MD5" is still the wrong algorithm.

A pepper (a secret value stored outside the database, for example in an HSM) is extra defense in depth. It is not named on the SSCP outline. Do not spend a CAT item inventing peppers if the stem only asked for salt.

Scenario: password storage with salt. You inherit a Linux web app whose users table has password_hash char(32) filled with unsalted MD5. A dump from a SQL injection is instantly cracked. The SSCP remediation is not AES-encrypting the passwords so support can decrypt them on the phone. Login needs verification, not recovery. For each new or reset password: generate a unique cryptographically random salt, run Argon2id (or bcrypt / scrypt / PBKDF2 with a current iteration count), store algorithm, salt, hash, parameters. On login, repeat the same KDF and compare in constant time. Migrate old MD5 rows on next successful password entry. That is hashing plus salting as 5.2 means it.

Never roll a custom "hash then reverse the string" scheme. Never store the password encrypted under a single application key "so we can email it back." Those designs turn a hash problem into a key-management incident.

Symmetric encryption and AES

Symmetric encryption uses the same secret key to encrypt and decrypt. It is fast and is how you protect bulk data: disks, backups, TLS record payload, file shares.

AES (FIPS 197) is the algorithm the outline names later under strength, and it is the symmetric cipher you should expect in stems. AES is a 128-bit block cipher with three key sizes: 128, 192, and 256 bits. Those three numbers are standard practitioner facts, not an unpublished "SSCP exam length." All three key sizes remain acceptable in NIST guidance; many shops default to AES-256 for long-lived data or quantum-aware policy (Grover's algorithm effectively squares the cost of brute force, which is why 256-bit keys are the conservative choice for archives). Do not claim the exam requires AES-256 exclusively, and do not claim AES-128 is already broken.

Operational AES notes the SSCP actually hits:

• Mode matters. GCM (and other AEAD modes) provide confidentiality and integrity together. CBC needs a separate MAC. ECB leaks patterns (the classic penguin image) and is not an operations mode.
• Key distribution is the hard part. If every branch office needs the backup key, you now have an identity-and-key-management problem. That is why hybrid designs exist (below).
• Retired symmetric ciphers (DES, 3DES, RC4) are not AES. Seeing them in a packet capture is a finding.

Asymmetric encryption, RSA, and ECC

Asymmetric cryptography uses a key pair. The public key can be distributed. The private key stays in an HSM, TPM, smart card, or carefully permissioned file. Two directions matter:

• Encrypt with the recipient's public key → only the recipient's private key decrypts. Confidentiality toward that recipient.
• Sign with the sender's private key → anyone with the public key can verify. Authenticity and, with a well-managed key, non-repudiation (11.3).

RSA (Rivest–Shamir–Adleman) is the classic integer-factorization public-key scheme. Practitioner facts, not invented SSCP magic numbers:

• 1024-bit RSA is below modern 112-bit security strength and is not used for new protection.
• 2048-bit RSA is the common minimum (NIST SP 800-131A: modulus 2048 bits or more for the 112-bit security floor).
• 3072-bit RSA is the usual comparison point when you want about 128-bit classical strength, matching AES-128's security strength — at a painful performance cost.
• 4096-bit RSA shows up in some certificate authorities and SSH keys; it is slower still.

Elliptic-curve cryptography (ECC) does the same jobs (key agreement, signatures, and, less often, encryption via ECIES-style constructions) on elliptic-curve groups. Comparable classical strength arrives at much smaller keys: NIST P-256 is commonly treated as roughly 128-bit strength, in the same band as AES-128 and RSA-3072, at a fraction of the RSA key size and with faster operations. P-384 tracks a higher strength band. Modern TLS, JWT signing, and mobile devices prefer ECDHE and ECDSA or Ed25519-style curves for this reason. ECC is not a bulk file-encryption algorithm for a 40 GB database dump.

RSA and ECC are both in scope for Shor's algorithm if a cryptographically relevant quantum computer arrives. That is a migration-to-PQC issue (5.1), not a reason to encrypt 40 GB with RSA-4096 "because bigger is safer."

AES versus RSA versus ECC

Hybrid cryptography: AES for bulk, RSA or ECC for key wrap

Scenario: AES for bulk versus RSA for key wrap. You must protect a 40 GB database backup before it goes to object storage. Encrypting the entire blob with a 2048-bit RSA public key is the wrong design: RSA (and ECC) are slow on bulk data, size-limited in raw form, and a nightmare to rotate. The SSCP pattern is the same one TLS uses:

1. Generate a random AES-256 data-encrypting key (high-entropy CSPRNG).
2. Encrypt the 40 GB with AES-GCM using that key.
3. Wrap (encrypt) the AES key with the backup recipient's RSA public key, or agree the AES key with ECDH.
4. Store ciphertext + wrapped key + nonce. Destroy the plaintext AES key in memory.
5. On restore, unwrap with the private key (HSM) and decrypt the blob.

That is symmetric plus asymmetric, not a religious choice of one algorithm for every byte.

When to hash versus encrypt versus HMAC

HMAC is a keyed hash. It sits conceptually between "hash" and "signature" and is on the outline under non-repudiation examples — with an important caveat the next section drills: both ends have the key, so HMAC authenticates a group, not a single non-repudiable actor.

Exam traps for this cluster

• Calling MD5 or SHA-1 "fine if we also encrypt." Collision resistance is a separate property.
• Unsalted SHA-256 of passwords because "SHA-256 is strong."
• RSA-1024 as a modern default, or claiming the SSCP publishes a secret required RSA length other than ordinary practitioner minima (2048+).
• Using ECC or RSA as a 40 GB backup cipher.
• Hashing a backup and claiming the data is confidential.
• Encrypting passwords so they can be decrypted for support calls.

Name the property, then pick the primitive. If the stem says bulk data, hear AES. If it says key wrap or identity, hear RSA or ECC. If it says password file, hear salted slow hash. If it says detect change of a known file, hear SHA-256 — not MD5.