Hashing, Encryption, and Encoding Quick Reference for Security+ SY0-701

A cryptography question often becomes manageable as soon as you identify the requested outcome:

Confidentiality: prevent unauthorized reading
Integrity: detect unauthorized change
Authenticity: verify the claimed source
Compatibility: represent data in a format another system can handle

Hashing, encryption, and encoding solve different problems. Digital signatures and HMAC combine cryptographic operations to add source assurance.

Fast split: Encrypt to keep data secret. Hash to create a one-way digest. Encode to change representation without adding secrecy.

Three methods at a glance

Method	Primary purpose	Reversible?	Uses a secret key?	Typical examples
Hashing	Create a digest for integrity checks or password verification	No practical reversal	No for an ordinary hash	SHA-256, SHA-3
Encryption	Protect confidentiality	Yes, with the proper key	Yes	AES, RSA
Encoding	Represent data for storage, transfer, or compatibility	Yes, without a secret	No	Base64, hexadecimal

The output may look unreadable in all three cases. Appearance does not determine the security property. Ask what information or key is needed to recover or verify the original data.

Hashing

A cryptographic hash function accepts data of varying length and produces a fixed-length digest. A secure hash is designed to be one-way and collision resistant.

Useful properties include:

The same input produces the same digest when the same algorithm is used.
A small input change should produce a very different digest.
The digest length is determined by the algorithm, not by the input size.
Finding the original input from the digest should be computationally infeasible.
Finding two different inputs with the same digest should be computationally infeasible.

Integrity checking

A software publisher can post a file and its expected SHA-256 digest. After downloading the file, a user calculates a new digest and compares it with the published value.

A match supports the conclusion that the file did not change between the publisher's calculation and the user's calculation. It does not prove who created the file unless the expected digest is delivered through a trusted, authenticated source.

An ordinary hash does not authenticate the sender

Anyone who has a message can calculate its unkeyed hash. Matching digests show that the compared data is the same. They do not identify who produced it.

Use a digital signature when public verification and signatory assurance are needed. Use HMAC when parties share a secret and need message authentication.

Example digest

For the text:

Cert happens.

SHA-256 produces:

0875b0b38c71dc648dfcc1ebfd8cb5cc9b1d510b884fd2ebb5d023a4f7bfc2f2

Changing even the final period changes the digest. Deleting the period does not produce a slightly shorter result. SHA-256 still returns a 256-bit digest.

Recognize weak legacy choices

MD5 and SHA-1 may still appear in old systems, file listings, or exam distractors. Their collision resistance is not suitable for modern security uses. Prefer current approved hash families such as SHA-2 or SHA-3 when the scenario requires a secure cryptographic hash.

Encryption

Encryption transforms plaintext into ciphertext using an algorithm and a key. Decryption uses the required key to restore the plaintext.

Encryption primarily protects confidentiality. It does not automatically prove who created the data or guarantee that no one modified it. Secure protocols often combine encryption with an authentication mechanism.

Symmetric encryption

Symmetric encryption uses the same secret key for encryption and decryption.

Strengths

Fast enough for large amounts of data
Efficient for disks, files, databases, and network sessions
Commonly used after two parties establish a shared session key

Main challenge

The secret key must be distributed and protected safely.

AES is the main Security+ example of a symmetric block cipher.

Asymmetric encryption

Asymmetric cryptography uses a mathematically related public and private key pair.

When protecting confidentiality for a recipient:

The sender encrypts with the recipient's public key.
The recipient decrypts with the recipient's private key.

Strengths

The public key can be distributed broadly.
It supports digital signatures and key-establishment processes.
It reduces the need to share one long-term secret with every party.

Tradeoffs

It is slower and more computationally expensive than symmetric encryption.
Real systems commonly use asymmetric methods to establish or protect a symmetric session key, then use symmetric encryption for the data.

RSA and elliptic-curve cryptography are common asymmetric concepts. The exact operation depends on the algorithm and protocol. Do not assume every asymmetric algorithm supports both encryption and signatures.

Hybrid encryption

A typical secure session uses both types:

Asymmetric cryptography authenticates parties or protects key establishment.
Symmetric encryption protects the application data efficiently.

When a question offers both methods, look for the stage of the process being described.

Encoding

Encoding changes how data is represented so that it can be stored or transferred through a particular system. It does not require a secret key.

Base64 is useful when binary data must travel through a text-oriented format. Hexadecimal represents each byte as two base-16 characters.

The text:

Cert happens.

can be represented as Base64:

Q2VydCBoYXBwZW5zLg==

or hexadecimal:

43 65 72 74 20 68 61 70 70 65 6e 73 2e

Anyone who recognizes the encoding can reverse it. Encoding may make data less readable at a glance, but it does not provide confidentiality.

Encoding can carry encrypted or hashed data

These operations can be layered.

For example, a system may:

Encrypt binary data.
Encode the ciphertext with Base64 so it can be placed in a text field.

Base64 is still only the representation layer. The encryption is what protects confidentiality.

Common clues

Look for encoding when the scenario mentions:

Binary data inside email, JSON, XML, or another text format
Printable representation
Character compatibility
Base64 or hexadecimal output
A value that anyone can decode without a key

Digital signatures and HMAC

Hashing is often one part of a larger cryptographic process.

Digital signatures

A digital signature uses asymmetric cryptography.

The signer creates the signature using the signer's private key.
A verifier checks the signature using the corresponding public key.

A properly implemented digital signature supports:

Integrity
Origin authentication
Non-repudiation support

It does not provide confidentiality by itself. Anyone may be able to read a signed message unless the message is also encrypted.

Digital-signature systems normally operate on a digest of the data rather than applying the signature algorithm directly to an entire large file.

HMAC

A hash-based message authentication code combines a cryptographic hash function with a shared secret key.

HMAC supports:

Integrity
Message authentication between parties that share the secret

HMAC does not provide confidentiality. It also does not provide the same third-party non-repudiation support as a digital signature because every party holding the shared secret could generate a valid HMAC.

Mechanism	Key material	Integrity	Source assurance	Confidentiality
Ordinary hash	None	Yes, when compared with a trusted digest	No	No
HMAC	Shared secret	Yes	Yes, among holders of the shared secret	No
Digital signature	Private key signs; public key verifies	Yes	Yes, with a trusted public-key binding	No

Password protection

Passwords should not be stored as plaintext or as reversibly encrypted values for routine authentication. A verifier usually stores the output of a password-hashing or password-based key-derivation process.

Salt

A salt is a unique random value combined with a password before hashing.

Salting helps because:

Two users with the same password receive different stored values.
Precomputed hash lists become far less useful.
An attacker must work on each salted password separately.

The salt is not normally secret. It can be stored beside the resulting password hash.

Key stretching

Key stretching deliberately makes each password guess more expensive by repeating or strengthening the derivation process.

The goal is to slow offline guessing after a credential database is stolen while keeping legitimate login verification practical.

A work factor or cost setting controls the expense. As hardware improves, an organization can increase that cost for newly created or updated password values.

Pepper

A pepper is an additional secret value kept separately from the password database. It can add protection if the database is stolen without the separate secret.

Peppering is not a replacement for unique salts or an appropriate password-hashing function.

Password clue: Salt defeats easy reuse of precomputed results. Key stretching raises the cost of every guess.

Scenario comparisons

Scenario	Best match	Why
A company must prevent someone who steals a laptop from reading its files.	Encryption	The required property is confidentiality.
An administrator compares a downloaded image with a trusted SHA-256 value.	Hashing	The digest can reveal whether the file changed.
Binary certificate data must be placed inside a text-only configuration file.	Encoding	The problem is data representation and compatibility.
A software vendor wants customers to verify the publisher and detect modified packages.	Digital signature	Customers need integrity and public verification of the claimed signer.
Two internal services share a secret and must authenticate API messages.	HMAC	A shared secret can produce and verify message-authentication tags.
Users with the same password must not have identical stored password values.	Unique salts	The random value makes otherwise identical passwords produce different results.
A stolen credential database should require more computation for every password guess.	Key stretching	The process deliberately increases the cost of offline guessing.
A sender needs to transfer a large encrypted file efficiently after negotiating a session key.	Symmetric encryption	Symmetric encryption is efficient for bulk data.

Common exam traps

Choosing Base64 to protect a secret

Base64 is reversible without a key. It solves a representation problem, not a confidentiality problem.

Choosing hashing for confidentiality

Hashing can support integrity checks and password verification. It does not let an authorized recipient recover the original message.

Assuming encryption supplies every security property

Encryption protects confidentiality when implemented correctly. Integrity and authentication usually require an authenticated-encryption mode, MAC, signature, or protocol that supplies those protections.

Signing with the public key

The signer uses the private key. Verifiers use the corresponding public key.

For confidentiality, the direction is different: a sender encrypts for a recipient with the recipient's public key, and the recipient decrypts with the private key.

Treating an ordinary hash as proof of origin

Anyone can calculate an unkeyed hash. Use a trusted digital signature or HMAC when the source matters.

Treating HMAC as a digital signature

HMAC uses a shared secret. A digital signature uses a private key for signing and a public key for verification. HMAC cannot show a third party which shared-secret holder created the tag.

Assuming a salt must remain secret

A salt should be unique and unpredictable when generated, but it can be stored with the password hash. Its job is to make identical passwords and precomputed attacks less useful.

Confusing key stretching with encryption

Key stretching increases the work needed to test password guesses or derive a key. It does not replace encryption when data must later be recovered.

Rapid review grid

Need	Choose	Memory cue
Confidentiality	Encryption	Recover with the proper key
Integrity comparison	Hash	One-way digest
Text-safe representation	Encoding	Reformat without a secret
Integrity and shared-secret authentication	HMAC	Hash plus shared secret
Integrity and public verification of a signer	Digital signature	Private signs, public verifies
Different stored values for identical passwords	Salt	Unique random input
More expensive password guessing	Key stretching	Raise the cost per guess
Efficient bulk-data protection	Symmetric encryption	One shared secret key
Signatures or protected key establishment	Asymmetric cryptography	Public and private key pair

A useful decision path:

Must authorized users recover the original data? Choose encryption.
Must anyone be able to reverse the representation? Choose encoding.
Is a one-way comparison enough? Choose hashing.
Must the source also be verified? Add HMAC or a digital signature, depending on the trust model.

Review checklist

Before moving on, confirm that you can:

State the main purpose of hashing, encryption, and encoding.
Explain why unreadable output is not automatically encrypted.
Separate symmetric and asymmetric encryption use cases.
Remember that private keys sign and public keys verify.
Explain why an ordinary hash does not authenticate a sender.
Choose HMAC for shared-secret message authentication.
Choose a digital signature for public verification of a signer.
Explain how salts change password-storage results.
Explain how key stretching increases the cost of password guessing.
Recognize Base64 and hexadecimal as encodings rather than confidentiality controls.
Identify whether a scenario requests confidentiality, integrity, authenticity, or compatibility.

For the broader cryptography and PKI material, continue with the General Security Concepts guide.

Official references

The Security+ SY0-701 objectives include cryptographic solutions such as symmetric and asymmetric encryption, hashing, salting, key stretching, digital signatures, and public-key infrastructure. The following primary sources provide standards and definitions used in this guide.