Cybersecurity
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.
Cryptography and the CIA Triad
| CIA Pillar | Cryptographic Role |
|---|---|
| Confidentiality | Encryption 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. |
| Integrity | Hash 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. |
| Availability | Cryptographic 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-Repudiation | Digital 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. |
| Authentication | Cryptographic 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
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 / Feature | Description |
|---|---|
| CIA Pillar | Confidentiality (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-CBC | Cipher 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-GCM | Galois/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-CCM | Counter 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-256 | AES-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 Acceleration | AES-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 Management | AES 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
| Algorithm | Description |
|---|---|
| ChaCha20-Poly1305 | Modern 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. |
| RC4 | Legacy 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 / Twofish | Blowfish: 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. |
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 Case | Description |
|---|---|
| CIA Pillar | Confidentiality (encryption) & Integrity/Authentication (digital signatures) — RSA serves both CIA Triad functions depending on usage. |
| RSA Encryption | Encrypts 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 Signatures | Creates 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 Guidance | NIST 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 Limitations | RSA 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 / Curve | Description |
|---|---|
| CIA Pillar | Confidentiality (ECDH key exchange) & Integrity/Authentication (ECDSA, EdDSA digital signatures) — ECC serves both CIA Triad functions. |
| ECDSA | Elliptic 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 / Ed25519 | Edwards-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 / ECDHE | Elliptic 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 Curves | NIST 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 RSA | ECC 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.
| Feature | Description |
|---|---|
| CIA Pillar | Availability & 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 Secrecy | Ephemeral 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 Attack | Classic 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 DH | TLS 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. |
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
| Algorithm | Description & Status |
|---|---|
| CIA Pillar | Integrity (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-512 | SHA-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 / BLAKE3 | High-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. |
| MD5 | Completely 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-1 | Deprecated 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 Type | Description |
|---|---|
| CIA Pillar | Integrity & Authentication — MACs simultaneously verify that data has not been modified (Integrity) and that the sender possessed the shared secret key (Authentication). |
| HMAC | Hash-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. |
| CMAC | Cipher-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. |
| Poly1305 | High-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 / GCM | Galois 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 Extension | Hash 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.
| Function | Description |
|---|---|
| CIA Pillar | Confidentiality & Authentication — password hashing protects authentication credential confidentiality even when the password database is compromised, maintaining the Availability of authentication services. |
| bcrypt | Adaptive 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. |
| scrypt | Memory-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. |
| Argon2 | Winner 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. |
| PBKDF2 | Password-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). |
| Salting | A 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. |
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 Component | Description |
|---|---|
| CIA Pillar | All three pillars — certificates enable secure key exchange (Confidentiality), authenticate communication partners (Integrity/Authentication), and underpin the availability of PKI-protected services. |
| Certificate Fields | Subject (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 Chains | A 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 Lifecycle | Certificates 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 Pinning | Hardcoding 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 Element | Description |
|---|---|
| Public CA Hierarchy | Commercial 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 CA | Organisations 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 CAs | Root 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 Protocol | Automatic 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 Surface | Active 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. |
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 Feature | Description |
|---|---|
| CIA Pillar | All 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 Improvements | Mandatory 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 Suites | Only 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 Configuration | NIST 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 Vulnerabilities | Historical 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 Feature | Description |
|---|---|
| CIA Pillar | All three pillars — SSH provides Confidentiality (encrypted terminal sessions), Integrity (MAC on every packet), and Authentication (public key and keyboard-interactive authentication). |
| Key Exchange | SSH 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 Authentication | SSH 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 Authentication | SSH 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 Hardening | Recommended 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 Management | Enterprise 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
| Protocol | Description |
|---|---|
| CIA Pillar | Confidentiality (encrypted tunnels) & Integrity (packet authentication) — VPN protocols protect both CIA pillars for network traffic across untrusted networks. |
| IPsec | Internet 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 / IPsec | IKEv2 (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. |
| WireGuard | Modern 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. |
| OpenVPN | TLS-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 VPN | Browser-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 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
| Library | Description |
|---|---|
| CIA Pillar | All three pillars — cryptographic libraries are the building blocks of all CIA Triad protections: encryption (Confidentiality), digital signatures and MACs (Integrity), and authentication protocols (Authentication). |
| OpenSSL | The 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. |
| Libsodium | High-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-LC | Google’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 Castle | Java 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 / PyNaCl | Python 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.
| Tool | Description |
|---|---|
| CIA Pillar | Confidentiality & Integrity — TLS assessment tools identify configurations that weaken or eliminate the Confidentiality and Integrity protections TLS provides for data in transit. |
| testssl.sh | Open-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 Test | Qualys 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). |
| sslscan2 | Fast 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 Agility | Well-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 / Standard | Description |
|---|---|
| CIA Pillar | Confidentiality & 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 Vault | Open-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 KMS | Cloud-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 / OpenPGP | GNU 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 Standards | A 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. |
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)
| Standard | Description |
|---|---|
| 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 Exchange | The 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 Timeline | NIST’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. |
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 Control | Primary CIA Pillar(s) | Security Function & Algorithm |
|---|---|---|
| AES-256-GCM | Confidentiality & Integrity | Authenticated encryption for data at rest and in transit — simultaneous encryption and integrity protection in a single operation |
| ChaCha20-Poly1305 | Confidentiality & Integrity | AEAD encryption for mobile/IoT without AES hardware — TLS 1.3 and WireGuard cipher suite |
| RSA-OAEP (2048+) | Confidentiality | Asymmetric key wrapping and session key establishment — must use OAEP padding, not PKCS#1 v1.5 |
| RSA-PSS Signatures | Integrity & Authentication | Non-repudiation for documents, code, and certificates — probabilistic signature scheme prevents forgery |
| ECDSA / Ed25519 | Integrity & Authentication | Digital signatures for certificates, SSH, code signing — Ed25519 preferred for new deployments |
| ECDHE / X25519 | Confidentiality & Availability | Forward-secret key exchange in TLS/SSH — every session uses unique ephemeral keys protecting past sessions |
| SHA-256 / SHA-384 / SHA-512 | Integrity | Collision-resistant hash functions for digital signatures, MACs, certificate fingerprints, and file integrity verification |
| HMAC-SHA256 / HMAC-SHA384 | Integrity & Authentication | Symmetric authenticated hashing for API signing, TLS record authentication, and JWT signatures |
| Argon2id | Confidentiality & Authentication | Password hashing protecting authentication credential databases from offline cracking attacks |
| PBKDF2-HMAC-SHA256 (310k+) | Confidentiality & Authentication | FIPS-compliant password hashing for regulated environments requiring FIPS 140-2 algorithm approval |
| X.509 PKI / TLS Certificates | All three pillars | Identity binding for authenticated key exchange — foundation of HTTPS, VPN, email, and code signing trust |
| TLS 1.3 | All three pillars | Confidential, integrity-protected, authenticated transport — mandatory forward secrecy and AEAD cipher suites |
| mTLS (Mutual TLS) | Authentication & Confidentiality | Bidirectional certificate authentication for zero-trust and API security — eliminates password-based API access |
| SSH (Ed25519 certificates) | All three pillars | Encrypted, authenticated remote administration — certificate-based auth preferred over password auth |
| IPsec / IKEv2 | Confidentiality & Integrity | Network-layer VPN providing encrypted tunnels with packet integrity and replay protection |
| WireGuard | Confidentiality & Integrity | Modern VPN with minimal attack surface — Curve25519, ChaCha20-Poly1305, BLAKE2s cryptographic stack |
| HSM / Key Management | Confidentiality | Hardware-backed key storage preventing key extraction — required for CA keys, signing keys, and master encryption keys |
| ML-KEM / CRYSTALS-Kyber | Confidentiality | Post-quantum key encapsulation — quantum-resistant replacement for RSA and ECDH key exchange |
| ML-DSA / CRYSTALS-Dilithium | Integrity & Authentication | Post-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 Case | Recommended Algorithm | Compliance Requirement |
|---|---|---|
| Bulk data encryption (at rest / in transit) | AES-256-GCM | NIST FIPS 197; PCI DSS Req 3.5; HIPAA Technical Safeguards |
| Password/credential storage | Argon2id (FIPS: PBKDF2-HMAC-SHA256) | OWASP ASVS 2.4; NIST SP 800-63B |
| Digital signatures (code, documents) | Ed25519 or ECDSA P-256 | NIST FIPS 186-5; CA/Browser Forum Baseline Requirements |
| TLS for web/API services | TLS 1.3 with ECDHE + AES-256-GCM | NIST SP 800-52 Rev. 2; PCI DSS 4.2.1; Mozilla Recommended |
| Key exchange | X25519 (ECDHE) or P-256 ECDHE | NIST SP 800-56A Rev. 3; NSA Suite B |
| Certificate hashing / fingerprinting | SHA-256 or SHA-384 | CA/Browser Forum: SHA-1 prohibited; NIST SP 800-131A |
| API authentication (HMAC) | HMAC-SHA256 | RFC 2104; AWS Signature Version 4 |
| Remote administration | SSH with Ed25519 certificates | NIST SP 800-52; CIS Linux Benchmark |
| Long-term classified / sensitive data | AES-256-GCM + Hybrid Kyber1024 | NSA CNSA 2.0; NIST FIPS 203 (transition) |
| VPN (site-to-site or remote access) | WireGuard or IKEv2/AES-256-GCM | NIST SP 800-77 Rev. 1; CISA VPN Guidance |
| Email encryption | S/MIME with ECC or OpenPGP Ed25519 | NIST SP 800-177; DoD PKI Policy |
| Post-quantum transition (key exchange) | X25519Kyber768 hybrid | NIST FIPS 203; NSA CNSA 2.0 Timeline 2030–2035 |