Imagine putting a letter into a locked box before sending it through the post.

Anyone who intercepts the box can see that something has been sent, but without the key they shouldn’t be able to open the box to read what is inside.

That is the basic premise behind encryption.

Encryption transforms readable information – known as plaintext – into an unintelligible form called ciphertext.

Only someone with the appropriate key should be able to turn the ciphertext back into the original plaintext information.

Encryption is one of the most important technical controls used in cybersecurity.

It can protect information:

• While it is being transmitted
• While it is stored
• Between devices
• Between applications
• Across untrusted networks
• On lost or stolen devices
• In cloud environments
• In backups

But encryption isn’t simply a matter of “turning encryption on”.

The algorithms, keys, certificates, protocols and processes surrounding encryption are all important and need careful management processes – if one of those processes is compromised, potentially the encryption can be too.

What Is Encryption?

Encryption uses a mathematical algorithm and a key to transform plaintext into ciphertext.

The ciphertext should reveal very little useful information about the original message.The recipient uses the appropriate key to decrypt it

Modern encryption relies on cryptographic algorithms designed so that recovering the plaintext without the appropriate key is computationally impractical.

Encryption Is Not the Same as Encoding

This is an important distinction – Encoding is designed to represent data in another format.

For example Base64 encoding would turn the phrase Meet me at noon into TWVldCBtZSBhdCBub29u

Anyone can decode it just by following the known process.

Encryption is different – even if you know the process (the algorithm), without the key, the ciphertext should not be practically recoverable.

The simple thing to remember is:

Encoding changes representation. Encryption protects information.

For more information about encoding – see my blog post on ASCII smuggling

Encryption Is Not Hashing

Encryption is also different from hashing.

Encryption is designed to be reversible so long as you have the appropriate key

Hashing is designed to be effectively one-way – There is no normal “decrypt the hash” operation.

Hashing is commonly used for:

• Password storage
• Integrity checking
• Digital signatures
• File verification

Encryption is used when we need to recover the original information.

The Two Major Types of Encryption

There are two fundamental approaches to encryption:

1. Symmetric encryption
2. Asymmetric encryption

The major difference is how the keys work.

Symmetric Encryption

With symmetric encryption, the same secret key is used for encryption and decryption. Both parties need access to the same secret key.

The major advantage is speed – Symmetric encryption is generally much faster than asymmetric cryptography and is therefore ideal for encrypting large amounts of data.

Examples of Symmetric Algorithms

Common symmetric encryption algorithms include:

• AES
• ChaCha20
• 3DES — now obsolete/deprecated for most modern uses
• DES — obsolete and insecure

Of these, AES is particularly widespread.

It is used in:

• TLS
• VPNs
• Wi-Fi security
• Disk encryption
• File encryption
• Databases
• Applications

The Key Distribution Problem

Symmetric encryption has one major problem however – Both parties need the secret key.

Imagine Alice wants to communicate securely with Bob.

How does Alice securely give Bob the key in the first place?

If she sends it across an untrusted network, and an attacker has access to that network, they could intercept the key.

The attacker now has the key, and the ability to decrypt any future communications, but also any previous communications if they had been capturing them for just this opportunity.

This is one of the fundamental problems that asymmetric cryptography helps solve.

The Scalability Problem

Another problem faced when using symmetric encryption is that it does not scale well

Again, imagine Alice wants to communicate securely with Bob.

Here, only one key needs to be managed

But lets say both Alice and Bob also want to communicate with Claire

Now we have to manage three keys

• Alice – Bob
• Alice – Claire
• Bob – Claire

Now lets introduce Dave – Alice, Bob, and Claire all want to communicate with Dave

Now we have to manage six keys

• Alice – Bob
• Alice – Claire
• Alice – Dave
• Bob – Claire
• Bob – Dave
• Claire – Dave

This is not an easily scalable solution – again, solved with Asymmetric encryption

Asymmetric Encryption

Asymmetric cryptography uses a pair of mathematically related keys:

• A public key
• A private key

The public key can be shared – The private key must be protected.

Examples of asymmetric cryptographic algorithms include:

• RSA
• Elliptic-curve cryptography
• Elliptic-curve digital signature algorithms
• Diffie-Hellman and Elliptic-Curve Diffie-Hellman for key agreement

The public and private keys have different purposes – when one is used to encrypt data, the opposing key is the only one that can decrypt that data.

If the private key is compromised, an attacker may be able to impersonate the key owner or decrypt information, depending on how the key is being used.

Asymmetric Encryption vs Digital Signatures

Asymmetric cryptography can be used for different purposes.

For encryption, the basic concept is that a message encrypted with Bobs public kay can only be decrypted with Bobs private key

But asymmetric cryptography is also used for digital signatures.

A simplified signature process is where Bob generates a message and signs it with his Private key

The recipient of the message can verify the signature with Bobs public key – thus proving it originated from Bob.

This provides evidence of authenticity and integrity.

Symmetric vs Asymmetric

A useful comparison of the two systems is:

	Symmetric	Asymmetric
Keys	One shared secret	Public/private key pair
Speed	Very fast	Much slower
Large data	Excellent	Generally unsuitable
Key distribution	Difficult	Easier
Digital signatures	No	Yes
Typical use	Bulk encryption	Key exchange, signatures, identity

In practice, modern systems frequently use both – this is known as hybrid encryption.

Hybrid Encryption

TLS provides a good example of hybrid encryption.

It would be inefficient to use asymmetric cryptography to encrypt every byte of a long conversation – the mathematical processing overhead of encrypting and decrypting data with public & private keys makes the use impractical.

Instead, a secure connection can use asymmetric cryptography to establish, or authenticate cryptographic keys and then use fast symmetric encryption for the actual data.

Remember the problems associated with symmetric encryption:

• The key distribution problem
• The scalability problem

With TLS, Asymmetric encryption is used to distribute key material for use in generating session-specific symmetric keys

When a TLS session is established – the client device generates some random data which is used as the seed value for creating a symmetric key. This data is encrypted with the public key of the server the client wishes to communicate with.

Upon receipt of this data, the server decrypts it with its private key.

Both parties now have the exact same seed data, and both can now create the exact same symmetric key (A.K.A. the session key)

This symmetric key is now used for all future data transfer within this session and is destroyed once the session terminates

This approach solves both symmetric key problems

The symmetric data is able to be distributed in a secure manner, and because it is destroyed after use, there is no need to manage multiple symmetric keys, a new one is generated each session.

Block & Stream Ciphers

One important distinction when dealing with encryption is between block ciphers and stream ciphers.

A block cipher processes data in fixed-size blocks (For example, AES operates on blocks of 128 bits.)

A stream cipher processes data as a stream rather than as fixed-size blocks. (A common modern example is ChaCha20.)

Stream ciphers are particularly useful where data arrives continuously or where efficient software implementation is important.

Block vs Stream Ciphers

A simplified comparison of the two forms is:

	Block Cipher	Stream Cipher
Processing	Fixed-size blocks	Continuous stream
Example	AES	ChaCha20
Common use	Files, storage, TLS, VPNs	TLS, VPNs, real-time/streaming data
Typical concern	Correct mode of operation	Correct nonce/keystream handling

The distinction can become less obvious in modern cryptography because block ciphers can be operated in modes that make them behave similarly to stream ciphers.

For example, AES-CTR turns AES into a counter-mode stream-like construction.

So the distinction is useful, but modern cryptographic systems don’t always fit neatly into two boxes.

Nonces and IVs

Many encryption systems require an additional value to increase complexity such as an initialisation vector (IV) or Number Used Once (Nonce)

These values help ensure that encrypting the same plaintext doesn’t simply produce the same ciphertext every time.

In some algorithms, reusing a nonce with the same key can completely undermine security.

This is an excellent example of why cryptography isn’t just about selecting an algorithm – The implementation matters enormously.

Encryption in TLS

One of the most familiar uses of encryption is HTTPS.

When you visit a website such as https://cybertrainer.uk, your browser establishes a secure TLS connection with the webserver hosting the site.

Transport Layer Security (TLS) provides the cryptographic protection for the connection.

It helps provide:

• Confidentiality
• Integrity
• Server authentication

Modern TLS commonly uses asymmetric cryptography for authentication and/or key agreement, followed by efficient symmetric encryption for the application traffic.

Encryption in VPNs

VPNs also use cryptography to protect network traffic across networks that may not be trusted.

For example, you may be in an airport and wish to take advantage of the free Wi-Fi on offer. The problem is that you have no idea who might be monitoring the traffic when you use that Wi-Fi connection – the operators will certainly be monitoring the traffic, but their could also be threat actors “sniffing” the traffic looking for an opportunity to attack an unsuspecting traveller.

A VPN creates an encrypted “tunnel” between the client software on the device you use (e.g. phone, or laptop) and an endpoint server somewhere on the Internet.

All your browsing traffic is now protected between your device and the VPN endpoint, meaning that nobody on the free Wi-Fi can intercept and read your data.

Depending on the VPN technology, encryption may protect traffic between:

• User and organisation
• Site and site
• Device and cloud
• Application and service

The encryption prevents someone who can observe the underlying network from simply reading the protected traffic.

Encryption in Wi-Fi

Wireless networks use encryption to protect communications between devices and wireless infrastructure.

Modern Wi-Fi security technologies include:

• WPA2
• WPA3

Unlike a wired connection which would require physical access to the cables to intercept traffic, wireless signals can be intercepted by anyone with the right equipment – as such any traffic on a Wi-Fi network should by protected by encryption to prevent eavesdropping.

Encryption at Rest

Encryption isn’t only for traffic crossing a network – It can also protect information when it is stored.

This is called encryption at rest.

Examples include:

• Full-disk encryption
• Database encryption
• File encryption
• Encrypted USB drives
• Encrypted backups
• Cloud storage encryption

If a laptop hard drive is configured with full-disk encryption and is subsequently is stolen, the attacker shouldn’t be able to simply remove the disk and read its contents. Unless the drive is unlocked with the decryption key, the data on it will remain safe and secure.

Encryption in Backups

Backups are particularly important for individuals and organisations alike – nobody wants to lose data.

An organisation may have excellent security around its production systems but store backups on removable media that isn’t encrypted. As such, an attacker who steals the backup could potentially obtain a complete copy of the organisation’s information.

Encryption can therefore protect both the live data, and the backup data.

But remember – The encryption key needs protecting too.

If the backup and its encryption key are stored together, stealing both may defeat the protection.

Encryption in Messaging

End-to-end encrypted messaging is another important application.

In a properly designed end-to-end encrypted system, the service transporting the message may not have the ability to decrypt the content. One the endpoints of the conversation should have the ability to decrypt the data.

This is fundamentally different from simply encrypting a connection between a user and a service.

Public Key Infrastructure

This brings us to one of the most important concepts surrounding asymmetric cryptography:

Public Key Infrastructure (PKI).

PKI provides a framework for managing many aspects of modern encryption:

• Public keys
• Private keys
• Digital certificates
• Certificate authorities
• Trust relationships
• Certificate revocation
• Certificate renewal
• Key lifecycle management

PKI is a major part of the infrastructure behind technologies such as TLS.

Why Do We Need PKI?

Imagine connecting to https://mybank.example

Your browser receives a public key from the service hosting the domain. But how does the browser know that the key really belongs to the bank, and you haven’t somehow been tricked into visiting a fake version of the site?

An attacker could potentially say “Hello, I’m the bank. Here’s my public key.”

This is where certificates and certificate authorities come in to the equation.

A digital certificate binds an identity to a public key.

The certificate says, in effect “This public key belongs to this identity.“

But why should we trust the certificate?

A Certificate Authority (CA) is a trusted organisation or system that issues and signs digital certificates on behalf of entities.

The CA effectively says “We have verified that this certificate belongs to this entity.”

Web browsers and operating systems maintain lists of trusted certificate authorities.

The Certificate Chain

Trust doesn’t necessarily stop with a single CA.

Certificates can form a chain.

The browser can verify the chain back to a trusted root.

If the chain is valid and the certificate is appropriate for the site, the browser can establish trust in the server’s public key.

Root Certificate Authorities

A root CA is at the top of a certificate trust hierarchy.

Its certificate is normally trusted directly by operating systems or applications.

The security of this trust model depends heavily on protecting the CA’s private keys.

If an attacker obtains a CA’s private key, they may potentially be able to create fraudulent certificates that appear trustworthy.

One well-known example of an attack against a CA was the 2011 attack against the Dutch CA – DigiNotar.

An threat actor breached DigiNotar’s systems in mid-2011 and generated over 500 fake digital certificates for major domains, including Google, Yahoo, and Skype.

The fraudulently issued Google certificate was used to conduct a man-in-the-middle attack targeting an estimated 300,000 Iranian users to intercept encrypted web traffic and monitor communications.

As a result, major tech companies such as Mozilla, Microsoft, and Google revoked DigiNotar root certificates to make sure their browsers flagged the certificates as untrusted.

The Dutch government took over management of the compromised company, and DigiNotar filed for bankruptcy later that year.

You can read the full forensic report about the attack here

Certificate Expiration

Certificates have a validity period.

The reason for this is due to the fact that within the certificate is the service’s public key – the longer the key is in circulation, the greater the chance that someone could crack it – so by limiting the time a key is considered valid before a new key (and certificate) is produced, the less chance there is for someone to compromise the key.

After expiry, the certificate should no longer be considered valid.

This is why organisations need processes for:

• Certificate renewal
• Certificate inventory
• Expiration monitoring
• Automated deployment

An expired certificate can cause a perfectly healthy service to stop working correctly.

Certificate Revocation

What happens if a certificate is compromised before it expires?

Imagine a web server’s private key is stolen – Simply waiting until the certificate’s expiry date is not good enough – The certificate needs to be revoked.

There are several mechanisms for this.

Certificate Revocation Lists

A Certificate Revocation List (CRL) is a published list of certificates that should no longer be trusted. Applications can obtain the CRL and check whether a certificate has been revoked.

The downside is that CRLs can become large and need to be distributed and updated.

OCSP

The Online Certificate Status Protocol (OCSP) allows a client to ask an OCSP service about a particular certificate.

This can provide more targeted status information.

Modern browsers and TLS implementations have also adopted other approaches to improve certificate-status handling and resilience.

Certificate Management

Large organisations may have thousands of certificates for all the different services the operate both internally for staff, and externally for customers.

If certificates aren’t tracked properly, organisations can experience:

• Expired certificates
• Incorrect certificates
• Weak certificates
• Certificates issued to the wrong system
• Forgotten certificates
• Revocation problems

Certificate management is therefore an operational security task, not just a cryptographic one.

Key Management

Perhaps the most important principle in cryptography is:

If the key is compromised, the encryption may no longer protect the information.

This means organisations need a complete key-management lifecycle.

Each stage needs appropriate controls.

Generating Keys

Keys should be generated using a suitable source of cryptographically secure randomness. Weak key generation can undermine even the strongest encryption algorithm.

Cryptography is only as strong as its weakest critical component.

Protecting Private Keys

Private keys need particularly strong protection.

They might be stored in:

• Operating-system protected stores
• Hardware security modules
• Smart cards
• Security keys
• Cloud key-management services
• Dedicated cryptographic appliances

A Hardware Security Module (HSM) is a specialised device designed to securely generate, store and use cryptographic keys.

Instead of giving an application direct access to a private key, the application can ask the HSM to perform a cryptographic operation.

Key Rotation

As mentioned earlier – keys shouldn’t necessarily remain in use forever.

Organisations may rotate keys periodically or when there is a security reason to do so.

Key rotation limits the amount of information protected by a particular key and can reduce the impact of a compromised key.

Key Backup and Recovery

Key management creates an interesting problem. Suppose an organisation encrypts an enormous amount of data and then loses the encryption key – The data may become permanently inaccessible.

Keys therefore sometimes need secure backup and recovery mechanisms. But those backups themselves must be protected.

This creates an important balance:

Protect the key strongly enough that an attacker cannot steal it, but make recovery possible for authorised users when necessary.

Encryption and Defence in Depth

Encryption works particularly well as part of a layered security architecture.

If an attacker bypasses one control, other controls can still provide protection.

Encryption and the CIA Triad

Encryption primarily supports Confidentiality – It makes information difficult for unauthorised parties to read.

But modern authenticated encryption can also support Integrity – The use of digital signatures can ensure that the data received can be trusted and has not been altered.

Encryption doesn’t automatically guarantee availability however.

An encrypted system can still be:

• Destroyed
• Deleted
• Taken offline
• Hit by ransomware
• Denied access

This is why encryption is one part of a broader security architecture.

Encryption and the Parkerian Hexad

Encryption can also be considered through the Parkerian Hexad.

Security property	How encryption can help
Confidentiality	Prevents unauthorised disclosure
Integrity	Authenticated encryption can detect modification
Availability	Generally indirect; key loss can actually harm availability
Possession / Control	Protects data even if the physical storage is lost
Authenticity	Digital signatures can establish authenticity
Utility	Protects useful data, but lost keys can make it unusable

This illustrates something particularly important:

Encryption can protect information even after physical possession has been lost.

A stolen encrypted laptop is a good example – The attacker has possession of the device, but without the appropriate key, the information may remain confidential.

Encryption as a Security Control

Encryption is primarily a preventive control – It attempts to prevent unauthorised parties from accessing information.

However, cryptographic systems can also provide evidence of:

• Tampering
• Certificate misuse
• Failed authentication
• Key compromise
• Invalid signatures

So encryption can contribute to detective controls as well.

In Summary

Encryption transforms readable information into ciphertext so that unauthorised parties cannot easily understand it.

There are two major forms of cryptography used in modern systems:

Symmetric – Uses the same secret key to encrypt and decrypt.

Fast and ideal for bulk data.

Examples include:

• AES
• ChaCha20

Asymmetric – Uses a public/private key pair.

Slower, but useful for authentication, digital signatures and key agreement.

Examples include:

• RSA
• Elliptic-curve cryptography
• Diffie-Hellman variants

Modern systems commonly combine both approaches in a hybrid approach.

Encryption is used extensively in:

• TLS / HTTPS
• VPNs
• Wi-Fi
• Full-disk encryption
• File encryption
• Database encryption
• Cloud storage
• Backups
• End-to-end messaging

PKI provides the infrastructure needed to establish trust around public keys through:

• Digital certificates
• Certificate Authorities
• Root and intermediate CAs
• Certificate chains
• Certificate revocation
• CRLs
• OCSP
• Certificate renewal

And cryptographic keys require their own lifecycle

The most important lesson is therefore that Encryption isn’t just an algorithm.

It is an entire ecosystem of algorithms, keys, protocols, certificates, trust relationships, implementations and processes.

Get all of those right, and encryption can provide an extremely powerful layer of protection.

Get the key management wrong, and the world’s strongest encryption algorithm won’t save you.

The mathematics protects the data. The key management protects the mathematics.