7.2 Cryptography & Public Key Infrastructure

Cryptography & Public Key Infrastructure (PKI)

Cryptography is the mathematical foundation of modern cybersecurity. It transforms sensitive, human-readable data into unintelligible ciphertext, verifies the genuine identity of communicating parties across untrusted public networks, detects unauthorized tampering, and guarantees that digital transactions cannot be repudiated.

IT support specialists, network engineers, and system administrators must understand encryption primitives, key exchange protocols, cryptographic hashing, digital certificates, and Transport Layer Security (TLS) to securely manage systems, configure HTTPS web servers, deploy VPNs, and safeguard corporate data.

---

1. Cryptographic Fundamentals & Kerckhoffs's Principle

Cryptography relies on standardized mathematical terminology and fundamental security axioms:

• Plaintext ($P$): The original, unencrypted, human-readable or machine-readable cleartext data (e.g., a credit card number, source code, or email text).
• Ciphertext ($C$): The encrypted, scrambled, unreadable output produced after applying a cryptographic algorithm to plaintext.
• Cipher (Algorithm): The mathematical function or set of procedural steps used to perform encryption and decryption.
• Cryptographic Key ($K$): A secret piece of information (typically a string of random bits) that parameters the cipher. The key dictates the specific transformation of plaintext into ciphertext and vice versa.
• Encryption ($E_K(P) = C$): The mathematical process of converting plaintext into ciphertext using a key.
• Decryption ($D_K(C) = P$): The mathematical process of converting ciphertext back into original plaintext using a key.

+-----------------------------------------------------------------------------+
|                          THE ENCRYPTION PIPELINE                            |
|                                                                             |
|   [ Plaintext (P) ]  ---> [ Cipher + Key (K) ] ---> [ Ciphertext (C) ]      |
|   "Confidential Data"        (Mathematical Transform) "7aF9#k@2!vL9..."     |
|                                                              |              |
|   [ Plaintext (P) ]  <--- [ Cipher + Key (K) ] <--------------+              |
|   "Confidential Data"        (Decryption Transform)                         |
+-----------------------------------------------------------------------------+

Kerckhoffs's Principle & Shannon's Maxim

Formulated in 1883 by Auguste Kerckhoffs and restated by Claude Shannon as "the enemy knows the system":

• The Principle: A cryptographic system should be secure even if everything about the system, except the key, is public knowledge.
• Security Through Obscurity is a Flaw: Proprietary, secret algorithms developed behind closed doors almost always contain fatal mathematical flaws discovered as soon as attackers reverse-engineer them. In contrast, modern open cryptographic standards (e.g., AES, RSA, SHA-256) are published publicly and subjected to decades of rigorous global mathematical scrutiny by cryptanalysts. The system's security rests entirely upon the mathematical randomness and secrecy of the key.

---

2. Symmetric Encryption (Secret Key Cryptography)

In Symmetric Encryption, the exact same secret key is utilized for both encrypting the plaintext and decrypting the ciphertext. Both the sender and receiver must possess a copy of this shared secret key prior to initiating secure communication.

+-----------------------------------------------------------------------------+
|                       SYMMETRIC ENCRYPTION MODEL                            |
|                                                                             |
|   Alice                                                               Bob   |
|   [ Plaintext ]                                                [ Plaintext ]|
|         |                                                            ^      |
|         v                                                            |      |
|   [ Encryption ] ---> [ Encrypted Ciphertext ] ---> [ Decryption ]   |
|         ^                     (Public Transit)                       ^      |
|         |                                                            |      |
|   [ SHARED KEY ] =============================================> [ SHARED KEY ]
|               (Pre-Shared Secret Key via Secure Channel)                    |
+-----------------------------------------------------------------------------+

Characteristics of Symmetric Encryption:

• Blazing Computational Speed: Symmetric ciphers utilize lightweight bitwise operations (XOR, byte substitutions, permutations) optimized directly into modern CPU hardware instruction sets (e.g., Intel/AMD AES-NI). They are capable of encrypting gigabytes of data per second with negligible CPU overhead.
• Bulk Data Encryption: Ideal for high-throughput workloads—such as Full Disk Encryption (BitLocker, LUKS, FileVault), database storage encryption, and high-bandwidth VPN payload encapsulation.
• The Key Distribution Dilemma: Because the same key is used for encryption and decryption, the communicating parties must securely exchange the shared secret key over an untrusted network before they can communicate securely. Furthermore, as an organization scales to $n$ users, the number of individual pairwise symmetric keys required explodes quadratically according to the formula: $\text{Total Keys} = \frac{n(n - 1)}{2}$ (e.g., 100 users require 4,950 separate symmetric keys; 1,000 users require 499,500 keys).

Standard Symmetric Algorithms:

1. Data Encryption Standard (DES): Developed in 1977 utilizing a 56-bit key. Obsolete and completely broken. Modern computing power can brute-force the entire 56-bit keyspace in hours.
2. Triple DES (3DES): Applies the DES cipher three times sequentially across two or three distinct keys (112-bit or 168-bit effective key length). Legacy algorithm deprecated by NIST due to slow performance and vulnerabilities (Sweet32 attack).
3. Advanced Encryption Standard (AES / Rijndael): Established as the worldwide gold standard by NIST in 2001. A symmetric block cipher operating on 128-bit blocks of data using key sizes of 128, 192, or 256 bits. AES-256 provides uncompromised security against all known classical and quantum brute-force attacks.
4. ChaCha20: A modern, high-speed stream cipher operating with a 256-bit key. Highly efficient on mobile devices and embedded hardware lacking hardware-accelerated AES-NI CPU instructions.

Block Cipher Operational Modes:

Block ciphers encrypt data in fixed-size chunks (e.g., 128 bits for AES). Operational modes determine how blocks are chained:

• Electronic Codebook (ECB): Each block is encrypted independently with the same key. Critically insecure: Identical plaintext blocks produce identical ciphertext blocks, preserving visual and structural patterns (the infamous "ECB Tux Penguin" vulnerability). Never use ECB.
• Cipher Block Chaining (CBC): Each plaintext block is XORed with the previous ciphertext block before encryption, requiring an unpredictable Initialization Vector (IV) for the first block. CBC prevents pattern leakage but requires sequential processing and separate message integrity checks.
• Galois/Counter Mode (GCM): Modern standard combining counter-mode block encryption with Galois field authentication. It delivers Authenticated Encryption with Associated Data (AEAD)—providing both high-speed parallelized confidentiality and cryptographic tamper-proofing in a single pass.

---

3. Asymmetric Encryption (Public Key Cryptography)

In Asymmetric Encryption, introduced by Whitfield Diffie, Martin Hellman, and Ralph Merkle in 1976, cryptographic operations utilize a mathematically linked key pair consisting of a Public Key and a Private Key.

+-----------------------------------------------------------------------------+
|                       ASYMMETRIC ENCRYPTION MODEL                           |
|                                                                             |
|   Alice (Sender)                                                Bob (Receiver)|
|   [ Plaintext ]                                                 [ Plaintext ]|
|         |                                                             ^      |
|         v                                                             |      |
|   [ Encryption ] ---> [ Encrypted Ciphertext ] ---> [ Decryption ]    |
|         ^                     (Public Transit)                        ^      |
|         |                                                             |      |
|   [ Bob's PUBLIC Key ]                                      [ Bob's PRIVATE Key ]
|   (Freely Distributed)                                      (Kept Strictly Secret)|
+-----------------------------------------------------------------------------+

The Mathematical Key Pair Dynamic:

1. Public Key ($K_{pub}$): Can be freely published and distributed to anyone in the world (via web servers, certificate repositories, email signatures).
2. Private Key ($K_{priv}$): Must be kept strictly secret and guarded at all times by its owner (stored on hardware security tokens, TPM chips, or password-protected keyrings).

• Core Mathematical Rule: Data encrypted with a specific Public Key can only be decrypted by the corresponding Private Key. Conversely, data signed/encrypted with the Private Key can be verified/decrypted by anyone possessing the corresponding Public Key.

Solving Key Distribution:

Asymmetric cryptography eliminates the key distribution dilemma. To communicate securely with Bob, Alice simply fetches Bob's public key from the internet and encrypts her message. Only Bob possesses the private key required to decrypt it. In an organization of $n$ users, each user requires only 1 key pair (2 keys), scaling linearly: $\text{Total Keys} = 2n$ (e.g., 1,000 users require only 2,000 keys total, compared to 499,500 symmetric keys).

Computational Limitation:

Asymmetric encryption relies on complex number theory (large prime modular exponentiation, elliptic curve point multiplication). It is 1,000 to 10,000 times slower computationally than symmetric encryption and cannot efficiently encrypt large files or multi-gigabyte data streams.

Major Asymmetric Algorithms:

1. RSA (Rivest-Shamir-Adleman): Founded on the mathematical difficulty of factoring the product of two massive prime numbers. Standard key lengths: 2048 bits (minimum baseline) and 4096 bits (high security). Used widely in TLS handshakes, PGP, and SSH.
2. Elliptic Curve Cryptography (ECC): Based on the algebraic properties of elliptic curves over finite fields (e.g., ECDSA, Ed25519). ECC delivers equivalent cryptographic strength to RSA with drastically smaller key sizes and lower CPU/memory overhead:
   • 256-bit ECC key $\approx$ 3072-bit RSA key in security strength.
   • 384-bit ECC key $\approx$ 7680-bit RSA key in security strength.
3. Diffie-Hellman (DH) & Elliptic Curve Diffie-Hellman (ECDH): A revolutionary key-agreement protocol allowing two parties to establish a shared symmetric secret key across an insecure public channel without transmitting the secret itself.

Symmetric vs. Asymmetric Cryptography Comparison Matrix

---

4. Cryptographic Hashing & Message Authentication Codes (HMAC)

A Cryptographic Hash Function is a mathematical algorithm that takes an arbitrary-sized block of data (a single word, an entire ISO disk image, or a multi-terabyte database) and transforms it into a unique, fixed-length string of bits called a hash value, message digest, or checksum.

+-----------------------------------------------------------------------------+
|                        CRYPTOGRAPHIC HASH PROPERTIES                        |
|                                                                             |
|   [ Plaintext Input ]  ---> [ Hash Function (SHA-256) ] ---> [ Fixed Digest ]|
|   "The quick brown fox..."                                   "e3b0c44298fc..."|
|                                                               (256 bits)    |
|                                                                             |
|   1. ONE-WAY ONLY: Computationally infeasible to reverse digest to input.   |
|   2. DETERMINISTIC: Identical input always yields identical hash output.    |
|   3. FIXED LENGTH: Output size is constant regardless of input payload size.|
|   4. AVALANCHE EFFECT: Changing 1 bit in input alters ~50% of hash output.  |
|   5. COLLISION RESISTANT: Infeasible to find two inputs with identical hash.|
+-----------------------------------------------------------------------------+

The Five Essential Hash Function Properties:

1. One-Way (Pre-image Resistance): It is computationally impossible to invert or reverse-engineer the original plaintext input from the output hash digest ($y = H(x)$; given $y$, finding $x$ is impossible).
2. Deterministic: The exact same input data will always produce the exact same hexadecimal digest every time it is processed.
3. Fixed-Length Output: Regardless of whether the input is 1 byte or 100 gigabytes, the output digest is always a fixed bit length (e.g., SHA-256 always outputs exactly 256 bits / 64 hex characters).
4. The Avalanche Effect: A microscopic change in the input (such as flipping a single bit, changing a lowercase letter to uppercase, or adding a space) completely scrambles the output digest, changing approximately 50% of the resulting hash bits.
5. Collision Resistance: It is computationally infeasible to find two different, distinct input messages $m_1$ and $m_2$ such that $H(m_1) = H(m_2)$. When two distinct inputs produce the same digest, a hash collision occurs, breaking the cryptographic integrity of the algorithm.

Standard Hash Algorithms:

• MD5 (Message Digest 5): Generates a 128-bit digest. Cryptographically broken. Practical collision attacks can generate colliding PDF or binary files in seconds. Never use MD5 for security.
• SHA-1 (Secure Hash Algorithm 1): Generates a 160-bit digest. Cryptographically broken. Deprecated by NIST, Google (SHAttered attack), and all major browsers.
• SHA-2 Family: Designed by the NSA and published by NIST. Standard variants include SHA-256 (256-bit digest) and SHA-512 (512-bit digest). Highly secure and universally deployed across TLS certificates, blockchain, and OS package verification.
• SHA-3 Family: Published by NIST in 2015 based on the Keccak sponge construction algorithm. Provides an entirely different internal mathematical architecture from SHA-2 as a resilient fallback.

Cryptographic Hash Algorithms Matrix

Hash-Based Message Authentication Code (HMAC)

A standard hash alone provides data integrity (detecting accidental corruption), but does not prove authenticity because an active attacker intercepting a message could modify the text, recompute the SHA-256 hash, and forward both to the recipient.

• HMAC ($HMAC(K, m)$): Combines a cryptographic hash function with a secret shared key. Only a party possessing the secret key can generate or verify the valid HMAC digest, guaranteeing both data integrity and message authentication.

---

5. Digital Signatures & Non-Repudiation

A Digital Signature is a mathematical scheme that combines asymmetric cryptography with cryptographic hashing to provide three vital security guarantees: Authenticity (proving who sent the message), Integrity (proving the message was not modified in transit), and Non-Repudiation (preventing the sender from denying their action).

+-----------------------------------------------------------------------------+
|                        DIGITAL SIGNATURE WORKFLOW                           |
|                                                                             |
|   [ SIGNING PROCESS - Sender (Alice) ]                                      |
|   1. Message (M) -------------> [ Hash (SHA-256) ] ---> [ Digest ]          |
|                                                              |              |
|   2. [ Digest ] + [ Alice's PRIVATE Key ] -------------> [ DIGITAL SIGNATURE]|
|                                                                             |
|   ======================== TRANSMISSION OVER NETWORK =====================  |
|   [ Message (M) ] + [ DIGITAL SIGNATURE ] sent across untrusted network      |
|   ========================================================================  |
|                                                                             |
|   [ VERIFICATION PROCESS - Receiver (Bob) ]                                 |
|   1. Message (M) -------------> [ Hash (SHA-256) ] ---> [ Computed Digest ] |
|                                                                |            |
|   2. [ DIGITAL SIGNATURE ] + [ Alice's PUBLIC Key ] --> [ Decrypted Digest ]|
|                                                                |            |
|   3. Compare: [ Computed Digest ] === [ Decrypted Digest ] ?  |            |
|      --> MATCH: Signature VALID (Integrity & Authenticity Confirmed!)       |
|      --> MISMATCH: Signature REJECTED (Data altered or forged key!)         |
+-----------------------------------------------------------------------------+

The Signing Process (Sender: Alice):

1. Alice generates a cryptographic hash digest of the original message using SHA-256.
2. Alice encrypts the resulting hash digest using her Private Key. This encrypted digest is the Digital Signature.
3. Alice transmits both the original message (in plaintext or encrypted form) and the attached Digital Signature to Bob.

The Verification Process (Receiver: Bob):

1. Bob receives the message and the digital signature.
2. Bob independently computes a fresh SHA-256 hash digest of the received message.
3. Bob decrypts the attached digital signature using Alice's publicly accessible Public Key, which reveals the original hash digest created by Alice.
4. Bob compares the two digests:
   • If the digests match: Bob has mathematical proof that the message was not altered by even a single bit (Integrity), and that it was genuinely signed by the holder of Alice's private key (Authenticity and Non-Repudiation).
   • If the digests do not match: The message was either tampered with in transit, or signed with an unauthorized key.

---

6. Public Key Infrastructure (PKI) & Digital Certificates

While asymmetric cryptography allows secure encryption and digital signatures, it introduces a critical vulnerability: The Public Key Authenticity Problem. If an attacker (Eve) performs a Man-in-the-Middle (MitM) attack and tricks Alice into accepting Eve's public key as belonging to Google or Bob, Eve can intercept, decrypt, and manipulate all communications.

Public Key Infrastructure (PKI) solves this problem by binding a specific public key to a verified real-world entity (e.g., example.com, an individual, or an organization) through trusted digital identity credentials called X.509 Digital Certificates.

+-----------------------------------------------------------------------------+
|                         PKI TRUST CHAIN HIERARCHY                           |
|                                                                             |
|   [ ROOT CERTIFICATE AUTHORITY (Root CA) ]                                  |
|   - Self-signed, high-trust root certificate                                |
|   - Stored offline in high-security physical vault                          |
|   - Pre-installed in OS / Browser Trusted Root Stores                       |
|                         |                                                   |
|                         v Signs Intermediate CA                             |
|   [ INTERMEDIATE CERTIFICATE AUTHORITY (Intermediate CA) ]                  |
|   - Online CA utilized for daily certificate issuance                       |
|   - Isolates and shields Root CA private key from exposure                  |
|                         |                                                   |
|                         v Signs End-Entity Cert                             |
|   [ LEAF / SERVER CERTIFICATE (End-Entity) ]                                |
|   - Issued to domain (e.g., https://www.google.com)                         |
|   - Validated by client browser traversing chain up to Root CA              |
+-----------------------------------------------------------------------------+

The Anatomy of an X.509 Certificate:

An X.509 standard certificate contains standardized metadata and cryptographic fields:

• Subject: The distinguished name of the entity being certified (e.g., CN=www.example.com, Organization, Locality, Country).
• Subject Alternative Name (SAN): Modern extension listing all domain names, subdomains, and IP addresses covered by the certificate (e.g., DNS:example.com, DNS:*.example.com for wildcards).
• Public Key: The certified entity's public key (RSA 2048/4096 or ECC P-256).
• Issuer: The Certificate Authority that verified the subject and digitally signed the certificate.
• Validity Period: Strict operational dates (Not Before and Not After).
• Serial Number: A unique alphanumeric identifier assigned by the issuing CA.
• Signature Algorithm: The cryptographic algorithm used by the CA to sign the certificate (e.g., SHA256withRSAEncryption or ECDSA-with-SHA384).
• CA Digital Signature: The cryptographic signature generated using the CA's private key.

The PKI Chain of Trust:

Operating systems and web browsers maintain a built-in Trusted Root Store containing the public certificates of globally trusted Root Certificate Authorities (e.g., DigiCert, Let's Encrypt, Sectigo, GlobalSign).

1. When a client browser connects to https://www.example.com, the web server presents its Leaf (End-Entity) Certificate and the Intermediate CA Certificate.
2. The browser validates the signature on the leaf certificate using the Intermediate CA's public key.
3. The browser validates the signature on the intermediate certificate using the Root CA's public key found in its local trusted root store.
4. If all signatures in the Chain of Trust are cryptographically valid, within their validity dates, and match the accessed domain name, the browser displays the secure lock icon.

Certificate Revocation Mechanisms:

When a private key is compromised, an employee leaves a company, or a domain registration lapses, certificates must be revoked before their official expiration date:

• Certificate Revocation List (CRL): A periodically published, CA-signed blacklist file containing serial numbers of revoked certificates. Limitations: High network latency, heavy bandwidth consumption, and client caching delays.
• Online Certificate Status Protocol (OCSP): An interactive protocol where the client queries the CA's OCSP responder server in real time over HTTP to check certificate status (Good, Revoked, Unknown). Limitations: Introduces connection latency and leaks user browsing history to the CA.
• OCSP Stapling (TLS Certificate Status Request): The modern standard solution. The web server itself periodically queries the CA OCSP responder, receives a cryptographically signed, timestamped status assertion, and "staples" this proof directly into the initial TLS handshake with the client browser. This eliminates client lookup latency, enhances privacy, and removes load from CA servers.

---

7. Transport Layer Security (TLS) & Secure Communication

Transport Layer Security (TLS) is the industry-standard cryptographic protocol operating above the transport layer (TCP port 445 for SMB, 443 for HTTPS, 993 for IMAPS) to provide end-to-end encryption, authentication, and tamper-resistance across untrusted networks.

+-----------------------------------------------------------------------------+
|                      TLS 1.2 vs. TLS 1.3 HANDSHAKE TIMELINE                 |
|                                                                             |
|   [ TLS 1.2: 2 Full Round Trips (2-RTT) ]                                   |
|   Client                                                           Server   |
|     | -------- ClientHello (Supported Ciphers) --------------------> |      |
|     | <------- ServerHello + Certificate + ServerKeyExchange ------ | (1 RTT)
|     | -------- ClientKeyExchange + [Finished] ---------------------> |      |
|     | <------- [Finished] (Session Keys Active) -------------------- | (2 RTT)
|     | <====== Encrypted Application Data Transfer (Symmetric AES) ===> |      |
|                                                                             |
|   [ TLS 1.3: 1 Round Trip (1-RTT) with Perfect Forward Secrecy ]            |
|   Client                                                           Server   |
|     | -------- ClientHello + Key Share (ECDHE) --------------------> |      |
|     | <------- ServerHello + Key Share + Cert + [Finished] -------- | (1 RTT)
|     | <====== Encrypted Application Data Transfer (Symmetric AES) ===> |      |
+-----------------------------------------------------------------------------+

Hybrid Cryptography in Action:

TLS combines the best attributes of asymmetric and symmetric cryptography:

1. Asymmetric / ECDH Key Exchange: Utilized exclusively during the initial handshake to authenticate server identity and securely negotiate a shared session key.
2. Symmetric Encryption (AES-GCM / ChaCha20): Used for all subsequent application data transfer, delivering high-speed, hardware-accelerated bulk encryption.

TLS 1.2 vs. TLS 1.3 Evolution:

• TLS 1.2: Required a 2-RTT (Two Round-Trip Time) handshake before encrypted data could flow. Supported legacy, insecure cryptographic primitives (RSA static key exchange, CBC-mode ciphers, RC4, MD5, SHA-1).
• TLS 1.3 (RFC 8446):
  • Streamlined 1-RTT Handshake: Combines key agreement and cipher negotiation into a single round trip, dramatically reducing web page load latency.
  • 0-RTT Resumption (Early Data): Allows returning clients to transmit encrypted requests on the very first packet.
  • Mandatory Perfect Forward Secrecy (PFS): Permanently eliminated static RSA key exchange; mandates Ephemeral Diffie-Hellman (ECDHE).
  • Purged Obsolete Ciphers: Completely removed support for CBC modes, 3DES, RC4, MD5, and SHA-1, restricting ciphers strictly to secure AEAD algorithms (AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305).

Perfect Forward Secrecy (PFS)

Perfect Forward Secrecy guarantees that compromising a server's long-term private key in the future does not allow an adversary to retroactively decrypt historical encrypted network traffic previously recorded and stored. Because TLS 1.3 utilizes ephemeral ECDHE keys generated uniquely per session, each session's symmetric encryption key is permanently destroyed as soon as the session terminates.