Cryptography & Cybersecurity — CIA Triad — Secure In Security
Secure In Security — Cryptography & Cybersecurity — CIA Triad Contact / Policy / About
Cryptography &
Cybersecurity
CIA Triad  /  Information Security
Introduction to Cryptography & the CIA Triad

Introduction to Cryptography in Cybersecurity

Cryptography is the science of securing information through mathematical techniques that make data unreadable to unauthorised parties, verifiable in origin, and detectable when altered. It is the foundational technology upon which virtually every modern information security control depends — from HTTPS web connections and encrypted email to digital signatures, VPNs, password hashing, and hardware security modules. Without cryptography, the concepts of Confidentiality, Integrity, and Availability as meaningful security guarantees would be impossible to achieve at scale across untrusted networks.

The relationship between cryptography and the CIA Triad is direct and architectural. Encryption algorithms protect Confidentiality by transforming plaintext into ciphertext that cannot be read without the correct key. Hash functions and digital signatures protect Integrity by enabling detection of any unauthorised modification to data or code. Availability is protected by cryptographic authentication protocols that prevent denial-of-service attacks based on credential theft and ensure that only legitimate users and systems can access critical services.

Key Concept
Cryptography provides the mathematical guarantees that make the CIA Triad enforceable across untrusted networks. A security control that does not use cryptography for Confidentiality, Integrity, or authentication can be bypassed by an adversary with network access. Understanding cryptographic principles is therefore prerequisite knowledge for every information security professional, regardless of their specialisation.

Cryptography and the CIA Triad

CIA PillarCryptographic Role
ConfidentialityEncryption transforms plaintext data into ciphertext that is computationally infeasible to read without the correct key. Symmetric encryption (AES), asymmetric encryption (RSA, ECC), and hybrid schemes protect data at rest, data in transit, and data in use. Confidentiality is the most commonly recognised cryptographic goal.
IntegrityHash functions (SHA-256, SHA-3) produce fixed-length digests that change completely if even a single bit of the input is modified. Message Authentication Codes (HMAC) combine hashing with a secret key to provide both integrity and authentication. Digital signatures extend this to public-key verification, enabling non-repudiation alongside integrity.
AvailabilityCryptographic authentication prevents credential-based Availability attacks by ensuring only legitimate users can authenticate to services. Key management systems protect the availability of cryptographic material. Authenticated encryption (AES-GCM) detects and rejects tampered ciphertext before it can cause service disruption or data corruption.
Non-RepudiationDigital signatures using asymmetric cryptography create mathematically verifiable proof that a specific private key holder produced a given message or transaction. Non-repudiation is essential for electronic commerce, legal documents, audit logs, and code signing — it prevents parties from falsely denying actions they performed.
AuthenticationCryptographic authentication protocols (TLS, Kerberos, OAuth) verify identity using challenge-response mechanisms, certificates, and tokens whose validity depends on cryptographic operations. Password hashing (bcrypt, Argon2) protects authentication credential databases from offline cracking attacks.

Fundamental Cryptographic Goals

Every cryptographic system is designed to achieve one or more of the following security properties. Understanding which properties a given algorithm provides — and which it deliberately does not address — is essential for selecting the correct cryptographic primitive for a given security requirement.

  • ConfidentialityOnly authorised parties can read the protected information. Achieved through encryption algorithms that transform plaintext into computationally irreversible ciphertext without the key.
  • IntegrityAny modification to protected data is detectable. Achieved through hash functions, MACs, and digital signatures that produce verification values dependent on the exact content.
  • AuthenticationThe claimed identity of a party or the origin of a message can be verified. Achieved through digital signatures, MACs, and cryptographic challenge-response protocols.
  • Non-RepudiationA party cannot falsely deny having performed an action. Achieved through digital signatures with asymmetric key pairs where only the signer possesses the private key.
  • Forward SecrecyCompromise of long-term keys does not compromise past session keys. Achieved through ephemeral Diffie-Hellman key exchange (ECDHE) that generates unique session keys never stored persistently.
  • Key ExchangeTwo parties can establish a shared secret over an insecure channel without prior shared secrets. Achieved through Diffie-Hellman and its elliptic-curve variant (ECDH).
Symmetric Cryptography — Algorithms & Applications

Symmetric Cryptography

Symmetric cryptography uses the same key for both encryption and decryption. It is computationally efficient, making it suitable for encrypting large volumes of data. The fundamental challenge of symmetric cryptography is key distribution — both parties must share the secret key through a secure channel before encrypted communication can begin. In practice, symmetric encryption is used for bulk data encryption, while asymmetric cryptography handles key exchange and authentication.

Advanced Encryption Standard (AES)

AES (Advanced Encryption Standard), standardised by NIST in 2001, is the dominant symmetric encryption algorithm in modern cryptographic deployments. It replaced DES after public key sizes became insufficient for security. AES is a block cipher operating on 128-bit blocks with key sizes of 128, 192, or 256 bits, and is implemented in hardware acceleration on all modern processors.

Mode / FeatureDescription
CIA PillarConfidentiality (primary) — AES is the world standard for bulk data encryption. AES-256 is the approved algorithm for protecting US government classified information at the SECRET level and above (NSA Suite B).
AES-CBCCipher Block Chaining mode chains each encrypted block to the previous ciphertext block. Requires a random IV (Initialisation Vector). Provides confidentiality but not integrity — must be combined with HMAC for authenticated encryption. Legacy mode; prefer AES-GCM for new deployments.
AES-GCMGalois/Counter Mode — the current recommended AES mode. Provides both confidentiality (CTR mode encryption) and integrity/authentication (GHASH authentication tag) in a single pass. The dominant authenticated encryption mode in TLS 1.3, HTTPS, and modern VPN protocols.
AES-CCMCounter with CBC-MAC — authenticated encryption mode used in IEEE 802.11i (WPA2), Bluetooth LE, and constrained IoT environments where GCM is computationally expensive. Provides confidentiality and authentication with smaller overhead than GCM.
AES-128 vs AES-256AES-128 provides 128 bits of security and is computationally faster. AES-256 provides 256 bits of security and is required for data with long-term sensitivity. Both are considered computationally secure against classical computers. AES-256 is recommended for post-quantum resistance.
Hardware AccelerationAES-NI (AES New Instructions) is a hardware extension in all modern Intel/AMD processors and Apple Silicon. Hardware AES achieves throughput of multiple gigabytes per second — effectively eliminating encryption as a performance bottleneck for most applications.
Key ManagementAES security depends entirely on key confidentiality. Keys must be generated with cryptographically secure random number generators (CSPRNG), stored in hardware security modules (HSMs) or operating system key stores, and rotated according to documented key lifecycle policies.

Stream Ciphers and Legacy Symmetric Algorithms

AlgorithmDescription
ChaCha20-Poly1305Modern stream cipher combined with Poly1305 MAC for authenticated encryption. Designed by Daniel Bernstein as a high-performance alternative to AES for environments without hardware AES acceleration (mobile, IoT). Used in TLS 1.3, WireGuard VPN, and SSH as the primary cipher suite alongside AES-GCM.
3DES (Triple DES)Legacy algorithm applying DES three times with two or three independent keys. Effective key length of 112 bits. Deprecated by NIST in 2023 — must not be used in new systems. Legacy systems using 3DES should be migrated to AES immediately. Still found in legacy financial (EMV) and mainframe environments.
RC4Legacy stream cipher, completely broken and prohibited by RFC 7465 (2015). Vulnerable to statistical biases, key reuse attacks, and multiple practical plaintext recovery attacks. Must not be used in any context. Often found in legacy WEP Wi-Fi, SSL 3.0, and TLS 1.0/1.1 implementations requiring immediate remediation.
Blowfish / TwofishBlowfish: 64-bit block cipher, vulnerable to birthday attacks in CBC mode for long sessions (Sweet32 attack). Twofish: AES finalist, 128-bit block cipher, strong but not widely adopted. Both are generally safe for new deployments but AES is preferred due to hardware acceleration and wider implementation support.
Key Concept
Authenticated Encryption with Associated Data (AEAD) — specifically AES-256-GCM and ChaCha20-Poly1305 — is the correct choice for new symmetric encryption deployments. AEAD provides confidentiality, integrity, and authentication in a single operation. Using encryption-only modes (AES-CBC, CTR) without a separate MAC creates a cryptographic vulnerability: ciphertext can be manipulated by an attacker without the key, leading to plaintext recovery or arbitrary message injection.
Asymmetric Cryptography — Public Key Systems

Asymmetric Cryptography and Public Key Systems

Asymmetric cryptography (public-key cryptography) uses mathematically related key pairs: a public key that can be freely distributed and a private key that must remain secret. Information encrypted with the public key can only be decrypted with the private key, and vice versa. This property eliminates the key distribution problem of symmetric cryptography and enables digital signatures, key exchange, and public key infrastructure.

RSA — Rivest-Shamir-Adleman

RSA, invented in 1977, was the first practical public-key cryptosystem and remains the most widely deployed asymmetric algorithm in enterprise environments. RSA security is based on the difficulty of factoring the product of two large prime numbers. Key sizes must be 2048 bits minimum (NIST requirement for security through 2030) with 4096 bits recommended for long-term sensitive data.

Feature / Use CaseDescription
CIA PillarConfidentiality (encryption) & Integrity/Authentication (digital signatures) — RSA serves both CIA Triad functions depending on usage.
RSA EncryptionEncrypts small amounts of data (session keys, symmetric key wrapping) using the recipient’s public key. RSA-OAEP (Optimal Asymmetric Encryption Padding) is the required padding scheme — PKCS#1 v1.5 padding is deprecated and vulnerable to Bleichenbacher padding oracle attacks.
RSA SignaturesCreates digital signatures by encrypting a hash of the message with the signer’s private key. Verifiable by anyone with the public key. RSA-PSS (Probabilistic Signature Scheme) is the required padding scheme for new implementations — PKCS#1 v1.5 signatures are deprecated.
Key Size GuidanceNIST SP 800-57: 2048-bit minimum through 2030, 3072-bit for data requiring protection beyond 2030. 4096-bit for highest assurance. Larger keys dramatically increase computational cost — RSA-4096 operations are 8× slower than RSA-2048.
RSA LimitationsRSA is orders of magnitude slower than symmetric cryptography. Unsuitable for bulk data encryption — used exclusively for key exchange and signatures. Vulnerable to quantum computers via Shor’s algorithm, motivating migration to post-quantum alternatives.

Elliptic Curve Cryptography (ECC)

Elliptic Curve Cryptography provides equivalent or superior security to RSA at dramatically smaller key sizes. A 256-bit ECC key provides approximately the same security as a 3072-bit RSA key. This makes ECC significantly more efficient in computation, bandwidth, and storage — critical advantages for TLS performance, mobile devices, and IoT deployments.

Algorithm / CurveDescription
CIA PillarConfidentiality (ECDH key exchange) & Integrity/Authentication (ECDSA, EdDSA digital signatures) — ECC serves both CIA Triad functions.
ECDSAElliptic Curve Digital Signature Algorithm. Standard for digital signatures in TLS, code signing, and cryptocurrency. Uses NIST P-256 or P-384 curves for enterprise. Requires a unique random nonce per signature — reuse of the nonce catastrophically leaks the private key (PS3 private key extraction vulnerability).
EdDSA / Ed25519Edwards-curve Digital Signature Algorithm using Curve25519. Designed by Daniel Bernstein. No random nonce requirement (deterministic), faster than ECDSA, immune to implementation timing attacks. Preferred for new deployments: used in SSH keys, OpenPGP, TLS 1.3, and Signal Protocol.
ECDH / ECDHEElliptic Curve Diffie-Hellman for key exchange. ECDHE (Ephemeral) generates a new key pair per session, providing forward secrecy. The default key exchange mechanism in TLS 1.3 — every TLS 1.3 session uses ECDHE.
Recommended CurvesNIST P-256 (secp256r1): most widely deployed, hardware accelerated. NIST P-384: required for US government TOP SECRET. Curve25519: highest assurance, no NIST backdoor concern, preferred for new non-government deployments. Avoid NIST P-224 (too small) and Brainpool curves (performance penalty).
ECC vs RSAECC 256-bit ≈ RSA 3072-bit security. ECC operations are 10–40× faster than equivalent RSA. Smaller keys reduce TLS handshake overhead. All major TLS 1.3 implementations default to ECDHE key exchange. NIST recommends migrating from RSA to ECC for new deployments wherever possible.

Diffie-Hellman Key Exchange

The Diffie-Hellman (DH) key exchange protocol, invented in 1976, enables two parties to establish a shared secret over an insecure channel without prior shared knowledge. This breakthrough solved the fundamental key distribution problem of symmetric cryptography. Modern deployments use Elliptic Curve Diffie-Hellman (ECDHE) rather than the original finite-field DH.

FeatureDescription
CIA PillarAvailability & Confidentiality — DH enables secure key establishment (Confidentiality) and through forward secrecy, ensures past sessions remain confidential even after long-term key compromise (Availability of historical privacy).
Forward SecrecyEphemeral DH generates a fresh key pair for each session. The session key is never stored. Compromise of the server’s long-term private key does not expose past session traffic — a critical protection against recorded-then-decrypted traffic attacks.
Logjam AttackClassic finite-field DH with 1024-bit parameters is vulnerable to the Logjam pre-computation attack (2015). RFC 7919 defines 2048-bit safe prime DH groups (ffdhe2048, ffdhe4096). All new implementations must use ECDHE or DH-2048+ — 768-bit and 1024-bit DH must be disabled in TLS configurations.
TLS 1.3 DHTLS 1.3 mandates ECDHE for all handshakes. Static RSA key exchange (no forward secrecy) is removed from TLS 1.3. Every TLS 1.3 connection has perfect forward secrecy by design — a major security improvement over TLS 1.2 which made forward secrecy optional.
Warning
RSA PKCS#1 v1.5 encryption padding and classic finite-field Diffie-Hellman with parameters below 2048 bits are both cryptographically broken in practical attack scenarios. Organisations conducting TLS configuration assessments must verify: (1) RSA-OAEP or ECDHE used for key exchange, (2) no RSA static key exchange (non-forward-secret), (3) DH parameters at minimum ffdhe2048 or ECDHE with P-256 or Curve25519. These misconfigurations are detected by tools such as testssl.sh, SSL Labs, and NMAP ssl-enum-ciphers script.
Hash Functions, MACs & Integrity Verification

Hash Functions, Message Authentication Codes, and Integrity Verification

Cryptographic hash functions are one-way mathematical functions that produce a fixed-length output (digest) from arbitrary-length input. They are the primary building block of cryptographic Integrity protection. A secure hash function makes it computationally infeasible to find two different inputs that produce the same output (collision resistance), or to find an input that produces a given output (preimage resistance). These properties make hashes ideal for verifying that data has not been modified.

Cryptographic Hash Algorithms

AlgorithmDescription & Status
CIA PillarIntegrity (primary) — hash functions detect any modification to data, code, or messages. Used in digital signatures, MACs, certificate fingerprints, file integrity verification, password hashing, blockchain, and software distribution.
SHA-256 / SHA-384 / SHA-512SHA-2 family (NIST FIPS 180-4). SHA-256 is the most widely deployed hash algorithm: TLS certificates, code signing, Git commits, and Bitcoin. SHA-384 is required for US government TOP SECRET. SHA-512 provides 256 bits of collision resistance and is preferred for password-based key derivation. All SHA-2 variants are currently considered secure.
SHA-3 (Keccak)NIST’s alternative hash standard (FIPS 202), selected through an open competition to provide a structurally different backup to SHA-2. Uses the sponge construction rather than Merkle-Damgård. Not vulnerable to length-extension attacks. SHA3-256 and SHAKE-256 (extendable output) recommended for new deployments requiring maximum assurance.
BLAKE2 / BLAKE3High-performance hash algorithms designed as faster, more secure alternatives to SHA-2 and MD5. BLAKE2 (RFC 7693) is the fastest secure hash algorithm in software. BLAKE3 is even faster, tree-structured, and parallelisable. Widely used in password managers, file integrity tools, and high-throughput security systems.
MD5Completely broken — do not use for security purposes. MD5 collision attacks are trivially fast; chosen-prefix collisions can be computed in minutes. Never use MD5 for integrity verification, digital signatures, or certificates. Still found in legacy configurations requiring urgent remediation. Acceptable only for non-security checksums (file deduplication).
SHA-1Deprecated and cryptographically broken for collision resistance. Practical SHA-1 chosen-prefix collisions (SHAttered, 2017; Shambles, 2020) allow signature forgery and certificate forgery. Prohibited in TLS certificates (CA/Browser Forum), code signing, and digital signatures since 2016–2017. Must not be used in new implementations.

Message Authentication Codes (MACs)

A Message Authentication Code (MAC) is a cryptographic construction that uses a shared secret key to provide both data integrity and authentication. Unlike a hash function alone, a MAC can only be verified by parties who possess the secret key — preventing an attacker who knows the hash algorithm from generating a valid authentication tag for a modified message.

MAC TypeDescription
CIA PillarIntegrity & Authentication — MACs simultaneously verify that data has not been modified (Integrity) and that the sender possessed the shared secret key (Authentication).
HMACHash-based Message Authentication Code (RFC 2104). Combines a hash function (e.g. HMAC-SHA256, HMAC-SHA384) with a secret key using a nested hash construction. The NIST-recommended MAC construction. Used in TLS record layer authentication, JWTs, API request signing (AWS Signature Version 4), and IPsec.
CMACCipher-based MAC using AES as the underlying primitive (NIST SP 800-38B). Preferred over HMAC in hardware-constrained environments where AES hardware acceleration is available but SHA acceleration is not. Used in payment card validation (EMV) and FIPS-compliant embedded security.
Poly1305High-performance MAC used with ChaCha20 (ChaCha20-Poly1305 AEAD). One-time MAC design — secure and extremely fast without hardware acceleration. Used in TLS 1.3, WireGuard, and SSH as the MAC component of the ChaCha20-Poly1305 cipher suite.
GMAC / GCMGalois Message Authentication Code — the authentication component of AES-GCM. Provides authentication tag generation and verification as part of the AES-GCM AEAD construction. GHASH authentication is computed simultaneously with CTR-mode encryption, making GCM particularly efficient on hardware with AES-NI support.
Length ExtensionHash functions using Merkle-Damgård construction (MD5, SHA-1, SHA-2) are vulnerable to length extension attacks when used directly as MACs without HMAC wrapping. An attacker knowing H(key‖message) can compute H(key‖message‖extension) without knowing the key. HMAC’s double-hash construction prevents this attack entirely.

Password Hashing Functions

Password storage requires specialised hash functions designed to be intentionally slow and memory-intensive. Standard cryptographic hash functions (SHA-256, etc.) are too fast — an attacker with a GPU can test billions of password guesses per second against a SHA-256 hash database. Password hashing functions incorporate configurable work factors (iterations, memory cost) to make offline dictionary attacks computationally prohibitive.

FunctionDescription
CIA PillarConfidentiality & Authentication — password hashing protects authentication credential confidentiality even when the password database is compromised, maintaining the Availability of authentication services.
bcryptAdaptive password hashing function (1999) using the Blowfish cipher. Work factor parameter controls computational cost. Widely deployed standard; cost factor 12+ recommended for new deployments. Maximum 72-character input — bcrypt silently truncates longer passwords, a known limitation. Native support in most web frameworks.
scryptMemory-hard password hashing function (RFC 7914). Requires significant RAM as well as CPU time, specifically designed to make ASIC/GPU acceleration ineffective. Used in cryptocurrency wallets and file encryption (OpenSSL 1.1+, macOS Keychain). Parameter selection: N=2¹⁷+, r=8, p=1 for interactive logins.
Argon2Winner of the 2015 Password Hashing Competition. Three variants: Argon2i (side-channel resistant), Argon2d (maximum GPU resistance), Argon2id (recommended default, combines both). The OWASP and NIST recommended password hashing function for new implementations. Configurable time, memory, and parallelism parameters.
PBKDF2Password-Based Key Derivation Function 2 (RFC 2898). NIST-approved and FIPS 140-2 compliant — required in many government and regulated industry contexts. Less memory-hard than bcrypt/scrypt/Argon2, making it more vulnerable to GPU-based attacks. Minimum 310,000 iterations with HMAC-SHA256 (OWASP 2023 recommendation).
SaltingA cryptographically random value (salt) is concatenated with the password before hashing and stored alongside the hash. Salts prevent rainbow table attacks and ensure that identical passwords produce different hashes. All modern password hashing functions (bcrypt, scrypt, Argon2) incorporate automatic salt generation.
Key Concept
The correct password hashing algorithm for new deployments is Argon2id with parameters recommended by OWASP: memory=19MB, iterations=2, parallelism=1 as the minimum. For environments requiring FIPS 140-2 compliance, PBKDF2-HMAC-SHA256 with 310,000+ iterations is required. MD5 and SHA-1 password hashes are trivially crackable — any system discovered to be storing passwords with these functions should be treated as a critical vulnerability requiring immediate remediation and mandatory password reset.
Public Key Infrastructure & Digital Certificates

Public Key Infrastructure and Digital Certificates

Public Key Infrastructure (PKI) is the framework of policies, procedures, hardware, software, and people that creates, manages, distributes, uses, stores, and revokes digital certificates and public keys. PKI bridges the gap between raw public-key cryptography and practical trust — it answers the question “whose public key is this?” through a chain of cryptographically verifiable trust anchors.

X.509 Digital Certificates

X.509 is the ITU-T standard format for public key certificates, used in TLS/HTTPS, S/MIME email signing, code signing, VPN authentication, and smart card-based authentication. A certificate binds a public key to an identity through a digital signature by a Certificate Authority (CA) that vouches for the binding.

Certificate ComponentDescription
CIA PillarAll three pillars — certificates enable secure key exchange (Confidentiality), authenticate communication partners (Integrity/Authentication), and underpin the availability of PKI-protected services.
Certificate FieldsSubject (entity identity: CN, O, OU, C), Issuer (signing CA), Validity Period (notBefore, notAfter), Subject Public Key Info (algorithm + public key), Subject Alternative Names (SANs: DNS names, IPs, emails), Key Usage (Digital Signature, Key Encipherment, Certificate Signing), Extended Key Usage (TLS Server, Code Signing), Serial Number, Signature Algorithm.
Certificate ChainsA chain of trust from end-entity certificate through intermediate CAs to a root CA. Intermediate CAs are the signing authorities for end-entity certificates. Root CAs are self-signed trust anchors distributed with operating systems and browsers. Chain validation requires every certificate in the chain to be valid, unexpired, and unrevoked.
Certificate Transparency (CT)Public append-only logs recording all issued TLS certificates (RFC 9162). Mandatory since 2018 for publicly trusted TLS certificates. Enables monitoring for misissued or fraudulent certificates. SCT (Signed Certificate Timestamp) embedded in certificates proves CT logging. Used to detect certificate authority misbehaviour and domain impersonation.
Certificate LifecycleCertificates have a defined validity period (maximum 398 days for publicly trusted TLS certificates since 2020). Lifecycle events: issuance, renewal, revocation (CRL, OCSP), expiry. Certificate expiry is one of the most common causes of unplanned service outages — automated certificate lifecycle management (ACME protocol) is the recommended practice.
Certificate PinningHardcoding expected certificate or public key values in applications to reject valid certificates from other CAs for a specific domain. Prevents attacks using fraudulently issued certificates from other trusted CAs. Used in mobile applications, HPKP (deprecated for browsers), and high-security API clients. Requires careful lifecycle management to prevent pinning-caused outages.

Certificate Authorities and Trust Models

Trust Model ElementDescription
Public CA HierarchyCommercial CAs (DigiCert, Sectigo, Let’s Encrypt, GlobalSign) issue certificates trusted by all browsers and operating systems. Root store programme membership (Mozilla, Apple, Microsoft, Google) is the gatekeeping mechanism. Let’s Encrypt provides free DV certificates through the ACME protocol with 90-day validity and automated renewal.
Private / Enterprise CAOrganisations deploy internal PKI for intranet TLS, client authentication, VPN certificates, code signing, and email encryption. Microsoft Active Directory Certificate Services (AD CS) is the dominant enterprise CA platform. Internal root CA certificates are distributed through MDM/Group Policy to managed devices.
Intermediate CAsRoot CAs keep their private keys offline (air-gapped) to minimise compromise risk. Day-to-day certificate issuance uses intermediate CA certificates whose private keys are online. If an intermediate CA is compromised, its certificate is revoked without compromising the root CA. Cross-certification enables trust between separate PKI hierarchies.
Revocation (CRL/OCSP)CRL (Certificate Revocation List): periodic signed list of revoked certificates published by CA. OCSP (Online Certificate Status Protocol): real-time revocation checking by querying CA’s OCSP responder. OCSP Stapling: server includes a pre-fetched OCSP response in TLS handshake — improves performance and privacy.
ACME ProtocolAutomatic Certificate Management Environment (RFC 8555). Automates domain validation and certificate issuance/renewal. Certbot, Caddy, Traefik, and cloud load balancers implement ACME for automatic certificate lifecycle management. Eliminates manual certificate renewal, the primary cause of expiry-related outages.
AD CS Attack SurfaceActive Directory Certificate Services is a significant attack surface. ESC1–ESC8 vulnerabilities (SpecterOps research) enable low-privileged users to obtain domain administrator certificates through misconfigured templates. Certificate template ACL auditing, Certify tool enumeration, and AD CS hardening (CIS Benchmark for AD CS) are essential for enterprise PKI security.
Warning
Certificate expiry is one of the most common and preventable causes of security-critical service outages. The industry-wide adoption of short-lived certificates (90 days for Let’s Encrypt, 398-day maximum for public TLS) makes automated certificate lifecycle management mandatory, not optional. Every organisation must deploy certificate monitoring with at least 30-day expiry alerting and automated renewal through ACME-compatible tooling. Manual certificate management at scale inevitably produces expiry incidents.
Cryptographic Protocols — TLS, SSH & VPN

Cryptographic Protocols in Information Security

Cryptographic protocols combine cryptographic primitives (algorithms) with structured handshake, authentication, and session management procedures to provide complete security services over untrusted networks. The protocols described in this section are deployed in virtually every enterprise environment and understanding their cryptographic properties is essential for security architecture and configuration assessment.

TLS — Transport Layer Security

TLS (Transport Layer Security) is the cryptographic protocol that secures the majority of internet traffic: HTTPS web connections, email (SMTPS, IMAPS), API communications, database connections, and application protocols. TLS provides authentication, confidentiality, and integrity for data in transit. TLS 1.3 (RFC 8446, 2018) is the current standard; TLS 1.2 is still widely deployed; TLS 1.0 and 1.1 are deprecated and prohibited.

TLS FeatureDescription
CIA PillarAll three pillars — TLS provides Confidentiality (encrypted session data), Integrity (AEAD authentication tags on every record), and Authentication (certificate-based server identity verification, optional client authentication).
TLS 1.3 ImprovementsMandatory forward secrecy (ECDHE only), no static RSA key exchange, reduced handshake from 2 round-trips to 1, removal of obsolete algorithms (RC4, 3DES, SHA-1, MD5, export ciphers, anonymous cipher suites), encrypted client hello (ECH) for metadata privacy.
TLS 1.3 Cipher SuitesOnly five cipher suites: TLS_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_CCM_SHA256, TLS_AES_128_CCM_8_SHA256. All use AEAD — authenticated encryption is mandatory in TLS 1.3 with no unauthenticated cipher suites permitted.
TLS ConfigurationNIST SP 800-52 Rev. 2 and Mozilla TLS Recommended Configuration define minimum cipher suites and protocol versions. Key requirements: TLS 1.2 minimum (TLS 1.3 preferred), forward secrecy (ECDHE/DHE), AES-GCM or ChaCha20-Poly1305, ECDSA/RSA-2048+ certificates with SHA-256 signature.
TLS VulnerabilitiesHistorical vulnerabilities: BEAST (CBC+TLS 1.0), CRIME/BREACH (compression), POODLE (SSLv3), FREAK (export ciphers), Logjam (weak DH), DROWN (SSLv2), ROBOT (RSA PKCS#1 v1.5). All mitigated by TLS 1.3. TLS 1.2 deployments require specific cipher suite configuration to prevent these attacks.
mTLS (Mutual TLS)Mutual TLS requires both client and server to present certificates, enabling bidirectional certificate-based authentication. Used in zero-trust architecture, microservice-to-microservice authentication, API security, and client VPN. mTLS eliminates password-based API authentication and provides strong identity assurance for machine-to-machine communications.

SSH — Secure Shell Protocol

SSH (Secure Shell, RFC 4251) is the standard cryptographic protocol for secure remote administration, file transfer (SFTP/SCP), and port forwarding. It replaced Telnet and FTP in enterprise environments in the late 1990s. SSH uses a hybrid cryptographic approach: asymmetric cryptography for host authentication and key exchange, symmetric cryptography for session encryption.

SSH FeatureDescription
CIA PillarAll three pillars — SSH provides Confidentiality (encrypted terminal sessions), Integrity (MAC on every packet), and Authentication (public key and keyboard-interactive authentication).
Key ExchangeSSH 2 uses ECDHE (curve25519-sha256 preferred) or DH group key exchange (diffie-hellman-group14-sha256 minimum). The key exchange establishes session keys for symmetric encryption. chacha20-poly1305@openssh.com and aes256-gcm@openssh.com are the recommended cipher suites.
Host AuthenticationSSH server presents a host key (ed25519, ecdsa, or rsa) that clients verify against the known_hosts file. First-connection trust-on-first-use (TOFU) model is the default. Enterprise deployments use SSHFP DNS records or SSH Certificate Authorities (ssh-keygen -t certificate) for scalable host key verification.
Client AuthenticationSSH certificate-based authentication (ed25519 keys preferred) is the security standard. Password authentication should be disabled (PasswordAuthentication no in sshd_config). SSH certificates with short validity periods and CA-signed user certificates enable centralised key management and automatic expiry.
SSH HardeningRecommended sshd_config: PermitRootLogin no, PasswordAuthentication no, PubkeyAuthentication yes, KexAlgorithms curve25519-sha256, Ciphers chacha20-poly1305@openssh.com and aes256-gcm@openssh.com, MACs hmac-sha2-256-etm@openssh.com. Disable ssh-dss and diffie-hellman-group1-sha1 (Logjam vulnerable).
SSH Key ManagementEnterprise SSH key sprawl (unmanaged user-to-server key mappings) is a significant insider threat and compliance risk. Tools: HashiCorp Vault SSH Secrets Engine, Teleport, StrongDM, and CyberArk Conjur provide centralised SSH certificate issuance, access logging, and automatic rotation.

VPN Cryptography — IPsec and WireGuard

ProtocolDescription
CIA PillarConfidentiality (encrypted tunnels) & Integrity (packet authentication) — VPN protocols protect both CIA pillars for network traffic across untrusted networks.
IPsecInternet Protocol Security suite (RFC 4301–4309). Two modes: Transport (encrypts payload only, preserves IP headers) and Tunnel (encrypts entire IP packet, adds new header). Two protocols: AH (Authentication Header, integrity only) and ESP (Encapsulating Security Payload, confidentiality + integrity). IKEv2 key exchange for VPN authentication.
IKEv2 / IPsecIKEv2 (RFC 7296) is the current standard for IPsec key exchange. Supports EAP authentication, MOBIKE (mobile IP changes), and stronger algorithms. Required cipher suites: AES-256-GCM or AES-256-CBC+HMAC-SHA256, ECDHE P-256 or DH-2048+ for key exchange, RSA-2048 or ECDSA certificates for authentication.
WireGuardModern VPN protocol (RFC 8565). Uses Noise Protocol Framework, Curve25519 ECDH, ChaCha20-Poly1305 AEAD, BLAKE2s hashing, and SipHash-2-4 for cookie protection. Deliberately minimal cryptographic agility (no algorithm negotiation) prevents downgrade attacks. Approximately 4,000 lines of code vs. 100,000+ for OpenVPN or IPsec — vastly smaller attack surface.
OpenVPNTLS-based VPN protocol using OpenSSL. Highly configurable but requires careful cipher suite selection to avoid weak configurations. Must be configured with TLS 1.2+, AES-256-GCM, ECDHE key exchange, and certificate-based authentication. tls-auth/tls-crypt-v2 provides HMAC-based packet authentication before TLS handshake — mitigates DoS attacks.
SSL VPNBrowser-based VPN using TLS. Clientless access through HTTPS web portals. Subject to all TLS vulnerabilities and requires TLS 1.2+ configuration. SSL VPN gateways (Pulse Secure, Citrix ADC, Fortinet SSL VPN) have been the target of significant zero-day exploitation campaigns targeting unpatched appliances.
Cryptographic Tools & Implementation

Cryptographic Tools and Implementation

Cryptographic security depends not only on mathematically sound algorithms but on their correct implementation. A theoretically perfect algorithm implemented incorrectly — with side-channel vulnerabilities, weak random number generation, or insecure key storage — provides no meaningful security. The tools described in this section are used by cryptographic engineers, security assessors, and system administrators for implementing, auditing, and testing cryptographic systems.

Cryptographic Libraries and Toolkits

LibraryDescription
CIA PillarAll three pillars — cryptographic libraries are the building blocks of all CIA Triad protections: encryption (Confidentiality), digital signatures and MACs (Integrity), and authentication protocols (Authentication).
OpenSSLThe most widely deployed open-source cryptographic library, used in Apache, Nginx, OpenSSH, OpenVPN, and thousands of applications. Implements TLS 1.3, X.509, PKCS standards, AES, RSA, ECC, hash functions, and PRNG. Subject of significant security research (Heartbleed CVE-2014-0160); actively maintained with regular security patches.
LibsodiumHigh-level cryptographic library by Daniel Bernstein designed for ease of correct use. Default algorithms: XSalsa20/Poly1305 (secretbox), Ed25519 (sign), X25519/XSalsa20 (box), Argon2id (pwhash). Deliberately minimal API makes misuse difficult. Preferred for new applications requiring custom cryptographic operations.
BoringSSL / AWS-LCGoogle’s fork of OpenSSL (used in Chrome, Android) and Amazon’s fork (used in AWS services). Both implement FIPS 140-3 validated cryptographic modules. More aggressively deprecate weak algorithms. AWS-LC optimised for AWS service performance. Used when FIPS 140-2/3 certification is required.
Bouncy CastleJava and C# cryptographic library with the widest algorithm support for JVM and .NET environments. FIPS 140-2 certified versions available. Implements post-quantum algorithms (CRYSTALS-Kyber, CRYSTALS-Dilithium). Standard for enterprise Java PKI, S/MIME, CMS/PKCS#7 applications.
Python cryptography / PyNaClPython cryptography library (pyca/cryptography): comprehensive OpenSSL-backed implementation for Python. PyNaCl: Python bindings for libsodium. The cryptography package is preferred for Python applications requiring raw cryptographic operations; PyNaCl for high-level libsodium API access.

TLS Configuration Assessment Tools

TLS configuration assessment tools evaluate the cryptographic security of TLS-protected services, identifying cipher suite weaknesses, protocol version vulnerabilities, certificate issues, and configuration flaws that undermine the Confidentiality and Integrity protections TLS is intended to provide.

ToolDescription
CIA PillarConfidentiality & Integrity — TLS assessment tools identify configurations that weaken or eliminate the Confidentiality and Integrity protections TLS provides for data in transit.
testssl.shOpen-source TLS assessment script that comprehensively tests TLS/SSL configurations: protocol versions, cipher suites, key exchange mechanisms, certificate validation, known vulnerabilities (BEAST, POODLE, CRIME, HEARTBLEED, ROBOT, FREAK, Logjam), HSTS, HPKP, CT, and OCSP stapling. The most thorough open-source TLS assessment tool.
SSL Labs Server TestQualys SSL Labs web-based TLS assessment providing A–F ratings. Tests all TLS vulnerabilities, cipher suite strength, forward secrecy, certificate chain validity, and compliance with Mozilla Recommended configuration. Industry-standard benchmark: A+ rating required for regulated industries (PCI DSS, HIPAA) and modern security postures.
Nmap ssl-*Nmap NSE scripts for TLS assessment: ssl-enum-ciphers (enumerates all accepted cipher suites and rates strength), ssl-cert (extracts certificate details), ssl-dh-params (detects weak DH parameters), ssl-heartbleed (tests for Heartbleed). Enables TLS assessment of non-web services (SMTP, IMAP, database connections).
sslscan2Fast TLS scanner that enumerates cipher suites, protocol versions, key exchange, and certificate details for both web and non-web services. Particularly useful for scanning entire networks of TLS-enabled services during infrastructure security assessments.
Cryptographic AgilityWell-designed systems support multiple cryptographic algorithms to enable smooth migration as algorithms are deprecated. Cryptographic agility enables disabling RC4, 3DES, or SHA-1 without rebuilding applications. TLS cipher suite negotiation is the primary mechanism; library-level algorithm selection is the implementation approach.

Key Management Tools and Hardware Security Modules

Key management is the most operationally critical aspect of cryptographic security. A mathematically perfect encryption algorithm protects nothing if the key is insecurely generated, stored, or rotated. Hardware Security Modules (HSMs) provide tamper-resistant hardware-backed key storage and cryptographic operations for the most sensitive key material.

Tool / StandardDescription
CIA PillarConfidentiality & Integrity — proper key management ensures that the Confidentiality protection provided by encryption cannot be undermined by key theft, and that signing keys providing Integrity guarantees cannot be forged.
Hardware Security Modules (HSMs)Dedicated hardware devices that generate, store, and use cryptographic keys in tamper-resistant hardware. Keys never leave the HSM in plaintext. FIPS 140-2/3 Level 3 HSMs provide physical tamper evidence and response. Required for CA private keys, payment HSMs (PIN validation), code signing keys, and high-assurance key management. Vendors: Thales/nCipher, Utimaco, AWS CloudHSM, Azure Dedicated HSM.
HashiCorp VaultOpen-source secrets management platform with built-in support for cryptographic operations: encryption as a service (Transit Secrets Engine), PKI certificate issuance, dynamic database credentials, SSH certificate signing, and AWS/Azure/GCP secrets management. Widely deployed for developer-facing secrets management and automated certificate lifecycle.
AWS KMS / Azure Key Vault / GCP KMSCloud-native key management services providing HSM-backed key storage, encryption operations, and key lifecycle management as managed services. Integration with cloud services (S3 SSE-KMS, RDS encryption, disk encryption) enables transparent envelope encryption. FIPS 140-2 Level 2 (AWS KMS) and Level 3 (HSM option) validated.
GPG / OpenPGPGNU Privacy Guard implements the OpenPGP standard (RFC 4880) for file encryption and email signing using asymmetric cryptography. Uses a web-of-trust model rather than hierarchical PKI. GPG with Curve25519 keys (gpg –expert with ed25519/cv25519) is the recommended key generation approach. Widely used for software release signing (Linux packages, Git tag signing, Debian repositories).
PKCS StandardsA family of public-key cryptography standards from RSA Security: PKCS#1 (RSA), PKCS#7/CMS (cryptographic message syntax), PKCS#8 (private key format), PKCS#10 (certificate signing request), PKCS#11 (hardware token interface — HSM API), PKCS#12 (certificate + private key bundle, .pfx/.p12 files). PKCS#12 files require strong password protection.
Key Concept
Key rotation is a mandatory component of cryptographic security that is frequently neglected in operational environments. NIST SP 800-57 defines maximum key usage periods for each algorithm and key type. Data encryption keys (DEKs) should be rotated annually or when a defined volume of data is encrypted. TLS certificates rotate automatically with ACME. Long-term secrets discovered without rotation history should be treated as potentially compromised and rotated immediately with an investigation into possible exposure.
Post-Quantum Cryptography & Emerging Standards

Post-Quantum Cryptography and Emerging Standards

Quantum computers, when sufficiently powerful, will break the asymmetric cryptographic algorithms (RSA, ECC, Diffie-Hellman) that underpin the majority of modern PKI, TLS, and digital signature infrastructure. Shor’s algorithm solves the integer factorisation and discrete logarithm problems that RSA and ECC respectively rely upon in polynomial time on a quantum computer. Symmetric algorithms (AES-256) and hash functions (SHA-256+) are significantly less affected — Grover’s algorithm halves their effective key length, but doubling key sizes (AES-256 provides adequate post-quantum security).

The “harvest now, decrypt later” threat — where adversaries record encrypted traffic today to decrypt it once quantum computers are available — means the migration to post-quantum cryptography is urgent even before large-scale quantum computers exist. NIST completed its Post-Quantum Cryptography standardisation process in 2024, publishing the first post-quantum algorithm standards.

NIST Post-Quantum Cryptography Standards (2024)

StandardDescription
CRYSTALS-Kyber (FIPS 203)ML-KEM (Module-Lattice Key Encapsulation Mechanism). Primary post-quantum key exchange mechanism. Based on the Module Learning With Errors (MLWE) lattice problem. Three security levels: Kyber-512 (128-bit), Kyber-768 (192-bit), Kyber-1024 (256-bit post-quantum security). Already integrated into TLS 1.3 hybrid key exchange (X25519Kyber768) and Chrome/Firefox experiments.
CRYSTALS-Dilithium (FIPS 204)ML-DSA (Module-Lattice Digital Signature Algorithm). Primary post-quantum digital signature algorithm. Based on MLWE. Three security levels: Dilithium2/3/5. Recommended for code signing, certificate signatures, and authentication in post-quantum deployments. Larger signatures than ECDSA (2420 bytes for Dilithium2 vs 64 bytes for Ed25519).
SPHINCS+ (FIPS 205)SLH-DSA (Stateless Hash-based Digital Signature Algorithm). Hash-based signature scheme — security relies only on hash function security, not algebraic structure. Largest signatures but most conservative security assumptions. Recommended as a backup to lattice-based schemes for the highest assurance requirements.
FALCON (FIPS 206)FN-DSA (FFT over NTRU-Lattice Digital Signature Algorithm). Smaller signatures than Dilithium with similar security. Based on NTRU lattices. More complex constant-time implementation requirements — implementation complexity is a consideration for choosing between Dilithium and Falcon.
Hybrid Key ExchangeThe transitional approach: combining classical (X25519/P-256) and post-quantum (Kyber) key exchange such that security holds if either algorithm is unbroken. Hybrid X25519Kyber768 is already deployed in TLS experiments. IETF drafts standardising hybrid TLS key exchange (RFC draft-ietf-tls-hybrid-design). Recommended approach for the transition period.
Migration TimelineNIST’s FIPS 140-3 timeline requires post-quantum approved algorithms by 2030. US federal agencies must migrate to post-quantum key exchange and digital signatures by 2035. NSA has announced that Suite B (RSA, ECDSA, ECDH) will not be approved for national security systems after the transition. Organisations should begin cryptographic inventory and migration planning immediately.
Warning
“Harvest now, decrypt later” attacks are an active threat. Intelligence agencies and sophisticated adversaries may already be recording encrypted traffic to decrypt when quantum computers become available. Data with long-term sensitivity — classified information, intellectual property, long-term contracts, medical records — encrypted today with RSA or ECDH may be exposed in 10–15 years. Organisations with long-term data sensitivity requirements should implement post-quantum hybrid key exchange in TLS deployments now, before quantum computers are available. Migration from classical asymmetric cryptography to post-quantum algorithms should begin with inventory and risk assessment immediately.
CIA Triad Cryptography Control Matrix

CIA Triad Cryptography Control Matrix

Effective cryptographic security program design requires systematic mapping of algorithms, protocols, and controls to CIA Triad pillars. The following matrix maps every major cryptographic primitive and protocol covered in this document to its primary CIA Triad contribution, enabling security architects to ensure balanced cryptographic protection across all three pillars.

Cryptographic ControlPrimary CIA Pillar(s)Security Function & Algorithm
AES-256-GCMConfidentiality & IntegrityAuthenticated encryption for data at rest and in transit — simultaneous encryption and integrity protection in a single operation
ChaCha20-Poly1305Confidentiality & IntegrityAEAD encryption for mobile/IoT without AES hardware — TLS 1.3 and WireGuard cipher suite
RSA-OAEP (2048+)ConfidentialityAsymmetric key wrapping and session key establishment — must use OAEP padding, not PKCS#1 v1.5
RSA-PSS SignaturesIntegrity & AuthenticationNon-repudiation for documents, code, and certificates — probabilistic signature scheme prevents forgery
ECDSA / Ed25519Integrity & AuthenticationDigital signatures for certificates, SSH, code signing — Ed25519 preferred for new deployments
ECDHE / X25519Confidentiality & AvailabilityForward-secret key exchange in TLS/SSH — every session uses unique ephemeral keys protecting past sessions
SHA-256 / SHA-384 / SHA-512IntegrityCollision-resistant hash functions for digital signatures, MACs, certificate fingerprints, and file integrity verification
HMAC-SHA256 / HMAC-SHA384Integrity & AuthenticationSymmetric authenticated hashing for API signing, TLS record authentication, and JWT signatures
Argon2idConfidentiality & AuthenticationPassword hashing protecting authentication credential databases from offline cracking attacks
PBKDF2-HMAC-SHA256 (310k+)Confidentiality & AuthenticationFIPS-compliant password hashing for regulated environments requiring FIPS 140-2 algorithm approval
X.509 PKI / TLS CertificatesAll three pillarsIdentity binding for authenticated key exchange — foundation of HTTPS, VPN, email, and code signing trust
TLS 1.3All three pillarsConfidential, integrity-protected, authenticated transport — mandatory forward secrecy and AEAD cipher suites
mTLS (Mutual TLS)Authentication & ConfidentialityBidirectional certificate authentication for zero-trust and API security — eliminates password-based API access
SSH (Ed25519 certificates)All three pillarsEncrypted, authenticated remote administration — certificate-based auth preferred over password auth
IPsec / IKEv2Confidentiality & IntegrityNetwork-layer VPN providing encrypted tunnels with packet integrity and replay protection
WireGuardConfidentiality & IntegrityModern VPN with minimal attack surface — Curve25519, ChaCha20-Poly1305, BLAKE2s cryptographic stack
HSM / Key ManagementConfidentialityHardware-backed key storage preventing key extraction — required for CA keys, signing keys, and master encryption keys
ML-KEM / CRYSTALS-KyberConfidentialityPost-quantum key encapsulation — quantum-resistant replacement for RSA and ECDH key exchange
ML-DSA / CRYSTALS-DilithiumIntegrity & AuthenticationPost-quantum digital signatures — quantum-resistant replacement for RSA-PSS and ECDSA

Cryptographic Algorithm Selection Decision Framework

When selecting cryptographic algorithms for a new deployment, the following framework provides a structured approach to algorithm selection that accounts for security requirements, compliance obligations, performance constraints, and post-quantum migration timelines.

Use CaseRecommended AlgorithmCompliance Requirement
Bulk data encryption (at rest / in transit)AES-256-GCMNIST FIPS 197; PCI DSS Req 3.5; HIPAA Technical Safeguards
Password/credential storageArgon2id (FIPS: PBKDF2-HMAC-SHA256)OWASP ASVS 2.4; NIST SP 800-63B
Digital signatures (code, documents)Ed25519 or ECDSA P-256NIST FIPS 186-5; CA/Browser Forum Baseline Requirements
TLS for web/API servicesTLS 1.3 with ECDHE + AES-256-GCMNIST SP 800-52 Rev. 2; PCI DSS 4.2.1; Mozilla Recommended
Key exchangeX25519 (ECDHE) or P-256 ECDHENIST SP 800-56A Rev. 3; NSA Suite B
Certificate hashing / fingerprintingSHA-256 or SHA-384CA/Browser Forum: SHA-1 prohibited; NIST SP 800-131A
API authentication (HMAC)HMAC-SHA256RFC 2104; AWS Signature Version 4
Remote administrationSSH with Ed25519 certificatesNIST SP 800-52; CIS Linux Benchmark
Long-term classified / sensitive dataAES-256-GCM + Hybrid Kyber1024NSA CNSA 2.0; NIST FIPS 203 (transition)
VPN (site-to-site or remote access)WireGuard or IKEv2/AES-256-GCMNIST SP 800-77 Rev. 1; CISA VPN Guidance
Email encryptionS/MIME with ECC or OpenPGP Ed25519NIST SP 800-177; DoD PKI Policy
Post-quantum transition (key exchange)X25519Kyber768 hybridNIST FIPS 203; NSA CNSA 2.0 Timeline 2030–2035
Warning
Cryptographic algorithm deprecation is an ongoing process — algorithms that are secure today may require migration within 5–10 years. Organisations must maintain a cryptographic inventory documenting every algorithm, key size, and protocol in use across their environment. This inventory enables rapid response when vulnerabilities are discovered or deprecation timelines are announced by NIST, NSA, or CA/Browser Forum. The NIST NCCoE Migration to Post-Quantum Cryptography project provides detailed guidance on conducting cryptographic inventories and migration planning.