Encrypt, Hash, or Sign? Symmetric vs Asymmetric, Hashing, Salting and Key Stretching on Security+

Key length is not comparable across families

A longer key means more possible keys and a harder brute-force search, but only within one algorithm family. A 256-bit ECC key and a 3,072-bit RSA key give roughly the same strength, about the same as a 128-bit AES key, according to NIST's key management guidance. The numbers differ because the attacks differ: brute force against AES, factoring against RSA, discrete logarithms against ECC. The exam uses this to set a trap. A stem that asks which provides the strongest protection, listing RSA-2048 beside AES-256, is not won by the bigger number. And ECC's small keys are exactly why it is the answer for IoT devices, smart cards and anything with tight power or bandwidth budgets.

Hashing, and what is built on it

A hash function takes input of any length and produces a fixed-length digest. It is one way: there is no key and no way to run it backwards. Change one bit of the input and roughly half the output bits flip. A good hash makes a collision, two inputs with the same digest, infeasible to find. MD5 lost that property years ago, and a practical SHA-1 collision was published in 2017. Both survive only as non-security checksums. SHA-256 and SHA-3 are the current answers.

Hashing on its own proves integrity to anyone who trusts the published hash, which is why download pages list SHA-256 values. Add a shared key and you have an HMAC. Encrypt the hash with a private key and you have a digital signature: the sender hashes the message and signs the hash; the receiver recomputes the hash and checks it against the signature using the sender's public key. A match proves the message is unchanged and that only the private-key holder could have signed it.

The same chained-hash idea is what the outline means by blockchain and an open public ledger: each block includes the hash of the one before, so altering an old record breaks every hash after it, and copies held by many parties make the tampering visible.

Salting and key stretching solve different problems

Password storage is where hashing most often goes wrong, and Security+ tests two separate fixes. A plain SHA-256 of each password has two weaknesses. Identical passwords produce identical hashes, so cracking one cracks every account that shares it, and an attacker can use a rainbow table, precomputed once, to reverse common passwords by lookup. And SHA-256 is designed to be fast, so one graphics card can test billions of guesses per second.

A salt is a random value generated for each password and mixed in before hashing. It is stored beside the hash and does not need to be secret. Its job is to make every hash unique, which kills rainbow tables and hides shared passwords. What it does not do is slow anyone down: with the salt in hand, an attacker can still test billions of guesses against each account.

Key stretching fixes the speed. Algorithms like PBKDF2 run the hash many thousands of times, bcrypt has a tunable cost factor, and Argon2id also demands a configurable amount of memory per guess, which blunts GPUs and custom hardware. A legitimate login pays a fraction of a second once. An attacker pays it for every guess, and the guessing rate drops by many orders of magnitude. Some systems also add a pepper, a secret value kept outside the database, so a stolen database alone is not enough to start guessing.

Where the encryption sits

Objective 1.4 also asks where encryption is applied, and the right level depends on the threat. Each level protects against a different loss.

The trap is full-disk encryption on a running machine. Once the system is booted and unlocked, the disk serves decrypted data to anything running on it, so malware on a logged-in laptop sees plaintext. Full-disk encryption protects the device when it is off or stolen; file, database and record encryption keep protecting the data while the system runs. The hardware that holds the keys, the TPM, HSM, key management system and secure enclave, has its own home in the TPM and secure boot post.

Obfuscation rounds out the objective. Steganography hides data inside other data, such as an image. Tokenization swaps a sensitive value for a meaningless token that maps back only through a protected vault. Data masking shows a partial or altered value, such as the last four digits of a card. None of them is encryption, and the data protection post covers when each is the better choice.

Four stems, decoded

1. A firm must prove a signed contract came from its CFO, who later claims it was forged. Digital signature. Non-repudiation is the requirement, and only a private key that one person holds can provide it. An HMAC fails because the key is shared.
2. A breached database stored unsalted SHA-256 password hashes; what most reduces the damage next time? A salted, stretched algorithm such as bcrypt or Argon2id. Salting alone stops rainbow tables but leaves fast guessing; encrypting the passwords is wrong because anything that can be decrypted can be stolen along with the key.
3. A team of 50 wants each pair of members to communicate privately using only symmetric keys. How many keys? 1,225, from 50 × 49 ÷ 2. With asymmetric keys it would be 100.
4. An analyst finds a credential in a script, written as a long Base64 string, and the developer says it is encrypted. It is not. Base64 is encoding, reversible by anyone with no key. Encoding is about format, encryption is about secrecy, and hashing is about integrity.

Cryptographic solutions are objective 1.4 of Security+ SY0-701 Domain 1, General Security Concepts, 12% of the exam, and the same material becomes objective 1.3 in SY0-801, where Domain 1 grows to 16%. It is the foundation the PKI and data protection objectives build on. Work every Domain 1 topic with our free Security+ Domain 1 study guide.

#SecurityPlus #SY0701 #SY0801 #Cryptography #Encryption #Hashing #PasswordSecurity #ExamPrep #InfoSec #CyberSecurity