Study & Revision
Cryptography & Data Protection
Cryptography & Data Protection
Evidence labels show where each concept’s recorded learning comes from: classroom sessions, Study Buddy sessions, supplementary Study Guide explanations or a mix. Reviewed revision may go further, so you can study ahead. Available questions do not imply complete topic or exam coverage.
Blockchain and Hash-Linked Records
Evidence: Mixed
Revision: Available · 7 questions · 3 flashcards
Exam relevance
CompTIA Security+
Verified for Security+: 4 of 7 questions and 3 of 3 flashcards. The mapping does not verify the others.
Reviewed revision scope
- Classroom (Session 9): blockchain and hash-linked records were covered.
- Supplementary: a blockchain is a ledger made of blocks of records in which each block includes the hash of the block before it, so that changing an earlier block changes its hash and breaks every later link.
- Supplementary: copies of the ledger are held by many participants who agree on new blocks by a consensus process, which is what makes tampering detectable and hard without central control; hash-linking alone only makes a change evident.
- Supplementary: an open public ledger can be read and joined by anyone, while a permissioned or private blockchain restricts who may read, write or validate; a blockchain is therefore not necessarily public, and a central bank digital currency does not inherently require one.
Outside the authored revision scope
- Individual cryptocurrencies and their value
- Consensus algorithms in detail
- Configuring or operating these technologies in practice
- The mathematics of the algorithms beyond the level stated
- The exact wording of the session material
Recorded evidence
- Classroom (Session 9): blockchain and hash-linked records were covered.
- Supplementary: a blockchain is a ledger made of blocks of records in which each block includes the hash of the block before it, so that changing an earlier block changes its hash and breaks every later link.
- Supplementary: copies of the ledger are held by many participants who agree on new blocks by a consensus process, which is what makes tampering detectable and hard without central control; hash-linking alone only makes a change evident.
- Supplementary: an open public ledger can be read and joined by anyone, while a permissioned or private blockchain restricts who may read, write or validate; a blockchain is therefore not necessarily public, and a central bank digital currency does not inherently require one.
- Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions — Classroom session record · Cryptography, cryptanalysis and ciphers; Encoding and encryption; The Caesar cipher and Enigma; Symmetric encryption and AES; Asymmetric encryption, RSA and ECC; Key length, keyspace and brute force; Hashing and the SHA families; Hash resistance properties and collisions; Checksums and integrity verification; Rainbow tables and password cracking; Digital signatures; Public key infrastructure and certificate authorities; Digital certificates and X.509; Root, intermediate and leaf certificates; Self-signed certificates and certificate signing requests; Common Name and Subject Alternative Name; Certificate validity, expiry and revocation; Key lifecycle and key management; Entropy and randomness; TPMs, HSMs and secure enclaves; FIPS 140-2 and FIPS 140-3; Key escrow and M-of-N recovery; Confidentiality and the states of data; Hybrid encryption; Disk, partition and file encryption; Database and record-level encryption; Transport encryption, TLS and HTTPS; Key agreement, ephemeral keys and forward secrecy; Salting, stretching and peppering; Blockchain; Steganography, data masking and tokenisation; De-identification and anonymisation; Tutor demonstrations; Classroom review of cryptographic algorithms
- Blockchain and Hash-Linked Records — Supplementary Study Guide explanation · The idea; See a change break the chain; Why hash-linking makes a change evident; What hash-linking alone does not do; Many copies and consensus; Public and permissioned blockchains; Where the idea is used, and where it is not needed; A central bank digital currency does not need a blockchain; Limits worth knowing
Not established by the recorded evidence
- Individual cryptocurrencies and their value
- Consensus algorithms in detail
- Configuring or operating these technologies in practice
- The mathematics of the algorithms beyond the level stated
- The exact wording of the session material
Authored and machine-validated on 12 October 2026; owner review pending. Checked during authoring against the Session 9 Learning Log and the Blockchain and Hash-Linked Records lesson Sources and scope section. Scope statements are labelled Classroom or Supplementary: Classroom statements record what the session covered, and beginner-first wording developed afterwards is labelled Supplementary. The concept is mapped to the Security+ objectives named in its mappings; that mapping verifies none of its questions or flashcards, and no practical competence or completed assessment is implied.
Certificate Validity and Revocation
Evidence: Mixed
Revision: Available · 7 questions · 3 flashcards
Exam relevance
CompTIA Security+
Verified for Security+: 4 of 7 questions and 2 of 3 flashcards. The mapping does not verify the others.
Reviewed revision scope
- Classroom (Session 9): certificate validity and expiration; certificate revocation; and certificate revocation lists (CRLs) compared with the Online Certificate Status Protocol (OCSP) were covered.
- Supplementary: every certificate has a validity period and stops being acceptable when it expires; revocation withdraws a certificate before its expiry, for example because its private key was compromised or its details are no longer correct.
- Supplementary: a certificate revocation list (CRL) is a signed list, published periodically by a CA, of the serial numbers of certificates it has revoked; the Online Certificate Status Protocol (OCSP) lets a client ask a responder for the current status of one certificate.
- Supplementary: revocation checking has operational limits: a CRL can be large and is only as fresh as its last publication, an OCSP query tells the responder which certificate a client is checking and can fail or be blocked, and many clients carry on when no answer arrives; shorter certificate lifetimes limit how long a compromised certificate stays usable.
Outside the authored revision scope
- OCSP stapling configuration
- Browser-specific revocation mechanisms
- Configuring or operating these technologies in practice
- The mathematics of the algorithms beyond the level stated
- The exact wording of the session material
Recorded evidence
- Classroom (Session 9): certificate validity and expiration; certificate revocation; and certificate revocation lists (CRLs) compared with the Online Certificate Status Protocol (OCSP) were covered.
- Supplementary: every certificate has a validity period and stops being acceptable when it expires; revocation withdraws a certificate before its expiry, for example because its private key was compromised or its details are no longer correct.
- Supplementary: a certificate revocation list (CRL) is a signed list, published periodically by a CA, of the serial numbers of certificates it has revoked; the Online Certificate Status Protocol (OCSP) lets a client ask a responder for the current status of one certificate.
- Supplementary: revocation checking has operational limits: a CRL can be large and is only as fresh as its last publication, an OCSP query tells the responder which certificate a client is checking and can fail or be blocked, and many clients carry on when no answer arrives; shorter certificate lifetimes limit how long a compromised certificate stays usable.
- Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions — Classroom session record · Cryptography, cryptanalysis and ciphers; Encoding and encryption; The Caesar cipher and Enigma; Symmetric encryption and AES; Asymmetric encryption, RSA and ECC; Key length, keyspace and brute force; Hashing and the SHA families; Hash resistance properties and collisions; Checksums and integrity verification; Rainbow tables and password cracking; Digital signatures; Public key infrastructure and certificate authorities; Digital certificates and X.509; Root, intermediate and leaf certificates; Self-signed certificates and certificate signing requests; Common Name and Subject Alternative Name; Certificate validity, expiry and revocation; Key lifecycle and key management; Entropy and randomness; TPMs, HSMs and secure enclaves; FIPS 140-2 and FIPS 140-3; Key escrow and M-of-N recovery; Confidentiality and the states of data; Hybrid encryption; Disk, partition and file encryption; Database and record-level encryption; Transport encryption, TLS and HTTPS; Key agreement, ephemeral keys and forward secrecy; Salting, stretching and peppering; Blockchain; Steganography, data masking and tokenisation; De-identification and anonymisation; Tutor demonstrations; Classroom review of cryptographic algorithms
- Certificate Validity and Revocation: CRLs and OCSP — Supplementary Study Guide explanation · Validity and expiry; Revocation: ending a certificate early; Certificate revocation lists; Online Certificate Status Protocol; CRL and OCSP compared; The limits of revocation checking
Not established by the recorded evidence
- OCSP stapling configuration
- Browser-specific revocation mechanisms
- Configuring or operating these technologies in practice
- The mathematics of the algorithms beyond the level stated
- The exact wording of the session material
Authored and machine-validated on 12 October 2026; owner review pending. Checked during authoring against the Session 9 Learning Log and the Certificate Validity and Revocation: CRLs and OCSP lesson Sources and scope section. Scope statements are labelled Classroom or Supplementary: Classroom statements record what the session covered, and beginner-first wording developed afterwards is labelled Supplementary. The concept is mapped to the Security+ objectives named in its mappings; that mapping verifies none of its questions or flashcards, and no practical competence or completed assessment is implied.
Controller and processor responsibilities
Evidence: Supplementary
Revision: Available · 1 question · 1 flashcard
Exam relevance
Learning-only · no verified exam mapping
Reviewed revision scope
- In the approved educational explanation a controller determines purposes and means and a processor acts on its behalf; actual processing determines roles, with Article 28 instructions, safeguards and accountability rather than automatic supplier classification.
Outside the authored revision scope
- Completed professional practice or legal advice
- Complete exam objectives or verified exam alignment
Recorded evidence
- In the approved educational explanation a controller determines purposes and means and a processor acts on its behalf; actual processing determines roles, with Article 28 instructions, safeguards and accountability rather than automatic supplier classification.
- Data Protection: UK GDPR and the DPA 2018 — Supplementary Study Guide explanation · The seven data-protection principles; Lawful bases and current law; Controllers, processors and service providers; Worked breach assessment
Not established by the recorded evidence
- Completed professional practice or legal advice
- Complete exam objectives or verified exam alignment
- Material outside the named introductory scope
Reviewed 2026-09-22. Reviewed against approved Sessions 3–4 learning and Core Concepts explanations. Fictional applications are educational elaborations, not completed practical work. Learning-only; this concept has not yet been individually verified against the Security+ SY0-701 objectives or any other exam syllabus. Coverage derives from the approved Core Concepts learning extension, not a claim of explicit classroom teaching.
Cryptography Foundations: Ciphers, Keys and Encoding
Evidence: Mixed
Revision: Available · 8 questions · 5 flashcards
Exam relevance
CompTIA Security+
Verified for Security+: 0 of 8 questions and 1 of 5 flashcards. The mapping does not verify the others.
Reviewed revision scope
- Classroom (Session 9): cryptography, cryptanalysis and cryptology; plaintext, ciphertext and ciphers; encoding and encryption; the Caesar cipher and substitution; Enigma as a historical example; Alice, Bob and Mallory; Kerckhoffs’s principle; and key length, keyspace and brute force were covered.
- Supplementary: cryptography is the practice of protecting information by transforming it so that only intended parties can read or trust it; cryptanalysis is the study of breaking that protection; cryptology covers both. A cipher is an algorithm that turns plaintext into ciphertext under the control of a key, and decryption reverses it with the right key.
- Supplementary: encoding changes how data is represented, using a public scheme and no key, so anyone can reverse it; encryption needs a secret key to reverse. Encoding such as Base64 gives no confidentiality.
- Supplementary: the Caesar cipher shifts each letter by a fixed number of places and is a substitution cipher; with only 25 useful shifts it falls to trying every key, and simple substitution with a mixed alphabet falls to letter-frequency analysis.
- Supplementary: Kerckhoffs’s principle says a system should stay secure when everything about it except the key is public, so security rests on keeping the key secret and not on hiding the algorithm.
- Supplementary: the keyspace is the number of possible keys; a key of n bits has 2 to the power n possible values, each added bit doubles the work of a brute-force attack, which tries every key, and key lengths are comparable only within the same kind of algorithm.
- Supplementary: by convention, Alice and Bob are the parties who want to communicate securely and Mallory is a malicious attacker who can intercept and alter messages.
Outside the authored revision scope
- How the Enigma machine worked internally or how it was broken
- Configuring or operating these technologies in practice
- The mathematics of the algorithms beyond the level stated
- The exact wording of the session material
Recorded evidence
- Classroom (Session 9): cryptography, cryptanalysis and cryptology; plaintext, ciphertext and ciphers; encoding and encryption; the Caesar cipher and substitution; Enigma as a historical example; Alice, Bob and Mallory; Kerckhoffs’s principle; and key length, keyspace and brute force were covered.
- Supplementary: cryptography is the practice of protecting information by transforming it so that only intended parties can read or trust it; cryptanalysis is the study of breaking that protection; cryptology covers both. A cipher is an algorithm that turns plaintext into ciphertext under the control of a key, and decryption reverses it with the right key.
- Supplementary: encoding changes how data is represented, using a public scheme and no key, so anyone can reverse it; encryption needs a secret key to reverse. Encoding such as Base64 gives no confidentiality.
- Supplementary: the Caesar cipher shifts each letter by a fixed number of places and is a substitution cipher; with only 25 useful shifts it falls to trying every key, and simple substitution with a mixed alphabet falls to letter-frequency analysis.
- Supplementary: Kerckhoffs’s principle says a system should stay secure when everything about it except the key is public, so security rests on keeping the key secret and not on hiding the algorithm.
- Supplementary: the keyspace is the number of possible keys; a key of n bits has 2 to the power n possible values, each added bit doubles the work of a brute-force attack, which tries every key, and key lengths are comparable only within the same kind of algorithm.
- Supplementary: by convention, Alice and Bob are the parties who want to communicate securely and Mallory is a malicious attacker who can intercept and alter messages.
- Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions — Classroom session record · Cryptography, cryptanalysis and ciphers; Encoding and encryption; The Caesar cipher and Enigma; Symmetric encryption and AES; Asymmetric encryption, RSA and ECC; Key length, keyspace and brute force; Hashing and the SHA families; Hash resistance properties and collisions; Checksums and integrity verification; Rainbow tables and password cracking; Digital signatures; Public key infrastructure and certificate authorities; Digital certificates and X.509; Root, intermediate and leaf certificates; Self-signed certificates and certificate signing requests; Common Name and Subject Alternative Name; Certificate validity, expiry and revocation; Key lifecycle and key management; Entropy and randomness; TPMs, HSMs and secure enclaves; FIPS 140-2 and FIPS 140-3; Key escrow and M-of-N recovery; Confidentiality and the states of data; Hybrid encryption; Disk, partition and file encryption; Database and record-level encryption; Transport encryption, TLS and HTTPS; Key agreement, ephemeral keys and forward secrecy; Salting, stretching and peppering; Blockchain; Steganography, data masking and tokenisation; De-identification and anonymisation; Tutor demonstrations; Classroom review of cryptographic algorithms
- Cryptography Foundations: Ciphers, Keys and Encoding — Supplementary Study Guide explanation · The idea; Three words that sound alike; Encoding is not encryption; A cipher you can break yourself; Enigma: a historical example; Alice, Bob and Mallory; Kerckhoffs’s principle; Key length, keyspace and brute force
Not established by the recorded evidence
- How the Enigma machine worked internally or how it was broken
- Configuring or operating these technologies in practice
- The mathematics of the algorithms beyond the level stated
- The exact wording of the session material
Authored and machine-validated on 12 October 2026; owner review pending. Checked during authoring against the Session 9 Learning Log and the Cryptography Foundations: Ciphers, Keys and Encoding lesson Sources and scope section. Scope statements are labelled Classroom or Supplementary: Classroom statements record what the session covered, and beginner-first wording developed afterwards is labelled Supplementary. The concept is mapped to the Security+ objectives named in its mappings; that mapping verifies none of its questions or flashcards, and no practical competence or completed assessment is implied.
Cryptographic Hardware: TPM, HSM, Secure Enclave and FIPS 140
Evidence: Mixed
Revision: Available · 7 questions · 4 flashcards
Exam relevance
CompTIA Security+
Verified for Security+: 4 of 7 questions and 2 of 4 flashcards. The mapping does not verify the others.
Reviewed revision scope
- Classroom (Session 9): Trusted Platform Modules (TPMs), hardware security modules (HSMs), secure enclaves, and the FIPS 140-2 and FIPS 140-3 standards were covered.
- Supplementary: a Trusted Platform Module (TPM) is a security chip built into one device that generates and protects keys for that device and can release them only when the device starts in an expected state; it does not necessarily hold every encryption key, and commonly protects a key that in turn protects others stored on the drive.
- Supplementary: a hardware security module (HSM) is a dedicated, tamper-resistant device or service that generates, stores and uses keys on behalf of many systems, such as a certificate authority’s signing keys, without releasing them.
- Supplementary: a secure enclave is an isolated, protected area of a processor or system-on-chip that keeps keys and sensitive processing apart from the main operating system, protecting data while it is in use.
- Supplementary: FIPS 140 is the United States government standard for validating cryptographic modules; FIPS 140-3 supersedes FIPS 140-2, and a validation applies to a specific module, not to a whole product or organisation.
Outside the authored revision scope
- FIPS 140 security levels and testing procedures
- Specific hardware products
- Configuring or operating these technologies in practice
- The mathematics of the algorithms beyond the level stated
- The exact wording of the session material
Recorded evidence
- Classroom (Session 9): Trusted Platform Modules (TPMs), hardware security modules (HSMs), secure enclaves, and the FIPS 140-2 and FIPS 140-3 standards were covered.
- Supplementary: a Trusted Platform Module (TPM) is a security chip built into one device that generates and protects keys for that device and can release them only when the device starts in an expected state; it does not necessarily hold every encryption key, and commonly protects a key that in turn protects others stored on the drive.
- Supplementary: a hardware security module (HSM) is a dedicated, tamper-resistant device or service that generates, stores and uses keys on behalf of many systems, such as a certificate authority’s signing keys, without releasing them.
- Supplementary: a secure enclave is an isolated, protected area of a processor or system-on-chip that keeps keys and sensitive processing apart from the main operating system, protecting data while it is in use.
- Supplementary: FIPS 140 is the United States government standard for validating cryptographic modules; FIPS 140-3 supersedes FIPS 140-2, and a validation applies to a specific module, not to a whole product or organisation.
- Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions — Classroom session record · Cryptography, cryptanalysis and ciphers; Encoding and encryption; The Caesar cipher and Enigma; Symmetric encryption and AES; Asymmetric encryption, RSA and ECC; Key length, keyspace and brute force; Hashing and the SHA families; Hash resistance properties and collisions; Checksums and integrity verification; Rainbow tables and password cracking; Digital signatures; Public key infrastructure and certificate authorities; Digital certificates and X.509; Root, intermediate and leaf certificates; Self-signed certificates and certificate signing requests; Common Name and Subject Alternative Name; Certificate validity, expiry and revocation; Key lifecycle and key management; Entropy and randomness; TPMs, HSMs and secure enclaves; FIPS 140-2 and FIPS 140-3; Key escrow and M-of-N recovery; Confidentiality and the states of data; Hybrid encryption; Disk, partition and file encryption; Database and record-level encryption; Transport encryption, TLS and HTTPS; Key agreement, ephemeral keys and forward secrecy; Salting, stretching and peppering; Blockchain; Steganography, data masking and tokenisation; De-identification and anonymisation; Tutor demonstrations; Classroom review of cryptographic algorithms
- Key Management, Cryptographic Hardware and Escrow — Supplementary Study Guide explanation · The key lifecycle; Entropy and randomness; Centralised and decentralised key management; KMIP; Hardware that protects keys; Trusted Platform Module; A TPM does not hold every key; Hardware security modules; Secure enclaves; FIPS 140-2 and FIPS 140-3; Key escrow; M-of-N control
Not established by the recorded evidence
- FIPS 140 security levels and testing procedures
- Specific hardware products
- Configuring or operating these technologies in practice
- The mathematics of the algorithms beyond the level stated
- The exact wording of the session material
Authored and machine-validated on 12 October 2026; owner review pending. Checked during authoring against the Session 9 Learning Log and the Key Management, Cryptographic Hardware and Escrow lesson Sources and scope section. Scope statements are labelled Classroom or Supplementary: Classroom statements record what the session covered, and beginner-first wording developed afterwards is labelled Supplementary. The concept is mapped to the Security+ objectives named in its mappings; that mapping verifies none of its questions or flashcards, and no practical competence or completed assessment is implied.
Cryptographic mechanisms and PKI
Evidence: Not yet recorded
Revision: Available · 1 question · 1 flashcard
Exam relevance
CompTIA Security+CREST CPSACREST CPIA
- Security+ · 1.4 · direct
This concept relates to the cited objective. Course coverage and authored revision do not establish full objective coverage.
- CPSA · B11 · direct
This concept relates to the cited objective. Course coverage and authored revision do not establish full objective coverage.
- CPIA · B7 · direct
This concept relates to the cited objective. Course coverage and authored revision do not establish full objective coverage.
Verified for Security+: 0 of 1 question and 1 of 1 flashcard. The mapping does not verify the others.
Verified for CPSA: 0 of 1 question and 0 of 1 flashcard. The mapping does not verify the others.
Verified for CPIA: 0 of 1 question and 0 of 1 flashcard. The mapping does not verify the others.
Reviewed revision scope
- Symmetric cryptography uses the same secret key for encryption and decryption.
- Asymmetric cryptography uses a related public key and private key.
Outside the authored revision scope
- PKI certificate lifecycle
- Algorithm implementation
- Hashing and HMAC
- Key distribution protocols
Recorded evidence
Not yet recorded in classroom, Study Buddy or Study Guide learning. This does not prevent revision.
Not established by the recorded evidence
- Symmetric/asymmetric cryptography
- Hashing/HMAC
- Full PKI
Reviewed 2026-09-16. Revision key models verified against NIST definitions and Security+ 1.4 / CPSA B11 / CPIA B7. This concept’s own course evidence remains unrecorded: its question and flashcard are reference-backed. Note added 13 October 2026: PKI and wider cryptography have since been authored as separate Module 6 concepts, which hold the Session 9 course evidence; this concept is retained unchanged by owner decision.
Obfuscation: Steganography, Masking, Tokenisation and De-identification
Evidence: Mixed
Revision: Available · 8 questions · 4 flashcards
Exam relevance
CompTIA Security+
- Security+ · 1.4 · direct
Mapped on 12 October 2026 for the “Obfuscation” sub-bullets “Steganography”, “Tokenization” and “Data masking” only. Course coverage and authored revision do not establish full objective coverage.
- Security+ · 3.3 · direct
Mapped on 12 October 2026 for the “Methods to secure data” sub-bullets “Masking”, “Tokenization” and “Obfuscation” only. Course coverage and authored revision do not establish full objective coverage.
Verified for Security+: 4 of 8 questions and 3 of 4 flashcards. The mapping does not verify the others.
Reviewed revision scope
- Classroom (Session 9): steganography, data masking, tokenisation, and de-identification and anonymisation were covered.
- Supplementary: steganography hides the existence of information inside other, ordinary-looking data such as an image; it conceals that a message exists, whereas encryption conceals what a message says.
- Supplementary: data masking replaces all or part of a value with substitute characters or realistic fictitious data, so that the result can be displayed or used for testing without exposing the original.
- Supplementary: tokenisation replaces a sensitive value with a token that has no mathematical relationship to it; the mapping is held in a separately protected token vault, so a token cannot be reversed with a key the way ciphertext can be decrypted.
- Supplementary: de-identification removes or alters direct identifiers; it does not necessarily make data anonymous, because individuals may still be re-identifiable from what remains or by combining it with other data. Pseudonymised data, where identifiers are replaced but a key to them is kept, is still personal data; anonymisation means individuals are no longer identifiable.
- Supplementary: sharing aggregated statistics instead of individual records, and suppressing very small counts, reduces the chance that anyone can be singled out.
Outside the authored revision scope
- Legal advice on data protection
- Steganography tools and detection techniques
- Configuring or operating these technologies in practice
- The mathematics of the algorithms beyond the level stated
- The exact wording of the session material
Recorded evidence
- Classroom (Session 9): steganography, data masking, tokenisation, and de-identification and anonymisation were covered.
- Supplementary: steganography hides the existence of information inside other, ordinary-looking data such as an image; it conceals that a message exists, whereas encryption conceals what a message says.
- Supplementary: data masking replaces all or part of a value with substitute characters or realistic fictitious data, so that the result can be displayed or used for testing without exposing the original.
- Supplementary: tokenisation replaces a sensitive value with a token that has no mathematical relationship to it; the mapping is held in a separately protected token vault, so a token cannot be reversed with a key the way ciphertext can be decrypted.
- Supplementary: de-identification removes or alters direct identifiers; it does not necessarily make data anonymous, because individuals may still be re-identifiable from what remains or by combining it with other data. Pseudonymised data, where identifiers are replaced but a key to them is kept, is still personal data; anonymisation means individuals are no longer identifiable.
- Supplementary: sharing aggregated statistics instead of individual records, and suppressing very small counts, reduces the chance that anyone can be singled out.
- Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions — Classroom session record · Cryptography, cryptanalysis and ciphers; Encoding and encryption; The Caesar cipher and Enigma; Symmetric encryption and AES; Asymmetric encryption, RSA and ECC; Key length, keyspace and brute force; Hashing and the SHA families; Hash resistance properties and collisions; Checksums and integrity verification; Rainbow tables and password cracking; Digital signatures; Public key infrastructure and certificate authorities; Digital certificates and X.509; Root, intermediate and leaf certificates; Self-signed certificates and certificate signing requests; Common Name and Subject Alternative Name; Certificate validity, expiry and revocation; Key lifecycle and key management; Entropy and randomness; TPMs, HSMs and secure enclaves; FIPS 140-2 and FIPS 140-3; Key escrow and M-of-N recovery; Confidentiality and the states of data; Hybrid encryption; Disk, partition and file encryption; Database and record-level encryption; Transport encryption, TLS and HTTPS; Key agreement, ephemeral keys and forward secrecy; Salting, stretching and peppering; Blockchain; Steganography, data masking and tokenisation; De-identification and anonymisation; Tutor demonstrations; Classroom review of cryptographic algorithms
- Obfuscation: Steganography, Masking, Tokenisation and De-identification — Supplementary Study Guide explanation · Four techniques at a glance; Steganography; Data masking; Tokenisation; Tokenisation is not encryption; De-identification and anonymisation; Choosing between them
Not established by the recorded evidence
- Legal advice on data protection
- Steganography tools and detection techniques
- Configuring or operating these technologies in practice
- The mathematics of the algorithms beyond the level stated
- The exact wording of the session material
Authored and machine-validated on 12 October 2026; owner review pending. Checked during authoring against the Session 9 Learning Log and the Obfuscation: Steganography, Masking, Tokenisation and De-identification lesson Sources and scope section. Scope statements are labelled Classroom or Supplementary: Classroom statements record what the session covered, and beginner-first wording developed afterwards is labelled Supplementary. The concept is mapped to the Security+ objectives named in its mappings; that mapping verifies none of its questions or flashcards, and no practical competence or completed assessment is implied.
Personal data and UK GDPR principles
Evidence: Supplementary
Revision: Available · 1 question · 1 flashcard
Exam relevance
Learning-only · no verified exam mapping
Reviewed revision scope
- The approved educational explanation covers personal data and the seven Article 5 principles: lawfulness, fairness and transparency; purpose limitation; minimisation; accuracy; storage limitation; integrity and confidentiality; accountability.
Outside the authored revision scope
- Completed professional practice or legal advice
- Complete exam objectives or verified exam alignment
Recorded evidence
- The approved educational explanation covers personal data and the seven Article 5 principles: lawfulness, fairness and transparency; purpose limitation; minimisation; accuracy; storage limitation; integrity and confidentiality; accountability.
- Data Protection: UK GDPR and the DPA 2018 — Supplementary Study Guide explanation · The seven data-protection principles; Lawful bases and current law; Controllers, processors and service providers; Worked breach assessment
Not established by the recorded evidence
- Completed professional practice or legal advice
- Complete exam objectives or verified exam alignment
- Material outside the named introductory scope
Reviewed 2026-09-22. Reviewed against approved Sessions 3–4 learning and Core Concepts explanations. Fictional applications are educational elaborations, not completed practical work. Learning-only; this concept has not yet been individually verified against the Security+ SY0-701 objectives or any other exam syllabus. Coverage derives from the approved Core Concepts learning extension, not a claim of explicit classroom teaching.
Data States and Levels of Encryption
Evidence: Mixed
Revision: Available · 10 questions · 5 flashcards
Exam relevance
CompTIA Security+
- Security+ · 1.4 · direct
Mapped on 12 October 2026 for the “Encryption” sub-bullet “Level” (full-disk, partition, file, volume, database and record) only. Course coverage and authored revision do not establish full objective coverage.
- Security+ · 3.3 · direct
Mapped on 12 October 2026 for the “General data considerations” sub-bullet “Data states” (data at rest, data in transit and data in use) only. Course coverage and authored revision do not establish full objective coverage.
Verified for Security+: 8 of 10 questions and 4 of 5 flashcards. The mapping does not verify the others.
Reviewed revision scope
- Classroom (Session 9): confidentiality; data at rest, in transit and in use; full-disk and partition encryption; BitLocker and the Encrypting File System (EFS); self-encrypting drives; and database and record-level encryption were covered.
- Supplementary: data at rest is stored, data in transit is moving across a network, and data in use is being processed in memory; each state needs its own protection, and encrypting one state does not protect the others.
- Supplementary: full-disk encryption protects everything on a drive against loss or theft of the powered-off device, but once the device is unlocked and running, the data is available to whoever or whatever is signed in; partition and volume encryption protect one area of a drive, and file-level encryption protects chosen files and can differ for each user.
- Supplementary: BitLocker encrypts whole volumes in Windows and EFS encrypts individual files for a user account; a self-encrypting drive (SED) performs the encryption in the drive’s own hardware.
- Supplementary: database encryption can protect the whole database’s stored files, a column or individual records; whole-database encryption does not hide data from an account or application that is authorised to query it, while record-level and column-level encryption can keep specific data from database users and administrators who lack the key.
Outside the authored revision scope
- Deploying or recovering BitLocker, EFS or a self-encrypting drive
- Specific database products
- Configuring or operating these technologies in practice
- The mathematics of the algorithms beyond the level stated
- The exact wording of the session material
Recorded evidence
- Classroom (Session 9): confidentiality; data at rest, in transit and in use; full-disk and partition encryption; BitLocker and the Encrypting File System (EFS); self-encrypting drives; and database and record-level encryption were covered.
- Supplementary: data at rest is stored, data in transit is moving across a network, and data in use is being processed in memory; each state needs its own protection, and encrypting one state does not protect the others.
- Supplementary: full-disk encryption protects everything on a drive against loss or theft of the powered-off device, but once the device is unlocked and running, the data is available to whoever or whatever is signed in; partition and volume encryption protect one area of a drive, and file-level encryption protects chosen files and can differ for each user.
- Supplementary: BitLocker encrypts whole volumes in Windows and EFS encrypts individual files for a user account; a self-encrypting drive (SED) performs the encryption in the drive’s own hardware.
- Supplementary: database encryption can protect the whole database’s stored files, a column or individual records; whole-database encryption does not hide data from an account or application that is authorised to query it, while record-level and column-level encryption can keep specific data from database users and administrators who lack the key.
- Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions — Classroom session record · Cryptography, cryptanalysis and ciphers; Encoding and encryption; The Caesar cipher and Enigma; Symmetric encryption and AES; Asymmetric encryption, RSA and ECC; Key length, keyspace and brute force; Hashing and the SHA families; Hash resistance properties and collisions; Checksums and integrity verification; Rainbow tables and password cracking; Digital signatures; Public key infrastructure and certificate authorities; Digital certificates and X.509; Root, intermediate and leaf certificates; Self-signed certificates and certificate signing requests; Common Name and Subject Alternative Name; Certificate validity, expiry and revocation; Key lifecycle and key management; Entropy and randomness; TPMs, HSMs and secure enclaves; FIPS 140-2 and FIPS 140-3; Key escrow and M-of-N recovery; Confidentiality and the states of data; Hybrid encryption; Disk, partition and file encryption; Database and record-level encryption; Transport encryption, TLS and HTTPS; Key agreement, ephemeral keys and forward secrecy; Salting, stretching and peppering; Blockchain; Steganography, data masking and tokenisation; De-identification and anonymisation; Tutor demonstrations; Classroom review of cryptographic algorithms
- Data States and Encryption at Rest — Supplementary Study Guide explanation · The three states of data; Levels of encryption for data at rest; Full-disk encryption; Partition and volume encryption; File-level encryption; BitLocker and EFS; Self-encrypting drives; Database and record-level encryption; Whole-database encryption; Column and record-level encryption
Not established by the recorded evidence
- Deploying or recovering BitLocker, EFS or a self-encrypting drive
- Specific database products
- Configuring or operating these technologies in practice
- The mathematics of the algorithms beyond the level stated
- The exact wording of the session material
Authored and machine-validated on 12 October 2026; owner review pending. Checked during authoring against the Session 9 Learning Log and the Data States and Encryption at Rest lesson Sources and scope section. Scope statements are labelled Classroom or Supplementary: Classroom statements record what the session covered, and beginner-first wording developed afterwards is labelled Supplementary. The concept is mapped to the Security+ objectives named in its mappings; that mapping verifies none of its questions or flashcards, and no practical competence or completed assessment is implied.
Digital Signatures
Evidence: Mixed
Revision: Available · 8 questions · 4 flashcards
Exam relevance
CompTIA Security+
Verified for Security+: 5 of 8 questions and 3 of 4 flashcards. The mapping does not verify the others.
Reviewed revision scope
- Classroom (Session 9): digital signatures; integrity, authentication and non-repudiation; and the difference between encryption and signing were covered.
- Supplementary: to sign, the signer hashes the content and uses their private key to produce a signature over the digest; to verify, anyone recomputes the digest and checks the signature against it with the signer’s public key.
- Supplementary: a valid signature shows that the content has not changed since signing (integrity) and that it was produced with the private key matching the public key used (authentication of origin), and so gives evidence for non-repudiation; it does not keep the content confidential.
- Supplementary: encryption for confidentiality uses the recipient’s public key to encrypt and the recipient’s private key to decrypt; signing uses the signer’s private key to sign and the signer’s public key to verify. The key pairs are used for different purposes, and signing hides nothing.
- Supplementary: non-repudiation is evidence, not an unconditional guarantee: a valid signature shows that a particular private key was used, and its weight depends on that key having been under the signer’s sole control and on the certificate, timestamp and records around it.
Outside the authored revision scope
- The legal status of electronic signatures
- Individual signature algorithms and their parameters
- Configuring or operating these technologies in practice
- The mathematics of the algorithms beyond the level stated
- The exact wording of the session material
Recorded evidence
- Classroom (Session 9): digital signatures; integrity, authentication and non-repudiation; and the difference between encryption and signing were covered.
- Supplementary: to sign, the signer hashes the content and uses their private key to produce a signature over the digest; to verify, anyone recomputes the digest and checks the signature against it with the signer’s public key.
- Supplementary: a valid signature shows that the content has not changed since signing (integrity) and that it was produced with the private key matching the public key used (authentication of origin), and so gives evidence for non-repudiation; it does not keep the content confidential.
- Supplementary: encryption for confidentiality uses the recipient’s public key to encrypt and the recipient’s private key to decrypt; signing uses the signer’s private key to sign and the signer’s public key to verify. The key pairs are used for different purposes, and signing hides nothing.
- Supplementary: non-repudiation is evidence, not an unconditional guarantee: a valid signature shows that a particular private key was used, and its weight depends on that key having been under the signer’s sole control and on the certificate, timestamp and records around it.
- Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions — Classroom session record · Cryptography, cryptanalysis and ciphers; Encoding and encryption; The Caesar cipher and Enigma; Symmetric encryption and AES; Asymmetric encryption, RSA and ECC; Key length, keyspace and brute force; Hashing and the SHA families; Hash resistance properties and collisions; Checksums and integrity verification; Rainbow tables and password cracking; Digital signatures; Public key infrastructure and certificate authorities; Digital certificates and X.509; Root, intermediate and leaf certificates; Self-signed certificates and certificate signing requests; Common Name and Subject Alternative Name; Certificate validity, expiry and revocation; Key lifecycle and key management; Entropy and randomness; TPMs, HSMs and secure enclaves; FIPS 140-2 and FIPS 140-3; Key escrow and M-of-N recovery; Confidentiality and the states of data; Hybrid encryption; Disk, partition and file encryption; Database and record-level encryption; Transport encryption, TLS and HTTPS; Key agreement, ephemeral keys and forward secrecy; Salting, stretching and peppering; Blockchain; Steganography, data masking and tokenisation; De-identification and anonymisation; Tutor demonstrations; Classroom review of cryptographic algorithms
- Digital Signatures — Supplementary Study Guide explanation · The idea; Signing and verifying, step by step; What happens if the document is changed; What a signature provides; Encryption and signing use the keys differently; Non-repudiation: evidence, not certainty; Where digital signatures are used
Not established by the recorded evidence
- The legal status of electronic signatures
- Individual signature algorithms and their parameters
- Configuring or operating these technologies in practice
- The mathematics of the algorithms beyond the level stated
- The exact wording of the session material
Authored and machine-validated on 12 October 2026; owner review pending. Checked during authoring against the Session 9 Learning Log and the Digital Signatures lesson Sources and scope section. Scope statements are labelled Classroom or Supplementary: Classroom statements record what the session covered, and beginner-first wording developed afterwards is labelled Supplementary. The concept is mapped to the Security+ objectives named in its mappings; that mapping verifies none of its questions or flashcards, and no practical competence or completed assessment is implied.
Hashing and Integrity Checking
Evidence: Mixed
Revision: Available · 10 questions · 6 flashcards
Exam relevance
CompTIA Security+
- Security+ · 1.4 · direct
Mapped on 12 October 2026 for the “Hashing” bullet only. Course coverage and authored revision do not establish full objective coverage.
- Security+ · 2.4 · direct
Mapped on 13 October 2026 for the “Cryptographic attacks” sub-bullets “Collision” and “Birthday” only. Course coverage and authored revision do not establish full objective coverage.
Verified for Security+: 6 of 10 questions and 5 of 6 flashcards. The mapping does not verify the others.
Reviewed revision scope
- Classroom (Session 9): the SHA families, SHA-256 and SHA-512; weaknesses in MD5 and SHA-1; fixed-length digests; preimage and collision resistance; hash collisions and the birthday bound; and checksums and integrity verification were covered.
- Supplementary: a cryptographic hash function turns input of any size into a fixed-length digest; it is one-way, uses no key, and cannot be decrypted, so a hash is not encrypted data. A small change to the input produces a completely different digest.
- Supplementary: preimage resistance means a digest cannot feasibly be turned back into an input that produces it; collision resistance means two different inputs with the same digest cannot feasibly be found. Collisions must exist because inputs outnumber digests; a secure hash makes them infeasible to find.
- Supplementary: because of the birthday effect, finding some collision takes roughly 2 to the power n/2 attempts for an n-bit digest, far fewer than finding a preimage; practical collisions have been produced for MD5 and SHA-1, which are unsuitable where collision resistance matters, and SHA-256 and SHA-512 belong to the SHA-2 family in current use.
- Supplementary: comparing a file’s computed digest with a published checksum detects accidental or deliberate change only if the published value comes from a source the attacker could not also change; a checksum alone says nothing about who produced the file.
Outside the authored revision scope
- Keyed hashes such as HMAC
- The internal construction of the SHA algorithms
- Configuring or operating these technologies in practice
- The mathematics of the algorithms beyond the level stated
- The exact wording of the session material
Recorded evidence
- Classroom (Session 9): the SHA families, SHA-256 and SHA-512; weaknesses in MD5 and SHA-1; fixed-length digests; preimage and collision resistance; hash collisions and the birthday bound; and checksums and integrity verification were covered.
- Supplementary: a cryptographic hash function turns input of any size into a fixed-length digest; it is one-way, uses no key, and cannot be decrypted, so a hash is not encrypted data. A small change to the input produces a completely different digest.
- Supplementary: preimage resistance means a digest cannot feasibly be turned back into an input that produces it; collision resistance means two different inputs with the same digest cannot feasibly be found. Collisions must exist because inputs outnumber digests; a secure hash makes them infeasible to find.
- Supplementary: because of the birthday effect, finding some collision takes roughly 2 to the power n/2 attempts for an n-bit digest, far fewer than finding a preimage; practical collisions have been produced for MD5 and SHA-1, which are unsuitable where collision resistance matters, and SHA-256 and SHA-512 belong to the SHA-2 family in current use.
- Supplementary: comparing a file’s computed digest with a published checksum detects accidental or deliberate change only if the published value comes from a source the attacker could not also change; a checksum alone says nothing about who produced the file.
- Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions — Classroom session record · Cryptography, cryptanalysis and ciphers; Encoding and encryption; The Caesar cipher and Enigma; Symmetric encryption and AES; Asymmetric encryption, RSA and ECC; Key length, keyspace and brute force; Hashing and the SHA families; Hash resistance properties and collisions; Checksums and integrity verification; Rainbow tables and password cracking; Digital signatures; Public key infrastructure and certificate authorities; Digital certificates and X.509; Root, intermediate and leaf certificates; Self-signed certificates and certificate signing requests; Common Name and Subject Alternative Name; Certificate validity, expiry and revocation; Key lifecycle and key management; Entropy and randomness; TPMs, HSMs and secure enclaves; FIPS 140-2 and FIPS 140-3; Key escrow and M-of-N recovery; Confidentiality and the states of data; Hybrid encryption; Disk, partition and file encryption; Database and record-level encryption; Transport encryption, TLS and HTTPS; Key agreement, ephemeral keys and forward secrecy; Salting, stretching and peppering; Blockchain; Steganography, data masking and tokenisation; De-identification and anonymisation; Tutor demonstrations; Classroom review of cryptographic algorithms
- Hashing and Integrity Checking — Supplementary Study Guide explanation · The idea; A hash is not encryption; The SHA families; What makes a hash secure; Preimage resistance; Collision resistance; Collisions must exist; The birthday effect; Why MD5 and SHA-1 are no longer suitable; Checksums and verifying a download; Where hashes are used
Not established by the recorded evidence
- Keyed hashes such as HMAC
- The internal construction of the SHA algorithms
- Configuring or operating these technologies in practice
- The mathematics of the algorithms beyond the level stated
- The exact wording of the session material
Authored and machine-validated on 12 October 2026; owner review pending. Checked during authoring against the Session 9 Learning Log and the Hashing and Integrity Checking lesson Sources and scope section. Scope statements are labelled Classroom or Supplementary: Classroom statements record what the session covered, and beginner-first wording developed afterwards is labelled Supplementary. The concept is mapped to the Security+ objectives named in its mappings; that mapping verifies none of its questions or flashcards, and no practical competence or completed assessment is implied.
Information classification and handling
Evidence: Mixed
Revision: Available · 2 questions · 2 flashcards
Exam relevance
Learning-only · no verified exam mapping
Reviewed revision scope
- Public, Internal, Confidential and Secret/Restricted are illustrative organisational labels; access, storage, sharing, retention and disposal controls follow sensitivity and purpose, while personal-data status is a separate legal question.
Outside the authored revision scope
- Completed professional practice or legal advice
- Complete exam objectives or verified exam alignment
Recorded evidence
- Public, Internal, Confidential and Secret/Restricted are illustrative organisational labels; access, storage, sharing, retention and disposal controls follow sensitivity and purpose, while personal-data status is a separate legal question.
- Session 3: Governance, Risk and Compliance — Classroom session record · Governance and Accountability; Risk and Measurement; Risk Management Lifecycle; Risk Treatment; Compliance Is Not the Same as Security; Risk Appetite vs Risk Tolerance; CVSS and Business Risk; ISO/IEC 27001 and 27002; Cyber Essentials; NIST Cybersecurity Framework; UK GDPR and Data Protection; Data Classification; UK GDPR Lawful Bases; ICO and the 72-Hour Rule; PCI DSS
- Session 4: Governance, Risk and Compliance — In Depth — Classroom session record · The Three GRC Pillars; Compliance ≠ Security; ISO/IEC 27001 and Continual Improvement; Why Consultants Need Business Context; Business Impact Analysis; Assessing Risk; Identifying and Managing Risk; Frameworks and Standards; UK GDPR and Data Protection; Data Classification and Handling
- Data Classification — Supplementary Study Guide explanation · Four classification tiers; From label to handling; Worked document lifecycle; Classification and personal data are different questions
Not established by the recorded evidence
- Completed professional practice or legal advice
- Complete exam objectives or verified exam alignment
- Material outside the named introductory scope
Reviewed 2026-09-22. Reviewed against approved Sessions 3–4 learning and Core Concepts explanations. Fictional applications are educational elaborations, not completed practical work. Learning-only; this concept has not yet been individually verified against the Security+ SY0-701 objectives or any other exam syllabus.
Key Management: Lifecycle, Randomness and Escrow
Evidence: Mixed
Revision: Available · 8 questions · 6 flashcards
Exam relevance
CompTIA Security+
Verified for Security+: 2 of 8 questions and 2 of 6 flashcards. The mapping does not verify the others.
Reviewed revision scope
- Classroom (Session 9): the cryptographic key lifecycle; centralised and decentralised key management; the Key Management Interoperability Protocol (KMIP); entropy and cryptographic randomness; key escrow; and M-of-N threshold recovery were covered.
- Supplementary: a key has a lifecycle of generation, distribution, storage, use, rotation, backup or archival, revocation and destruction, and a key is only as strong as the weakest of those stages; rotation replaces a key with a new one on a planned basis or after suspected exposure.
- Supplementary: centralised key management generates and stores keys in a dedicated system that issues them to the services that need them; decentralised management leaves each system or user to generate and hold its own keys. KMIP is a standard protocol that lets applications and devices from different vendors communicate with a key management server.
- Supplementary: keys must be generated from unpredictable random values; entropy is the measure of that unpredictability, and a key generated from too little entropy can be guessed however long it is.
- Supplementary: key escrow places a copy of a key with a trusted party so that data can be recovered if the key or its holder is unavailable; an escrowed copy is another copy to protect, so access to it must be controlled and recorded. M-of-N control splits the authority to recover or use a key among N people so that any M of them must act together.
Outside the authored revision scope
- Specific key management products
- Random number generator design
- Configuring or operating these technologies in practice
- The mathematics of the algorithms beyond the level stated
- The exact wording of the session material
Recorded evidence
- Classroom (Session 9): the cryptographic key lifecycle; centralised and decentralised key management; the Key Management Interoperability Protocol (KMIP); entropy and cryptographic randomness; key escrow; and M-of-N threshold recovery were covered.
- Supplementary: a key has a lifecycle of generation, distribution, storage, use, rotation, backup or archival, revocation and destruction, and a key is only as strong as the weakest of those stages; rotation replaces a key with a new one on a planned basis or after suspected exposure.
- Supplementary: centralised key management generates and stores keys in a dedicated system that issues them to the services that need them; decentralised management leaves each system or user to generate and hold its own keys. KMIP is a standard protocol that lets applications and devices from different vendors communicate with a key management server.
- Supplementary: keys must be generated from unpredictable random values; entropy is the measure of that unpredictability, and a key generated from too little entropy can be guessed however long it is.
- Supplementary: key escrow places a copy of a key with a trusted party so that data can be recovered if the key or its holder is unavailable; an escrowed copy is another copy to protect, so access to it must be controlled and recorded. M-of-N control splits the authority to recover or use a key among N people so that any M of them must act together.
- Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions — Classroom session record · Cryptography, cryptanalysis and ciphers; Encoding and encryption; The Caesar cipher and Enigma; Symmetric encryption and AES; Asymmetric encryption, RSA and ECC; Key length, keyspace and brute force; Hashing and the SHA families; Hash resistance properties and collisions; Checksums and integrity verification; Rainbow tables and password cracking; Digital signatures; Public key infrastructure and certificate authorities; Digital certificates and X.509; Root, intermediate and leaf certificates; Self-signed certificates and certificate signing requests; Common Name and Subject Alternative Name; Certificate validity, expiry and revocation; Key lifecycle and key management; Entropy and randomness; TPMs, HSMs and secure enclaves; FIPS 140-2 and FIPS 140-3; Key escrow and M-of-N recovery; Confidentiality and the states of data; Hybrid encryption; Disk, partition and file encryption; Database and record-level encryption; Transport encryption, TLS and HTTPS; Key agreement, ephemeral keys and forward secrecy; Salting, stretching and peppering; Blockchain; Steganography, data masking and tokenisation; De-identification and anonymisation; Tutor demonstrations; Classroom review of cryptographic algorithms
- Key Management, Cryptographic Hardware and Escrow — Supplementary Study Guide explanation · The key lifecycle; Entropy and randomness; Centralised and decentralised key management; KMIP; Hardware that protects keys; Trusted Platform Module; A TPM does not hold every key; Hardware security modules; Secure enclaves; FIPS 140-2 and FIPS 140-3; Key escrow; M-of-N control
Not established by the recorded evidence
- Specific key management products
- Random number generator design
- Configuring or operating these technologies in practice
- The mathematics of the algorithms beyond the level stated
- The exact wording of the session material
Authored and machine-validated on 12 October 2026; owner review pending. Checked during authoring against the Session 9 Learning Log and the Key Management, Cryptographic Hardware and Escrow lesson Sources and scope section. Scope statements are labelled Classroom or Supplementary: Classroom statements record what the session covered, and beginner-first wording developed afterwards is labelled Supplementary. The concept is mapped to the Security+ objectives named in its mappings; that mapping verifies none of its questions or flashcards, and no practical competence or completed assessment is implied.
Lawful bases and special category data
Evidence: Mixed
Revision: Available · 2 questions · 2 flashcards
Exam relevance
Learning-only · no verified exam mapping
Reviewed revision scope
- A basis must fit the processing purpose before processing; consent is not universal; the six taught Article 6 bases need the current recognised legitimate interest addition; special category data generally needs an Article 6 basis and an Article 9 condition with applicable safeguards.
Outside the authored revision scope
- Completed professional practice or legal advice
- Complete exam objectives or verified exam alignment
Recorded evidence
- A basis must fit the processing purpose before processing; consent is not universal; the six taught Article 6 bases need the current recognised legitimate interest addition; special category data generally needs an Article 6 basis and an Article 9 condition with applicable safeguards.
- Session 3: Governance, Risk and Compliance — Classroom session record · Governance and Accountability; Risk and Measurement; Risk Management Lifecycle; Risk Treatment; Compliance Is Not the Same as Security; Risk Appetite vs Risk Tolerance; CVSS and Business Risk; ISO/IEC 27001 and 27002; Cyber Essentials; NIST Cybersecurity Framework; UK GDPR and Data Protection; Data Classification; UK GDPR Lawful Bases; ICO and the 72-Hour Rule; PCI DSS
- Session 4: Governance, Risk and Compliance — In Depth — Classroom session record · The Three GRC Pillars; Compliance ≠ Security; ISO/IEC 27001 and Continual Improvement; Why Consultants Need Business Context; Business Impact Analysis; Assessing Risk; Identifying and Managing Risk; Frameworks and Standards; UK GDPR and Data Protection; Data Classification and Handling
- Data Protection: UK GDPR and the DPA 2018 — Supplementary Study Guide explanation · The seven data-protection principles; Lawful bases and current law; Controllers, processors and service providers; Worked breach assessment
Not established by the recorded evidence
- Completed professional practice or legal advice
- Complete exam objectives or verified exam alignment
- Material outside the named introductory scope
Reviewed 2026-09-22. Reviewed against approved Sessions 3–4 learning and Core Concepts explanations. Fictional applications are educational elaborations, not completed practical work. Learning-only; this concept has not yet been individually verified against the Security+ SY0-701 objectives or any other exam syllabus.
Password Storage: Salting, Stretching and Peppering
Evidence: Mixed
Revision: Available · 10 questions · 6 flashcards
Exam relevance
CompTIA Security+
Verified for Security+: 5 of 10 questions and 2 of 6 flashcards. The mapping does not verify the others.
Reviewed revision scope
- Classroom (Session 9): rainbow tables and password cracking; salting, key stretching and peppering; and password hashing using modern schemes were covered.
- Supplementary: passwords are stored as the output of a password-hashing scheme and not as plaintext or reversibly encrypted values; a fast general-purpose hash such as SHA-256 on its own is unsuitable because an attacker with the stored hashes can test guesses at enormous speed.
- Supplementary: a rainbow table is a precomputed table for reversing unsalted hashes of likely passwords; a salt is a unique random value stored with each password’s hash, which makes identical passwords produce different hashes and defeats precomputed tables. A salt does not need to be secret.
- Supplementary: key stretching deliberately makes each password hash slow or memory-intensive to compute, through many iterations or a tunable cost, so that large-scale guessing becomes expensive; Argon2id, scrypt, bcrypt and PBKDF2 are password-hashing schemes that combine salting and stretching.
- Supplementary: a pepper is a secret value added to every password before hashing and stored apart from the password database, for example in a hardware security module; it differs from a salt, which is unique to each password and stored beside the hash.
Outside the authored revision scope
- Choosing parameters for a password-hashing scheme
- Carrying out password cracking
- Configuring or operating these technologies in practice
- The mathematics of the algorithms beyond the level stated
- The exact wording of the session material
Recorded evidence
- Classroom (Session 9): rainbow tables and password cracking; salting, key stretching and peppering; and password hashing using modern schemes were covered.
- Supplementary: passwords are stored as the output of a password-hashing scheme and not as plaintext or reversibly encrypted values; a fast general-purpose hash such as SHA-256 on its own is unsuitable because an attacker with the stored hashes can test guesses at enormous speed.
- Supplementary: a rainbow table is a precomputed table for reversing unsalted hashes of likely passwords; a salt is a unique random value stored with each password’s hash, which makes identical passwords produce different hashes and defeats precomputed tables. A salt does not need to be secret.
- Supplementary: key stretching deliberately makes each password hash slow or memory-intensive to compute, through many iterations or a tunable cost, so that large-scale guessing becomes expensive; Argon2id, scrypt, bcrypt and PBKDF2 are password-hashing schemes that combine salting and stretching.
- Supplementary: a pepper is a secret value added to every password before hashing and stored apart from the password database, for example in a hardware security module; it differs from a salt, which is unique to each password and stored beside the hash.
- Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions — Classroom session record · Cryptography, cryptanalysis and ciphers; Encoding and encryption; The Caesar cipher and Enigma; Symmetric encryption and AES; Asymmetric encryption, RSA and ECC; Key length, keyspace and brute force; Hashing and the SHA families; Hash resistance properties and collisions; Checksums and integrity verification; Rainbow tables and password cracking; Digital signatures; Public key infrastructure and certificate authorities; Digital certificates and X.509; Root, intermediate and leaf certificates; Self-signed certificates and certificate signing requests; Common Name and Subject Alternative Name; Certificate validity, expiry and revocation; Key lifecycle and key management; Entropy and randomness; TPMs, HSMs and secure enclaves; FIPS 140-2 and FIPS 140-3; Key escrow and M-of-N recovery; Confidentiality and the states of data; Hybrid encryption; Disk, partition and file encryption; Database and record-level encryption; Transport encryption, TLS and HTTPS; Key agreement, ephemeral keys and forward secrecy; Salting, stretching and peppering; Blockchain; Steganography, data masking and tokenisation; De-identification and anonymisation; Tutor demonstrations; Classroom review of cryptographic algorithms
- Password Storage: Salting, Stretching and Peppering — Supplementary Study Guide explanation · The problem: storing passwords; Why a fast hash is not enough; Rainbow tables and password cracking; Salting; Key stretching; Peppering; Modern password-hashing schemes; What good storage does not fix
Not established by the recorded evidence
- Choosing parameters for a password-hashing scheme
- Carrying out password cracking
- Configuring or operating these technologies in practice
- The mathematics of the algorithms beyond the level stated
- The exact wording of the session material
Authored and machine-validated on 12 October 2026; owner review pending. Checked during authoring against the Session 9 Learning Log and the Password Storage: Salting, Stretching and Peppering lesson Sources and scope section. Scope statements are labelled Classroom or Supplementary: Classroom statements record what the session covered, and beginner-first wording developed afterwards is labelled Supplementary. The concept is mapped to the Security+ objectives named in its mappings; that mapping verifies none of its questions or flashcards, and no practical competence or completed assessment is implied.
Public Key Infrastructure and Certificates
Evidence: Mixed
Revision: Available · 12 questions · 8 flashcards
Exam relevance
CompTIA Security+
- Security+ · 1.4 · direct
Mapped on 12 October 2026 for the “Certificates” sub-bullets “Certificate authorities”, “Self-signed”, “Third-party”, “Root of trust” and “Certificate signing request (CSR) generation”; widened on 13 October 2026 to the sub-bullet “Wildcard” (the names a certificate covers) only. Course coverage and authored revision do not establish full objective coverage.
Verified for Security+: 11 of 12 questions and 6 of 8 flashcards. The mapping does not verify the others.
Reviewed revision scope
- Classroom (Session 9): public key infrastructure and certificate authorities; public and private CAs; the DigiNotar compromise; digital certificates and X.509; public keys and subject identities; root certificates and trust anchors; root, intermediate and leaf certificates; certificate chains and their verification; self-signed certificates; certificate signing requests; and the Common Name and Subject Alternative Name fields were covered.
- Supplementary: a digital certificate binds a public key to a subject identity and is signed by a certificate authority (CA); public key infrastructure (PKI) is the set of CAs, policies, software and procedures that issue, distribute, validate and revoke certificates.
- Supplementary: a certificate chain runs from a leaf (end-entity) certificate through one or more intermediate CA certificates to a root certificate; a root is self-signed and is trusted because it has been placed in the relying party’s trust store as a trust anchor, not because of its own signature.
- Supplementary: a client validating a server certificate checks each signature in the chain up to a trust anchor, the validity dates, that the certificate is permitted for the purpose, that the requested name matches, and revocation status where it is checked; a certificate shows control of a name and a key, not that a website or its operator is safe.
- Supplementary: a self-signed certificate is signed with its own key, so nothing outside it vouches for the identity; a public CA is trusted by default in operating systems and browsers, while a private CA is trusted only by devices configured to trust it.
- Supplementary: a certificate signing request (CSR) contains the applicant’s public key and requested identity and is signed with the applicant’s private key, which never leaves the applicant; modern clients match a website’s name against the Subject Alternative Name (SAN) extension and not the Common Name (CN).
- Supplementary: because clients accept any certificate that chains to a trust anchor, a compromised CA can be used to issue fraudulent certificates for names its attacker does not control, as happened to the Dutch CA DigiNotar in 2011, after which browsers and operating systems removed it from their trust stores.
- Supplementary: a wildcard name such as *.harbourbank.example in a certificate covers any name one level down, but not the bare domain and not a name two levels down; one stolen private key then exposes every name the wildcard covers.
Outside the authored revision scope
- Certificate formats and encodings
- Operating a certificate authority
- Configuring or operating these technologies in practice
- The mathematics of the algorithms beyond the level stated
- The exact wording of the session material
Recorded evidence
- Classroom (Session 9): public key infrastructure and certificate authorities; public and private CAs; the DigiNotar compromise; digital certificates and X.509; public keys and subject identities; root certificates and trust anchors; root, intermediate and leaf certificates; certificate chains and their verification; self-signed certificates; certificate signing requests; and the Common Name and Subject Alternative Name fields were covered.
- Supplementary: a digital certificate binds a public key to a subject identity and is signed by a certificate authority (CA); public key infrastructure (PKI) is the set of CAs, policies, software and procedures that issue, distribute, validate and revoke certificates.
- Supplementary: a certificate chain runs from a leaf (end-entity) certificate through one or more intermediate CA certificates to a root certificate; a root is self-signed and is trusted because it has been placed in the relying party’s trust store as a trust anchor, not because of its own signature.
- Supplementary: a client validating a server certificate checks each signature in the chain up to a trust anchor, the validity dates, that the certificate is permitted for the purpose, that the requested name matches, and revocation status where it is checked; a certificate shows control of a name and a key, not that a website or its operator is safe.
- Supplementary: a self-signed certificate is signed with its own key, so nothing outside it vouches for the identity; a public CA is trusted by default in operating systems and browsers, while a private CA is trusted only by devices configured to trust it.
- Supplementary: a certificate signing request (CSR) contains the applicant’s public key and requested identity and is signed with the applicant’s private key, which never leaves the applicant; modern clients match a website’s name against the Subject Alternative Name (SAN) extension and not the Common Name (CN).
- Supplementary: because clients accept any certificate that chains to a trust anchor, a compromised CA can be used to issue fraudulent certificates for names its attacker does not control, as happened to the Dutch CA DigiNotar in 2011, after which browsers and operating systems removed it from their trust stores.
- Supplementary: a wildcard name such as *.harbourbank.example in a certificate covers any name one level down, but not the bare domain and not a name two levels down; one stolen private key then exposes every name the wildcard covers.
- Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions — Classroom session record · Cryptography, cryptanalysis and ciphers; Encoding and encryption; The Caesar cipher and Enigma; Symmetric encryption and AES; Asymmetric encryption, RSA and ECC; Key length, keyspace and brute force; Hashing and the SHA families; Hash resistance properties and collisions; Checksums and integrity verification; Rainbow tables and password cracking; Digital signatures; Public key infrastructure and certificate authorities; Digital certificates and X.509; Root, intermediate and leaf certificates; Self-signed certificates and certificate signing requests; Common Name and Subject Alternative Name; Certificate validity, expiry and revocation; Key lifecycle and key management; Entropy and randomness; TPMs, HSMs and secure enclaves; FIPS 140-2 and FIPS 140-3; Key escrow and M-of-N recovery; Confidentiality and the states of data; Hybrid encryption; Disk, partition and file encryption; Database and record-level encryption; Transport encryption, TLS and HTTPS; Key agreement, ephemeral keys and forward secrecy; Salting, stretching and peppering; Blockchain; Steganography, data masking and tokenisation; De-identification and anonymisation; Tutor demonstrations; Classroom review of cryptographic algorithms
- Public Key Infrastructure and Digital Certificates — Supplementary Study Guide explanation · The idea; What is inside a certificate; Certificate authorities; Public and private CAs; Root, intermediate and leaf certificates; Why the root is trusted; Why intermediates exist; How a certificate is validated; Self-signed certificates; Requesting a certificate: the CSR; Common Name and Subject Alternative Name; What a certificate does not tell you; When a certificate authority fails: DigiNotar
Not established by the recorded evidence
- Certificate formats and encodings
- Operating a certificate authority
- Configuring or operating these technologies in practice
- The mathematics of the algorithms beyond the level stated
- The exact wording of the session material
Authored and machine-validated on 12 October 2026; owner review pending. Checked during authoring against the Session 9 Learning Log and the Public Key Infrastructure and Digital Certificates lesson Sources and scope section. Scope statements are labelled Classroom or Supplementary: Classroom statements record what the session covered, and beginner-first wording developed afterwards is labelled Supplementary. The concept is mapped to the Security+ objectives named in its mappings; that mapping verifies none of its questions or flashcards, and no practical competence or completed assessment is implied.
Symmetric, Asymmetric and Hybrid Encryption
Evidence: Mixed
Revision: Available · 9 questions · 5 flashcards
Exam relevance
CompTIA Security+
- Security+ · 1.4 · direct
Mapped on 12 October 2026 for the “Public key infrastructure (PKI)” sub-bullets “Public key” and “Private key” and the “Encryption” sub-bullets “Asymmetric”, “Symmetric”, “Algorithms” and “Key length” only. Course coverage and authored revision do not establish full objective coverage.
Verified for Security+: 5 of 9 questions and 4 of 5 flashcards. The mapping does not verify the others.
Reviewed revision scope
- Classroom (Session 9): symmetric encryption and AES; asymmetric encryption, RSA and ECC; key pairs and key distribution; prime numbers as the foundation of RSA; and hybrid encryption using AES and RSA together were covered.
- Supplementary: symmetric encryption uses one shared secret key to encrypt and decrypt; it is fast and suits large amounts of data, and its difficulty is getting the key to the other party safely. AES is the standard symmetric block cipher, with 128-, 192- or 256-bit keys.
- Supplementary: asymmetric encryption uses a mathematically related key pair: a public key that can be shared freely and a private key that its owner keeps secret and that cannot feasibly be worked out from the public key. Data encrypted with a recipient’s public key can be decrypted only with the matching private key.
- Supplementary: RSA’s security rests on the difficulty of factoring the product of two large prime numbers; elliptic curve cryptography (ECC) is a family of algorithms based on elliptic-curve mathematics, used for purposes such as key agreement and digital signatures, that gives comparable strength with much shorter keys.
- Supplementary: hybrid encryption encrypts the data with a fast symmetric key and then protects that key with the recipient’s public key, so that the bulk data gets symmetric speed and the key gets asymmetric distribution.
- Supplementary: key lengths are not comparable between kinds of algorithm: a 2048-bit RSA key is rated at roughly the strength of a 112-bit symmetric key, and a 256-bit elliptic-curve key at roughly 128 bits.
Outside the authored revision scope
- Block cipher modes of operation and padding schemes
- Post-quantum algorithms
- Configuring or operating these technologies in practice
- The mathematics of the algorithms beyond the level stated
- The exact wording of the session material
Recorded evidence
- Classroom (Session 9): symmetric encryption and AES; asymmetric encryption, RSA and ECC; key pairs and key distribution; prime numbers as the foundation of RSA; and hybrid encryption using AES and RSA together were covered.
- Supplementary: symmetric encryption uses one shared secret key to encrypt and decrypt; it is fast and suits large amounts of data, and its difficulty is getting the key to the other party safely. AES is the standard symmetric block cipher, with 128-, 192- or 256-bit keys.
- Supplementary: asymmetric encryption uses a mathematically related key pair: a public key that can be shared freely and a private key that its owner keeps secret and that cannot feasibly be worked out from the public key. Data encrypted with a recipient’s public key can be decrypted only with the matching private key.
- Supplementary: RSA’s security rests on the difficulty of factoring the product of two large prime numbers; elliptic curve cryptography (ECC) is a family of algorithms based on elliptic-curve mathematics, used for purposes such as key agreement and digital signatures, that gives comparable strength with much shorter keys.
- Supplementary: hybrid encryption encrypts the data with a fast symmetric key and then protects that key with the recipient’s public key, so that the bulk data gets symmetric speed and the key gets asymmetric distribution.
- Supplementary: key lengths are not comparable between kinds of algorithm: a 2048-bit RSA key is rated at roughly the strength of a 112-bit symmetric key, and a 256-bit elliptic-curve key at roughly 128 bits.
- Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions — Classroom session record · Cryptography, cryptanalysis and ciphers; Encoding and encryption; The Caesar cipher and Enigma; Symmetric encryption and AES; Asymmetric encryption, RSA and ECC; Key length, keyspace and brute force; Hashing and the SHA families; Hash resistance properties and collisions; Checksums and integrity verification; Rainbow tables and password cracking; Digital signatures; Public key infrastructure and certificate authorities; Digital certificates and X.509; Root, intermediate and leaf certificates; Self-signed certificates and certificate signing requests; Common Name and Subject Alternative Name; Certificate validity, expiry and revocation; Key lifecycle and key management; Entropy and randomness; TPMs, HSMs and secure enclaves; FIPS 140-2 and FIPS 140-3; Key escrow and M-of-N recovery; Confidentiality and the states of data; Hybrid encryption; Disk, partition and file encryption; Database and record-level encryption; Transport encryption, TLS and HTTPS; Key agreement, ephemeral keys and forward secrecy; Salting, stretching and peppering; Blockchain; Steganography, data masking and tokenisation; De-identification and anonymisation; Tutor demonstrations; Classroom review of cryptographic algorithms
- Symmetric, Asymmetric and Hybrid Encryption — Supplementary Study Guide explanation · Symmetric encryption: one shared key; AES; The key-distribution problem; Asymmetric encryption: a key pair; RSA and prime numbers; Elliptic curve cryptography; Key lengths are not comparable; Comparing the two; Hybrid encryption: using both together
Not established by the recorded evidence
- Block cipher modes of operation and padding schemes
- Post-quantum algorithms
- Configuring or operating these technologies in practice
- The mathematics of the algorithms beyond the level stated
- The exact wording of the session material
Authored and machine-validated on 12 October 2026; owner review pending. Checked during authoring against the Session 9 Learning Log and the Symmetric, Asymmetric and Hybrid Encryption lesson Sources and scope section. Scope statements are labelled Classroom or Supplementary: Classroom statements record what the session covered, and beginner-first wording developed afterwards is labelled Supplementary. The concept is mapped to the Security+ objectives named in its mappings; that mapping verifies none of its questions or flashcards, and no practical competence or completed assessment is implied.
Transport Encryption, Key Agreement and Forward Secrecy
Evidence: Mixed
Revision: Available · 8 questions · 4 flashcards
Exam relevance
CompTIA Security+
Verified for Security+: 6 of 8 questions and 4 of 4 flashcards. The mapping does not verify the others.
Reviewed revision scope
- Classroom (Session 9): transport encryption and TLS; HTTPS and certificate authentication; key agreement and ECDHE; ephemeral keys; and perfect forward secrecy were covered.
- Supplementary: in a TLS connection, authentication identifies the server through its certificate and proof that it holds the matching private key, key agreement gives both sides shared secret material without sending it, and symmetric encryption, which is fast enough for bulk data, protects what is exchanged using keys derived from that material.
- Supplementary: in an ephemeral Diffie-Hellman key agreement such as ECDHE, each side generates a temporary key pair for one session, exchanges the public halves and derives the same shared secret; the secret itself is never transmitted.
- Supplementary: forward secrecy means that later compromise of a long-term private key does not expose the session keys of earlier recorded sessions; it depends on ephemeral key exchange and on the temporary keys and session keys being discarded after use. It does not protect future sessions against an attacker who can now impersonate the server, or data stored at either end.
Outside the authored revision scope
- TLS cipher suite selection and server configuration
- The mathematics of Diffie-Hellman
- Configuring or operating these technologies in practice
- The mathematics of the algorithms beyond the level stated
- The exact wording of the session material
Recorded evidence
- Classroom (Session 9): transport encryption and TLS; HTTPS and certificate authentication; key agreement and ECDHE; ephemeral keys; and perfect forward secrecy were covered.
- Supplementary: in a TLS connection, authentication identifies the server through its certificate and proof that it holds the matching private key, key agreement gives both sides shared secret material without sending it, and symmetric encryption, which is fast enough for bulk data, protects what is exchanged using keys derived from that material.
- Supplementary: in an ephemeral Diffie-Hellman key agreement such as ECDHE, each side generates a temporary key pair for one session, exchanges the public halves and derives the same shared secret; the secret itself is never transmitted.
- Supplementary: forward secrecy means that later compromise of a long-term private key does not expose the session keys of earlier recorded sessions; it depends on ephemeral key exchange and on the temporary keys and session keys being discarded after use. It does not protect future sessions against an attacker who can now impersonate the server, or data stored at either end.
- Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions — Classroom session record · Cryptography, cryptanalysis and ciphers; Encoding and encryption; The Caesar cipher and Enigma; Symmetric encryption and AES; Asymmetric encryption, RSA and ECC; Key length, keyspace and brute force; Hashing and the SHA families; Hash resistance properties and collisions; Checksums and integrity verification; Rainbow tables and password cracking; Digital signatures; Public key infrastructure and certificate authorities; Digital certificates and X.509; Root, intermediate and leaf certificates; Self-signed certificates and certificate signing requests; Common Name and Subject Alternative Name; Certificate validity, expiry and revocation; Key lifecycle and key management; Entropy and randomness; TPMs, HSMs and secure enclaves; FIPS 140-2 and FIPS 140-3; Key escrow and M-of-N recovery; Confidentiality and the states of data; Hybrid encryption; Disk, partition and file encryption; Database and record-level encryption; Transport encryption, TLS and HTTPS; Key agreement, ephemeral keys and forward secrecy; Salting, stretching and peppering; Blockchain; Steganography, data masking and tokenisation; De-identification and anonymisation; Tutor demonstrations; Classroom review of cryptographic algorithms
- Transport Encryption, Key Agreement and Forward Secrecy — Supplementary Study Guide explanation · Transport encryption; Three jobs in one connection; The handshake, step by step; Certificate authentication in HTTPS; Key agreement: making a secret in public; Ephemeral keys; Forward secrecy; What forward secrecy depends on; What forward secrecy does not do
Not established by the recorded evidence
- TLS cipher suite selection and server configuration
- The mathematics of Diffie-Hellman
- Configuring or operating these technologies in practice
- The mathematics of the algorithms beyond the level stated
- The exact wording of the session material
Authored and machine-validated on 12 October 2026; owner review pending. Checked during authoring against the Session 9 Learning Log and the Transport Encryption, Key Agreement and Forward Secrecy lesson Sources and scope section. Scope statements are labelled Classroom or Supplementary: Classroom statements record what the session covered, and beginner-first wording developed afterwards is labelled Supplementary. The concept is mapped to the Security+ objectives named in its mappings; that mapping verifies none of its questions or flashcards, and no practical competence or completed assessment is implied.