Cryptography basics for security exams
Cryptography on a security exam is a matching game: each tool solves one problem. Symmetric encryption (one shared key) protects the confidentiality of bulk data. Asymmetric encryption (a public and private key pair) solves key exchange and digital signatures. Hashing (one-way, no key) proves integrity. PKI (certificates and certificate authorities) makes people trust that a public key really belongs to who it claims. The decision rule: name the property the scenario needs, such as confidentiality, integrity, authentication or non-repudiation, then pick the tool that provides it.
Which tool provides which property
| Tool | Keys | Reversible? | Gives you | Examples |
|---|---|---|---|---|
| Symmetric encryption | One shared secret key | Yes, with the key | Confidentiality, fast on large data | AES |
| Asymmetric encryption | Public key and private key | Yes, with the matching key | Key exchange, signatures, confidentiality for small data | RSA, elliptic-curve schemes |
| Hashing | None | No, it is one-way | Integrity; password storage when salted | SHA-256 |
| Digital signature | Private key signs, public key verifies | Verification only | Integrity, authentication, non-repudiation | RSA or ECDSA signatures over a hash |
| PKI certificate | Binds a public key to an identity | n/a | Trust in a public key | X.509 certificate issued by a CA |
If a question asks for the property and you cannot decide, remember the rule: confidentiality needs encryption, integrity needs a hash, and a signature adds identity on top of the hash.
Symmetric: fast, but the key must travel
Symmetric algorithms use the same key to encrypt and decrypt. AES, the current standard, encrypts in 128-bit blocks and uses keys of 128, 192 or 256 bits (FIPS 197). Older ciphers such as DES and 3DES are obsolete and usually appear as wrong answers. Symmetric encryption is quick enough for disks, databases and network traffic.
Its weakness is distribution. Both sides need the same secret, and if you must send it over an untrusted network, an eavesdropper can take it. That problem is why asymmetric cryptography exists.
Asymmetric: two keys with different jobs
A key pair has a public key, which anyone may have, and a private key, which stays secret. The two are mathematically linked, but the private key cannot practically be derived from the public one. This gives two distinct uses that exams love to swap:
- Confidentiality: encrypt with the recipient’s public key; only the recipient’s private key decrypts.
- Signing: sign with the sender’s private key; anyone can verify with the sender’s public key. A valid signature proves who signed and that the content was not changed, so the sender cannot plausibly deny it (non-repudiation).
Asymmetric operations are much slower than symmetric ones, so they are used on small things: a session key, or the hash of a document.
Hashing: a fingerprint, not a lock
A hash function turns any input into a fixed-length digest. SHA-256, from the SHA-2 family in FIPS 180-4, always produces 256 bits. Changing one bit of input changes the digest completely, and the digest cannot practically be turned back into the input. MD5 and SHA-1 are no longer considered safe where collision resistance matters, and an exam will treat them as the weak answers.
Hashing is not encryption. Nothing can be decrypted, which is exactly why it suits password storage: the system stores the hash and compares the hash of what you type. A salt, a unique random value added before hashing, stops two users with the same password from sharing a hash and defeats precomputed rainbow tables. A real password scheme also uses a deliberately slow function, such as PBKDF2, bcrypt or Argon2, so guessing is expensive. HMAC combines a hash with a secret key when you need integrity and proof that the sender knew the key.
PKI: who vouches for a public key
A public key by itself proves nothing about who owns it. A certificate (the X.509 format, RFC 5280) ties a public key to a subject and is signed by a certificate authority (CA). A client trusts a certificate if it chains up through intermediate CAs to a root CA already in its trust store. The vocabulary that appears most:
- CSR (certificate signing request): what you send to a CA to get a certificate. It contains your public key and identity details, never your private key.
- Self-signed certificate: signed by its own key. It encrypts fine but no third party vouches for it, so browsers warn.
- Wildcard certificate: covers one level of subdomains, such as
*.example.com. - Revocation: a certificate can be cancelled before it expires. A CRL is a downloadable list of revoked certificates. OCSP (RFC 6960) asks a responder about one certificate in near real time.
A worked example: one HTTPS connection
You open https://shop.example in a browser. In outline, TLS 1.3 (specified in RFC 9846, which replaced RFC 8446 in July 2026) does this:
- The server sends its certificate. The browser checks that the chain leads to a trusted root, that the name matches, that it has not expired, and, if configured, that it has not been revoked. This is PKI at work.
- Client and server use asymmetric key exchange to agree on a fresh shared secret that no eavesdropper can derive. The server proves it owns the certificate’s key with a signature.
- Both sides now use the shared secret as a symmetric session key. All page content is encrypted with it, fast.
- Integrity of every record is protected, so tampering in transit is detected.
Each of the four tools appears once, each doing the job it is best at. The whole session is not asymmetric, because that would be too slow.
Which exams test this
| Exam | How it appears | Where it is covered here |
|---|---|---|
| SY0-801 | General Security Concepts domain (16%), objective 1.3: PKI and key escrow, certificates (CAs, CRLs, OCSP, self-signed, wildcard, CSRs), symmetric versus asymmetric encryption, encryption levels, key exchange and key length, digital signatures, salting and hashing | General security concepts |
| SY0-801 | Security Architecture domain (19%), objective 3.3: methods to secure data, including hashing, masking, tokenization and encryption | Security architecture |
| SC-900 | Concepts of security, compliance and identity domain (10–15%): describe encryption and hashing, at fundamentals depth (outline as of October 21, 2026; the objective is unchanged by that update) | Security, compliance and identity concepts |
| N10-009 | Network Security domain (14%), objective 4.1: encryption of data in transit and at rest, and certificates (PKI, self-signed); objective 4.3 adds key management | N10-009 network security explained |
| 200-901 | Minor topic. Application Deployment and Security domain (15%), objective 4.8: application security issues around secret protection and encryption in storage and transport | 200-901 application deployment security explained |
How exam questions are built around it
The reliable trap is the key swap. A question asks how a sender can prove a message came from them, and the options offer “encrypt with the recipient’s public key” (confidentiality, not proof of origin) next to “sign with the sender’s private key” (the right one). Learn the two pairings as a rule: public key to the recipient for secrecy, private key of the sender for proof.
The second trap is encryption versus hashing. Words such as “recover the original”, “decrypt” and “confidentiality” mean encryption. Words such as “verify integrity”, “one-way”, “cannot be reversed” and “store passwords” mean hashing. Base64 appears as a decoy; it is encoding, not protection.
Third, speed and scale. “Large volume of data”, “disk” or “database” points to symmetric. “Exchange keys over an untrusted network” points to asymmetric. And revocation questions turn on “without downloading a complete list”, which means OCSP rather than a CRL.
Tokenization and masking in data-protection questions are not cryptography: tokenization swaps a value for a surrogate kept in a vault, masking hides part of a value.
Practice questions
Question 1. A finance officer must send a contract to a partner and prove to the partner that the contract came from her and was not altered in transit. Which action provides this?
- A. Encrypt the contract with the partner’s public key
- B. Sign the contract with her private key
- C. Publish a SHA-256 hash of the contract on a website
- D. Encrypt the contract with a symmetric key both parties know
Show answer
Answer: B
A digital signature is created with the sender’s private key over a hash of the document; the partner verifies it with the sender’s public key, which proves origin and integrity and gives non-repudiation. Encrypting with the partner’s public key gives confidentiality but anyone could have done it. A hash alone detects change but proves nothing about who produced it. A symmetric key shared in advance does not prove origin to a third party, as both sides hold the same key.
Question 2. An administrator is designing storage for user passwords. The system must be able to check a login attempt but no administrator, including the database owner, should be able to recover the original passwords. Which approach is best?
- A. Encrypt the passwords with AES and store the key on the same server
- B. Encrypt the passwords with an RSA public key
- C. Encode the passwords with Base64
- D. Store a salted hash computed with a slow hashing function such as bcrypt
Show answer
Answer: D
A salted hash made with a slow password hashing function lets the system compare a login attempt without storing anything reversible, and the salt makes identical passwords produce different hashes. Symmetric or asymmetric encryption is reversible by whoever holds the key, so administrators could recover the passwords. Base64 is only an encoding and offers no protection.
Go deeper
- FIPS 197, Advanced Encryption Standard
- FIPS 180-4, Secure Hash Standard
- RFC 5280, X.509 certificate and CRL profile
- RFC 9846, TLS 1.3, which obsoletes RFC 8446
Related on this site: Zero Trust explained, SSO, SAML, OAuth and OIDC explained, sensitivity labels explained and how to read a skills outline.