4.3 Cryptography Foundations: Symmetric, Asymmetric, Hashing, and PKI

Practical Cryptography for Security Leaders

Cryptography supports confidentiality, integrity, authentication, and nonrepudiation, but it does not solve every security problem. It cannot fix weak authorization, poor endpoint hygiene, excessive data collection, exposed secrets, or a broken business process. The CISSP mindset is to select cryptographic services that fit risk, implementation maturity, and operational reality.

Symmetric encryption uses the same secret key to encrypt and decrypt. It is fast and well suited for bulk data such as files, databases, backups, and network sessions after a session key has been established. The main challenge is not speed; it is distributing, storing, rotating, and protecting shared keys at scale.

Asymmetric cryptography uses a public key and private key pair. What one key does, the related key is needed to reverse or verify, depending on the scheme. It is slower than symmetric encryption, so it is commonly used for key exchange, digital signatures, certificate validation, and identity establishment rather than encrypting large datasets directly.

Hybrid designs are common. TLS, for example, uses asymmetric mechanisms and certificates to authenticate parties and agree on session secrets, then uses symmetric encryption for efficient protected communication. This pattern reflects a practical balance: use asymmetric cryptography for trust establishment and symmetric cryptography for high-volume protection.

Hash functions produce a fixed-length digest from input data. A good cryptographic hash is one way, collision resistant for practical purposes, and sensitive to changes in the input. Hashes help verify integrity for files, software artifacts, logs, and evidence, but a plain hash does not prove who created the data because anyone can compute it.

Message authentication codes add shared-secret authenticity to integrity. An HMAC can show that a party with the shared secret created or validated a message. Digital signatures provide a different property: a private key signs, and others can verify using the public key. That supports stronger accountability when the private key is controlled by a specific person, service, or organization.

Public key infrastructure provides a trust framework for certificates. A certificate binds a public key to an identity or purpose, and a certificate authority signs that binding. Relying parties decide whether to trust the certificate by validating the chain to a trusted root, checking names and usage constraints, and considering revocation status.

PKI is operationally demanding. Certificate requests, issuance, approval, installation, renewal, revocation, monitoring, and retirement must be owned. Expired certificates can create outages, weak validation can enable impersonation, and uncontrolled certificate issuance can create shadow trust relationships that bypass security governance.

Root certificate authorities require the highest protection because they anchor trust. Many organizations keep roots offline and use intermediate authorities for daily issuance. This reduces exposure and allows a compromised intermediate to be revoked without replacing every trust anchor. The design should define who can issue certificates, for what names, under which policy, and with what audit evidence.

Certificate revocation is a practical risk area. Certificate revocation lists and online certificate status protocols both have availability and freshness tradeoffs. Some environments use short-lived certificates to reduce reliance on revocation checking. The right answer depends on impact, connectivity, automation maturity, and tolerance for service disruption.

Cryptographic choices should follow recognized standards and approved libraries. Custom algorithms, homegrown random number generators, and unusual protocol combinations are warning signs. A security leader does not need to derive the math, but must know enough to challenge nonstandard choices and require review by qualified cryptographic engineers.

Key size and algorithm strength matter, but so do mode, padding, initialization, randomness, and implementation. Strong encryption can fail if the same nonce is reused where uniqueness is required, if private keys are stored in source code, or if applications accept invalid certificates. Operational misuse is often more likely than a theoretical break.

Data state matters. Data at rest may require database, file, disk, object storage, or backup encryption. Data in transit usually requires secure protocols and certificate validation. Data in use may require memory protections, trusted execution environments, tokenization, or process controls, but encryption alone cannot fully protect data while it is actively processed.

Use this selection checklist before approving cryptography in a design:

• Define the security objective: confidentiality, integrity, authentication, nonrepudiation, or a combination.
• Use standard algorithms, protocols, libraries, and platform services.
• Identify key owners, custodians, storage locations, and recovery procedures.
• Confirm certificate validation, hostname checks, and revocation or short-lived certificate strategy.
• Document where plaintext exists and who can access it.
• Test failure cases such as expired certificates, revoked keys, and unavailable key services.

For study purposes, stay practical. Know the difference between encryption, hashing, HMACs, digital signatures, and certificates. More importantly, know when each is appropriate and what governance is needed to keep the cryptographic control from becoming a fragile dependency.