Cryptography and Public Key Infrastructure

Cryptography comes from Greek words meaning 'hidden writing'. At its simplest, it's a way to scramble a message so that only the intended recipient can unscramble it. The original, readable message is called plaintext. The scrambled version is ciphertext. The mathematical recipe that does the scrambling is an algorithm (a set of rules). The secret value that makes each encryption unique is a key.

There are two main families of encryption: symmetric and asymmetric. Symmetric encryption uses one single key for both locking and unlocking. Think of it like a single padlock key: the same key locks the chest and unlocks it. The problem? You have to get that shared key to the other person without anyone else seeing it. If the internet is the courier, and there's a spy on every wire, sharing the key securely is almost impossible. AES (Advanced Encryption Standard) is a common symmetric algorithm used for bulk data encryption because it is very fast. The 350-701 exam expects you to recognise AES-128, AES-192, and AES-256 (the number indicates the key length in bits).

Asymmetric encryption (also called public key cryptography) solves the key-sharing problem. Each person generates two mathematically linked keys: a public key and a private key. The public key can be shared with anyone — posted on a website, emailed, even carved on a billboard. The private key must be kept absolutely secret, never shared. What one key encrypts, only the other can decrypt. So if Bob wants to send Alice a secret, he encrypts the message with Alice's public key. Only Alice's private key can decrypt it. The most famous asymmetric algorithm is RSA (named after its inventors Rivest, Shamir, Adleman). The exam also tests ECC (Elliptic Curve Cryptography), which provides equivalent security with shorter keys, making it more efficient.

But asymmetric encryption is mathematically complex and slow. Practical systems use hybrid encryption: they use asymmetric encryption to safely exchange a temporary symmetric key (called a session key), then use that symmetric key for the fast bulk encryption of the actual data. This is exactly how HTTPS (secure web browsing) works.

Hashing is the third fundamental cryptographic operation, distinct from encryption. A hash function takes any amount of data and produces a fixed-length fingerprint called a digest or hash value. Cryptography relies on hash functions having three properties: they are deterministic (same input always gives same output), preimage resistant (you cannot reverse the hash to get the original data), and collision resistant (it is extremely unlikely for two different inputs to produce the same hash). Common hash algorithms include SHA-256 (Secure Hash Algorithm, 256-bit version) and the older, now-insecure MD5. The 350-701 exam frequently tests understanding of hashing used for data integrity verification.

Digital signatures combine hashing and asymmetric encryption. The sender hashes the message, then encrypts that hash with their own private key. The recipient decrypts the hash with the sender's public key and recomputes the hash themselves. If the two hashes match, it proves two things: integrity (the message wasn't changed) and non-repudiation (the sender cannot deny sending it, because only they have the private key that created the signature). This is the core of document signing and software authentication.

Public Key Infrastructure (PKI) is the system that manages the trust. An entity called a Certificate Authority (CA) issues digital certificates. A digital certificate binds a public key to an identity (like a company name or a domain). The CA signs the certificate with its own private key, creating a trusted chain. Your browser has a built-in list of trusted root CA certificates. When you visit https://www.yourbank.com, the web server presents its certificate. Your browser checks the signature chain up to a trusted root, verifies the domain matches, and checks the current date is within the certificate validity period. Only then does the browser trust the public key and begin the encrypted session. The 350-701 exam expects you to understand the components of PKI: CA, RA (Registration Authority, which verifies the identity before the CA issues a certificate), CRL (Certificate Revocation List, a list of certificates that have been invalidated before expiry), and OCSP (Online Certificate Status Protocol, a real-time check for revoked certificates).

Imagine you are a network security engineer at a medium-sized company called 'SwiftBooks'. Your CFO receives an email that appears to be from the CEO, asking her to urgently wire €50,000 to a new supplier. The email looks legitimate — the CEO's name, signature, even the company logo. How do you prevent this fraud?

You would implement digital signatures for all internal emails. You set up an internal CA (perhaps using Microsoft Active Directory Certificate Services). You configure it to issue email signing certificates to every employee. The RA function is handled by your HR system: when a new person is hired, their identity is verified (ID check, manager approval), and the RA approves a certificate request. The CA then issues a certificate that binds the employee's email address to their public key, all signed by the company CA's private key.

Now when your CFO receives the urgent transfer request, her email client automatically checks the digital signature. First, it finds the sender's certificate attached. It verifies the certificate chain: the sender's certificate was signed by the company CA certificate, which is stored in the company's trusted root store on all workstations. The signature verification succeeds. Next, it checks whether that certificate has been revoked by querying an OCSP responder running on your internal network. The certificate is valid. Finally, it checks the email content's hash against the signature — the hash matches perfectly, proving the email wasn't altered. The email client shows a green 'signed' indicator. The CFO feels confident the request is real.

But what if a fraudster intercepts the email and changes the bank account number? The digital signature verification would fail. The hash wouldn't match. The CFO would see a red warning: 'signature invalid' or 'message altered'. She would pick up the phone to verify the request before wiring any money. This real-world scenario shows how PKI prevents business email compromise attacks, a trillion-dollar problem globally. In your daily work, you would also manage certificate lifecycles: monitoring expiry dates (a certificate expiring silently can break encrypted connections), revoking certificates for departing employees, and updating the CRL and OCSP responder. You would also face the decision of which key lengths to use: 2048-bit RSA keys are currently standard, but you might start migrating to 4096-bit or ECDSA (using ECC) for future-proofing against faster computers.