Understand PKI, encryption, hashing, digital signatures, obfuscation, and certificate workflows for the cryptography objectives on Security+.
Cryptography questions on Security+ are rarely about reciting algorithm names in isolation. CompTIA wants you to choose the right cryptographic tool for confidentiality, integrity, authentication, or non-repudiation and then understand the operational pieces around it, such as certificates, trust chains, and revocation.
PKI: Public key infrastructure, the certificate and trust-chain system used to bind identities to public keys.
HMAC: Hash-based message authentication code, which uses a shared secret to protect integrity and sender authenticity.
OCSP: Online Certificate Status Protocol, a way to check whether a certificate is still valid instead of relying only on local certificate lists.
| Need | Strongest first fit |
|---|---|
| Protect confidentiality of data at rest or in transit | Encryption |
| Detect unauthorized changes | Hashing or HMAC |
| Prove a sender or signer | Digital signature and PKI |
| Hide implementation details without true secrecy | Obfuscation |
| Validate certificate trust | PKI, CA chain, CRL, or OCSP |
Security+ is usually testing one of these judgments:
That is why a question about TLS may really be a certificate-lifecycle question, not an encryption-strength question.
flowchart LR
A["Root CA"] --> B["Intermediate CA"]
B --> C["Leaf certificate"]
C --> D["Server or user identity"]
D --> E["Client validates trust chain and status"]
What to notice:
| Requirement | Strongest first fit | Why |
|---|---|---|
| Bulk data confidentiality | Symmetric encryption such as AES | Fast enough for real data movement |
| Key exchange or sender identity | Asymmetric cryptography | Supports trust and identity use cases |
| Message integrity plus shared-secret validation | HMAC | Detects tampering and proves the holder knows the shared secret |
| Public proof a file came from a trusted signer | Digital signature with PKI | Supports integrity and non-repudiation |
| Protect stored secret values from casual disclosure in logs or UI | Masking or tokenization when the workflow fits | Reduces exposure without always revealing the real value |
Security+ does not require deep command-line mastery, but it helps to recognize what certificate inspection looks like:
1openssl s_client -connect example.com:443 -servername example.com
What to notice:
You can also inspect a local certificate file directly:
1openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName
What to notice:
subject and subjectAltName help confirm hostname fitissuer helps verify where the cert sits in the trust chaindates reveal expiration problems immediatelyWhen Security+ gives you a certificate failure, work through this order:
| Concept | What it is not |
|---|---|
| Hashing | not encryption |
| Encoding | not encryption |
| Digital signature | not the same as encryption, even though public-key crypto is involved |
| Obfuscation | not a substitute for real cryptographic protection |
CompTIA includes blockchain in this domain as part of cryptographic solutions vocabulary. You do not need to become a cryptocurrency expert. You do need to understand the broader idea: tamper-evident chained records, cryptographic validation, and a design goal of integrity and trust across a distributed system.
A company signs internal software releases and distributes them through a private repository. An administrator wants users to verify that packages were produced by the approved build pipeline and were not modified in transit. Which design is strongest?
A. Encrypt every package with the same shared password and publish that password to the deployment team
B. Hash every package privately but do not publish the expected digest anywhere
C. Sign each release with the build pipeline’s private key and let clients verify the signature with the trusted public certificate
D. Base64-encode each package before upload so tampering is easier to spot
Best answer: C. The core requirement is integrity plus signer identity. A digital signature backed by a trusted certificate is stronger than shared-secret encryption, unpublished hashes, or encoding.
Continue with 2. Threats, Vulnerabilities & Mitigations to move from security vocabulary into attack paths and defensive reasoning.