Cryptography questions on the GIAC GSEC exam often look simple until the answer choices mix up terms that sound related but solve different problems. That is where many people lose points. A hash is not encryption. A digital signature is not the same thing as a certificate. Symmetric and asymmetric keys can work together, but they are not interchangeable. This cheat sheet is built to make those lines clear. It focuses on what each primitive does, why it exists, and where you would actually use it in security work and on the exam.
If you are reviewing for GSEC, think in terms of security goals: confidentiality, integrity, authentication, non-repudiation, and key exchange. Then map the technology to the goal. That one habit will help you answer a large share of crypto questions correctly. If you want to pair this guide with exam-style drills, you can use the GIAC GSEC practice test as a quick way to test whether you can tell these concepts apart under pressure.
Start with the core security goals
Most cryptography tools exist to protect one or more of a few basic properties. If you remember the property first, the right answer usually gets easier.
- Confidentiality: Keeps data secret from unauthorized people.
- Integrity: Shows whether data was changed.
- Authentication: Proves identity or verifies the source of data.
- Non-repudiation: Makes it hard for a sender to deny they performed an action.
- Key exchange: Lets parties establish shared secrets safely.
A common exam trap is choosing a control that sounds secure but protects the wrong property. For example, hashing protects integrity, not confidentiality. Encryption protects confidentiality, but by itself it does not prove who created the message.
Hashing: what it does and what it does not do
A hash function takes input data of any size and turns it into a fixed-length output, often called a digest. Good hash functions are designed so that even a tiny input change creates a very different output. That behavior makes hashing useful for integrity checking.
In practical terms, if you hash a file now and hash it again later, matching digests suggest the file did not change. If the digests differ, the file changed somehow.
Hashing is used for:
- Integrity verification: Comparing stored and current hashes of files.
- Password storage: Storing password hashes instead of plaintext passwords.
- Digital signatures: Signing the hash of a message instead of the whole message.
- File identification: Recognizing known files, malware samples, or evidence images.
Hashing is not used for:
- Reversible protection: You do not decrypt a hash.
- Confidentiality: Anyone can hash data. The hash does not hide the original content in a usable way.
- Direct authentication by itself: A plain hash does not prove who created the data.
This last point matters. If an attacker can modify a file, they can usually compute a new hash too. That means a plain hash alone can show that two versions differ, but it does not prove who produced the correct one. For source authentication, you need something stronger, such as an HMAC or digital signature.
Important hash properties to know:
- Deterministic: The same input always gives the same output.
- Fast to compute: Useful for checking data efficiently.
- Preimage resistance: Hard to recover the original input from the hash.
- Second preimage resistance: Hard to find a different input with the same hash as a given input.
- Collision resistance: Hard to find any two different inputs with the same hash.
On GSEC, older algorithms matter because you may be asked what is weak or outdated. MD5 and SHA-1 are widely considered broken or too weak for modern collision-resistant needs. SHA-2 and SHA-3 families are the safer choices in modern settings.
Password hashing is a special case
Password hashing deserves separate attention because exam questions often mix it up with general hashing. Password storage should not use fast general-purpose hashing alone. Why? Because attackers can test huge numbers of guesses very quickly if the hash function is fast.
Instead, password systems should use slow, adaptive password hashing with a salt. The salt is a random value added before hashing. It prevents two users with the same password from having the same stored hash and helps defeat precomputed rainbow tables.
What to remember:
- A salt is not secret. It should be unique per password.
- A pepper is a separate secret value sometimes added at the application level.
- Password hashing should be intentionally expensive to slow brute-force attacks.
If the question asks what protects stored passwords best, look for salted, adaptive password hashing rather than simple SHA-256 alone.
Encryption: the tool for confidentiality
Encryption turns readable plaintext into unreadable ciphertext using a key. If the main goal is secrecy, encryption is usually the right family of controls.
There are two main key models:
- Symmetric encryption: The same key encrypts and decrypts.
- Asymmetric encryption: One key encrypts and a different but related key decrypts.
Symmetric encryption is usually faster and better for protecting large amounts of data. Asymmetric encryption is slower, but it solves key distribution problems and supports signatures.
Symmetric cryptography: fast and practical
In symmetric systems, both parties share the same secret key. That makes these algorithms efficient, which is why they are used heavily in VPNs, disk encryption, backups, and encrypted network sessions after the handshake phase.
Common use-cases:
- Full-disk encryption
- Database or file encryption
- Bulk data transfer after secure session setup
- Backup protection
Main strength: Speed.
Main weakness: Key distribution. Both sides need the same secret, so you need a safe way to share it first.
AES is the standard algorithm to know. If you see DES, 3DES, or RC4 in an answer set, the exam may be testing whether you recognize weaker or legacy choices.
Asymmetric cryptography: identity, exchange, and trust
Asymmetric cryptography uses a public and private key pair. The public key can be shared openly. The private key must be protected. This model is slower than symmetric encryption, but it handles problems that symmetric encryption cannot solve cleanly on its own.
Common use-cases:
- Key exchange: Safely establishing shared secrets
- Digital signatures: Proving message origin and integrity
- Certificates and PKI: Binding identities to public keys
- Small data encryption: Often used for key wrapping, not bulk data
Main strength: Better support for authentication, signatures, and secure key sharing.
Main weakness: Slower performance and more complexity.
RSA and elliptic curve systems are common examples. On the exam, if the scenario involves proving a sender’s identity or verifying software updates, asymmetric cryptography is often part of the answer.
Digital signatures: integrity plus source authentication
A digital signature proves more than a hash alone. It shows that the signed data has not changed and that someone with the correct private key signed it. That gives you integrity and authentication. It can also support non-repudiation, because the private key should be controlled by one identity.
Here is the simplified process:
- The sender hashes the message.
- The sender signs that hash with their private key.
- The receiver verifies the signature using the sender’s public key.
The message itself is not necessarily encrypted. That is a common confusion point. A signed email can still be readable in transit if it is signed but not encrypted.
Digital signatures are used for:
- Signed email
- Code signing
- Document signing
- Software update validation
- TLS certificates and trust chains
Digital signatures do not provide:
- Confidentiality by themselves
If an exam item asks how to verify that a file came from a known vendor and was not altered, a digital signature is the strongest fit. A plain hash only checks change. It does not tie the file to the vendor.
HMAC: the easy-to-miss integrity tool
HMAC stands for Hash-based Message Authentication Code. It combines a hash function with a shared secret key. This is important because it fixes a weakness of plain hashing: anyone can hash data, but only someone with the secret key can generate the correct HMAC.
That means HMAC provides:
- Integrity
- Authentication of the sender or source, as long as the secret key is controlled properly
HMAC does not provide non-repudiation, because both parties share the same secret. Either one could have created the HMAC.
This makes HMAC a good answer for API request signing, message validation between trusted systems, and session token protection where both sides share a secret.
Certificates and PKI: trust at scale
A certificate binds a public key to an identity. It is typically signed by a Certificate Authority, or CA. Public Key Infrastructure, or PKI, is the framework that manages certificates, trust chains, validation, revocation, and related processes.
Why this matters: a public key alone is just a key. A certificate adds identity and trust. In a browser, for example, the site presents a certificate. The browser checks whether it chains back to a trusted CA, whether the name matches, whether the certificate is still valid, and whether it has been revoked.
Remember these distinctions:
- Certificate: Binds identity to a public key.
- Digital signature: Verifies integrity and signer identity.
- PKI: The broader system that manages trust and certificates.
These terms are related, but not identical. Exams love to swap them around in answer choices.
Map common use-cases to the right crypto control
This is the fastest way to reason through test questions and real-world design decisions.
- You need to keep a laptop’s data secret if it is stolen.
Use symmetric encryption, such as full-disk encryption. - You need to verify a downloaded update is from the vendor and unchanged.
Use a digital signature. - You need to store user passwords safely.
Use salted, adaptive password hashing. - You need two systems to verify messages were not altered and came from someone who knows a shared secret.
Use HMAC. - You need to send large amounts of encrypted traffic efficiently.
Use symmetric encryption for the bulk data, often after an asymmetric key exchange. - You need to share a secret over an untrusted network.
Use asymmetric key exchange methods or a protocol like TLS that uses them. - You need to prove who signed a contract or code package.
Use a digital signature with proper key protection. - You need to detect whether a file changed.
Use a hash for integrity checking, but add a signature or HMAC if source trust matters.
Common terminology traps on GSEC
These are the mistakes that show up again and again:
- Hashing vs encryption: Hashing is one-way. Encryption is reversible with the right key.
- Authentication vs authorization: Authentication proves identity. Authorization decides what that identity can do.
- Digital signature vs certificate: A signature proves integrity and signer control of a private key. A certificate binds an identity to a public key.
- Integrity vs non-repudiation: Integrity shows data was not altered. Non-repudiation means a signer cannot easily deny the action.
- Symmetric vs asymmetric: Symmetric is fast and shared-secret based. Asymmetric uses key pairs and is better for signatures and key exchange.
If two answer choices both sound plausible, ask: which one directly satisfies the required security property?
Quick drills to lock it in
Try these short checks without looking back.
- A company wants to verify a backup file was not altered, but does not care who created it. What fits best?
Hashing. - An admin needs to confirm a patch really came from the vendor.
Digital signature. - A web app must store user passwords safely.
Salted, adaptive password hashing. - Two internal services share a secret and must detect tampered API messages.
HMAC. - A VPN must encrypt a large volume of traffic efficiently.
Symmetric encryption for data transfer. - A browser needs to trust a website’s public key.
Certificate validation through PKI.
If you miss one, do not just memorize the answer. Ask what security property was being tested. That is the reason the answer is correct.
A compact printable cheat sheet
Hash
Purpose: Integrity
Key needed: No
Reversible: No
Best for: File integrity checks, password storage as part of a proper password-hashing scheme, signature input
HMAC
Purpose: Integrity + authentication with shared secret
Key needed: Yes, shared secret
Reversible: No
Best for: API signing, trusted system-to-system message validation
Symmetric encryption
Purpose: Confidentiality
Key needed: Yes, same secret key on both sides
Reversible: Yes
Best for: Bulk data encryption, disks, backups, VPN data channels
Asymmetric encryption
Purpose: Confidentiality, key exchange, authentication support
Key needed: Yes, public/private pair
Reversible: Yes, with the matching key
Best for: Key exchange, small data protection, certificate-based trust
Digital signature
Purpose: Integrity + authentication + potential non-repudiation
Key needed: Yes, private key to sign, public key to verify
Reversible: Not the right concept here
Best for: Code signing, signed email, document approval, vendor verification
Certificate
Purpose: Bind identity to public key
Key needed: Built around public/private key systems
Best for: TLS, PKI, identity trust
Final exam mindset
For GSEC, do not treat cryptography as a list of algorithms to memorize in isolation. Treat it as a set of tools matched to security goals. Ask what problem the organization is trying to solve. Hide data? Encrypt it. Detect changes? Hash it. Prove origin? Sign it or use HMAC, depending on whether you need shared-secret authentication or public-key proof. Establish trust in a public key? Use certificates and PKI.
That approach works because cryptography is really about fit. The exam tests whether you can choose the right control for the right job. Once you stop lumping all crypto terms together, the questions become much easier to read and much harder to trick you with.
