Cryptography and Secure Communications

Introduction and context

Modern networks carry credentials, financial transactions, health information, intellectual property and operational commands across infrastructure that is often shared or hostile. Cryptography provides the technical mechanisms for protecting this information. It does not, however, make a system automatically secure. Cryptographic protection depends on sound algorithms, correct implementation, trustworthy key management, authenticated endpoints, secure protocols and appropriate operational governance.

This chapter examines the principal cryptographic tools used in network, Internet and cloud security: symmetric encryption, asymmetric encryption, hashing, message authentication, digital signatures, certificates, public key infrastructure (PKI), and key management. It then applies these ideas to TLS, IPsec, SSH and virtual private networks (VPNs).

Learning objectives

By the end of this chapter, you should be able to:

• distinguish confidentiality, integrity, authentication and non-repudiation;
• explain symmetric and asymmetric encryption and select between them appropriately;
• describe hashes, message authentication codes and digital signatures;
• explain certificates, PKI and certificate validation;
• apply secure key-generation, storage, rotation and revocation practices;
• describe the security functions of TLS, IPsec, SSH and VPN technologies;
• identify common cryptographic failures and recommend practical controls.

Security services and the cryptographic toolkit

A security design normally seeks four related services:

Availability is also essential, but cryptography alone cannot guarantee it. Availability requires resilient architecture, capacity planning, monitoring and recovery controls.

Cryptographic algorithms use a key-controlled transformation. Encryption converts plaintext into ciphertext; decryption recovers plaintext for an authorised recipient. The security objective is not that the algorithm remains secret. Well-designed systems follow Kerckhoffs’s principle: security should depend on the secrecy of the key, not on secrecy of the algorithm.

Symmetric encryption

Symmetric cryptography uses the same secret key, or securely related secret keys, for encryption and decryption. It is computationally efficient and is therefore used to protect large volumes of data, including network traffic, databases, backups and cloud storage.

A simplified representation is:

Here, P is plaintext, C is ciphertext, K is the secret key, E_K is encryption under K, and D_K is the corresponding decryption operation. The relationship applies only when the correct key, algorithm and mode are used.

Block and stream ciphers

A block cipher transforms fixed-size blocks. AES, with a 128-bit block size and commonly used 128-, 192- or 256-bit keys, is the dominant general-purpose standard. A block cipher must be used with an appropriate mode of operation. ECB mode is unsuitable for ordinary confidential data because identical plaintext blocks produce identical ciphertext blocks. Modes such as GCM provide authenticated encryption and are widely preferred.

A stream cipher generates a keystream combined with plaintext, commonly using exclusive OR. Stream constructions can be efficient, but reusing a nonce or keystream can expose plaintext. ChaCha20-Poly1305 is an important modern authenticated-encryption construction, especially where software performance or hardware support makes it attractive.

Authenticated encryption

Confidentiality without integrity is unsafe. An attacker might alter ciphertext, even if unable to read it. Authenticated encryption with associated data (AEAD) protects confidential plaintext and produces an authentication tag. Associated data, such as a protocol header, can be authenticated without being encrypted.

The sender supplies a key, nonce, plaintext and associated data; the receiver verifies the tag before accepting the plaintext. A nonce generally need not be secret, but it must satisfy the construction’s uniqueness requirement for a given key. Nonce reuse can be catastrophic for schemes such as GCM.

The key-distribution problem

If a system has n participants and every pair requires a distinct shared key, the number of pairwise keys is:

Here, K is the number of keys and n is the number of participants, assuming one unique key per unordered pair. For 10 participants, K = 10 × 9 ÷ 2 = 45. This scaling problem makes manual symmetric-key distribution unsuitable for large, dynamic networks. Asymmetric cryptography and centralised key-management systems address this challenge.

Asymmetric cryptography

Asymmetric, or public-key, cryptography uses a mathematically related public key and private key. The public key may be distributed widely; the private key must remain under the owner’s control. Depending on the operation, a public key can encrypt information for the private-key holder, or a private key can create a signature verifiable with the public key.

Public-key encryption is generally slower than symmetric encryption. Consequently, modern protocols usually use asymmetric cryptography to authenticate parties and establish a temporary symmetric session key, then use symmetric AEAD to protect the data stream. This is called hybrid cryptography.

RSA remains historically important, although modern deployments increasingly use elliptic-curve cryptography (ECC), such as elliptic-curve Diffie–Hellman (ECDH) for key agreement and elliptic-curve digital signature algorithms. The security of these systems depends on difficult mathematical problems and on correct parameter choices. Post-quantum cryptography is developing because sufficiently capable quantum computers could threaten widely used public-key systems, particularly those based on integer factorisation and discrete logarithms.

Key agreement

Diffie–Hellman key agreement allows two parties to derive a shared secret over an observable network without directly transmitting that secret. In a simplified multiplicative group, Alice selects private value a and sends g^a, while Bob selects b and sends g^b. Both derive g^ab. The values and group notation are simplified; secure implementations use approved groups and authenticated protocol specifications. Unauthenticated Diffie–Hellman is vulnerable to a man-in-the-middle attack, so the exchanged values must be authenticated, commonly with certificates or pre-established keys.

Ephemeral key agreement creates temporary private values for each session. When used correctly, compromise of a long-term private key does not necessarily reveal previously recorded sessions. This property is forward secrecy.

Hashing, MACs and signatures

A cryptographic hash function maps an input of arbitrary length to a fixed-length digest. A secure hash should make it computationally infeasible to recover the input, find a different input with the same digest, or deliberately find any collision. SHA-256 and SHA-3 are examples of approved modern hash families. MD5 and SHA-1 should not be selected for collision-resistant security applications.

A hash is not encryption: it is not designed to be reversed, and it does not by itself authenticate the sender. Passwords should not be stored as ordinary hashes. They should be processed with a password-specific, salted and deliberately expensive password-hashing function such as Argon2id, scrypt or bcrypt.

A message authentication code (MAC) combines a secret key and message to produce an authentication value. HMAC is a widely used construction based on a hash function. A MAC provides integrity and origin authentication to parties that share the secret, but it does not provide public verifiability because either party could have generated it.

A digital signature is generated using a private key and verified with the corresponding public key. In practice, the signer usually signs a digest of the message. A signature supports integrity, origin authentication and, within an appropriate legal and operational framework, evidence of signing. It does not automatically prove that a real-world person intended an action; identity binding, key protection, audit records and policy are also required.

Certificates and public key infrastructure

A digital certificate binds a public key to an identity or subject through a trusted issuer. X.509 certificates commonly contain the subject, issuer, public key, validity period, serial number, permitted uses, policy information and the issuer’s digital signature.

PKI is the collection of technology, people, procedures and governance used to issue, validate, renew, suspend and revoke certificates. Its main components include:

• a certification authority (CA), which signs certificates;
• a root CA, usually kept highly protected and used sparingly;
• one or more intermediate CAs, which issue end-entity certificates;
• registration processes that verify subject identity;
• repositories and status mechanisms such as CRLs or OCSP;
• policies defining assurance, permitted uses and responsibilities.

A certificate chain typically runs from an end-entity certificate through intermediate CAs to a trusted root already configured in the client’s trust store. Validation includes signature checks, validity dates, subject-name matching, key-usage and extended-key-usage checks, chain construction and revocation/status processing. Trusting a certificate merely because it is syntactically valid is insufficient.

A self-signed certificate can be appropriate for controlled internal systems when the organisation securely distributes and manages its trust anchor. It is not automatically trustworthy on the public Internet.

Key management

Cryptographic strength is undermined when keys are generated predictably, exposed in source code, shared excessively or retained indefinitely. A professional key-management lifecycle includes:

1. Generation: use an approved cryptographic random-number generator and suitable key sizes.
2. Distribution: protect keys in transit and ensure the recipient is authenticated.
3. Storage: use hardware security modules, trusted platform capabilities, dedicated secret managers or encrypted keystores where appropriate.
4. Use: enforce purpose, permissions, algorithm and environment restrictions.
5. Rotation: replace keys according to risk, exposure, usage volume and policy.
6. Backup and recovery: protect backups under separate controls and test restoration.
7. Revocation and destruction: invalidate compromised or retired keys and securely erase key material when no longer required.

Key separation is important: do not use one key for unrelated purposes, such as encryption and signing. Access should follow least privilege, with dual control or separation of duties for high-impact CA and HSM operations. Secrets should not be placed in application repositories, container images, tickets or chat messages. Cloud key-management services can improve control, but responsibility for permissions, configuration, data classification and recovery remains with the customer under the shared-responsibility model.

Secure communication protocols

TLS

Transport Layer Security protects application sessions such as HTTPS, secure email and API connections. A contemporary TLS exchange generally involves:

1. negotiation of protocol parameters and supported cryptographic suites;
2. server authentication using a certificate, with optional client authentication;
3. authenticated ephemeral key agreement;
4. derivation of symmetric traffic keys;
5. authenticated encryption of application data.

TLS 1.3 reduces obsolete options and normally provides forward secrecy through ephemeral key exchange. Certificate validation must include hostname verification and trust-chain validation. Disabling validation to “fix” a connection is a serious security defect. TLS protects data in transit between authenticated endpoints; it does not protect compromised endpoints, malicious applications, or data after it is decrypted.

IPsec

IPsec operates at the network layer and is commonly used for site-to-site and remote-access VPNs. Authentication Header (AH) can provide integrity and origin authentication but is rarely used because it does not provide confidentiality and interacts poorly with address translation. Encapsulating Security Payload (ESP) can provide confidentiality, integrity and authentication.

Internet Key Exchange (IKEv2) negotiates security associations, authenticates peers and establishes keys for ESP. Tunnel mode encapsulates an entire original IP packet and is common between gateways; transport mode protects the payload of an IP packet and is used in more specialised host-to-host arrangements. Strong algorithms, authenticated peers, restricted traffic selectors and current patches are required.

SSH

Secure Shell provides encrypted remote administration, file transfer and tunnelling. Host keys authenticate the server, while user authentication may use public keys, certificates, passwords or multi-factor methods. On first connection, an administrator must verify the host key through a trusted channel rather than blindly accepting any fingerprint. Private keys should be encrypted with a passphrase and protected by an agent or hardware-backed mechanism where feasible. Root login, password-only administration and broad forwarding permissions should be restricted.

VPN design

A VPN creates a protected logical path across an untrusted network, but “VPN” does not identify a single security level. Design choices include:

• remote-access versus site-to-site connectivity;
• full-tunnel versus split-tunnel routing;
• identity-based versus network-based access;
• device posture and multi-factor authentication;
• route, DNS and name-resolution controls;
• logging, monitoring and session termination.

Full tunnelling can improve central inspection but increases bandwidth and latency. Split tunnelling can improve performance but may permit a device to bridge trusted resources and hostile networks. Zero-trust designs increasingly grant narrow, application-specific access rather than broad network reachability.

Applied case: a secure cloud administration service

Background. An illustrative organisation operates a cloud-hosted payment-support platform. Administrators previously used a shared VPN account, SSH passwords and self-signed web certificates. Logs showed repeated login attempts, and an audit found that one private key was copied into a deployment repository.

Problem. The organisation needed confidentiality for administrative traffic, reliable identity verification, rapid revocation and evidence of administrative actions.

Analysis. The shared account prevented attribution. Password authentication was vulnerable to guessing and reuse. The self-signed certificates were accepted without a controlled trust-distribution process. The exposed private key could permit impersonation, and the VPN granted more network access than most administrators required.

Approach. The organisation established a managed PKI and a documented certificate policy. Public-facing services used certificates whose names matched their DNS identities. Administrators used individual accounts, phishing-resistant multi-factor authentication and short-lived SSH certificates or hardware-protected keys. Password-based SSH login was disabled. A cloud secret-management service and HSM-backed CA keys replaced repository secrets. The VPN was changed to identity-aware, least-privilege access with separate administrative segments. TLS 1.3-capable configurations, secure cipher suites, central logging and alerting were deployed. The exposed key was revoked and replaced, and repository history was examined for additional secrets.

Outcome. Attribution improved, broad network access was reduced and certificate and key replacement became measurable operational processes. The organisation also recognised that cryptography could not compensate for an unpatched administrator workstation or excessive permissions.

Learning points. Secure communication requires a complete system: authenticated identities, protected keys, current protocols, least privilege, monitoring and incident response. Revocation and recovery must be designed before compromise occurs.

Challenges, limitations and governance

Cryptography cannot solve endpoint compromise, malicious insiders, incorrect authorisation, insecure backups or social engineering. Strong algorithms can be defeated by weak passwords, poor random-number generation, nonce reuse, certificate-validation errors and leaked keys. Availability can also be affected by certificate expiration, inaccessible key services or overly restrictive firewall rules.

Organisations should maintain an inventory of cryptographic assets, classify data, define approved algorithms and monitor certificate expiry. They should plan for algorithm deprecation and post-quantum migration, especially for data requiring long-term confidentiality. Regulatory obligations may govern personal data, payment information, health records, electronic signatures, export controls and audit evidence. Legal requirements vary by jurisdiction; technical controls must therefore be aligned with organisational policy and applicable law.

Ethically, security professionals should minimise unnecessary collection, protect confidential keys, avoid deceptive interception and disclose weaknesses through responsible processes. TLS inspection in enterprises may support malware analysis, but it creates additional trusted decryption points and privacy risks. It requires transparent policy, strict access controls, limited retention and appropriate authorisation.

Best-practice checklist

• Prefer modern, maintained protocols and authenticated encryption.
• Never invent cryptographic algorithms or modes.
• Validate certificates, names, purposes, dates and trust chains.
• Use unique nonces as required by the algorithm.
• Generate keys with approved random sources and protect private material.
• Separate keys by purpose and environment.
• Use individual identities, MFA and least privilege.
• Rotate, revoke, back up and destroy keys through documented procedures.
• Keep cryptographic libraries and protocol implementations patched.
• Monitor certificate expiry, unusual key use, failed authentication and VPN activity.
• Test recovery, compromise response and post-quantum migration plans.

Chapter Summary

Cryptography supplies mechanisms for confidentiality, integrity and authentication, but secure communication is a system property rather than an algorithmic feature. Symmetric encryption is efficient for bulk data, while asymmetric cryptography supports authentication and key agreement. Hashes provide fixed-length integrity digests; MACs authenticate messages to shared-key holders; digital signatures provide publicly verifiable evidence associated with a private key. Certificates and PKI bind keys to identities through governed trust chains. Key management—generation, distribution, storage, rotation, revocation and destruction—is central to security.

TLS protects application sessions, IPsec protects network-layer traffic, SSH secures administration and VPNs create controlled paths across untrusted networks. Correct deployment requires current protocols, certificate validation, forward secrecy, protected keys, least privilege, monitoring and recovery planning. Limitations, privacy, regulatory duties and emerging post-quantum risks must also be considered.

Key Terms

Cryptography: The study and practice of protecting information using mathematical techniques.

Plaintext: Information in its intelligible, unencrypted form.

Ciphertext: Encrypted information produced from plaintext.

Symmetric encryption: Encryption using a shared secret key.

Asymmetric cryptography: Cryptography using related public and private keys.

AEAD: Authenticated encryption with associated data.

Nonce: A value intended for controlled use with a cryptographic operation, often requiring uniqueness.

Hash function: A function that maps arbitrary input to a fixed-length digest.

MAC: A keyed value used to authenticate a message and detect alteration.

Digital signature: A private-key-generated value verified with a public key.

Certificate: A signed binding between a public key and an identified subject.

PKI: The people, policies, technology and processes supporting certificate trust.

Certification authority: An entity that issues and signs certificates.

Certificate revocation: The invalidation of a certificate before its expiry.

Forward secrecy: Protection of past sessions if a long-term key is later compromised.

TLS: A protocol for authenticated, encrypted application communication.

IPsec: A suite of network-layer security protocols.

SSH: A protocol for secure remote login, transfer and tunnelling.

VPN: A protected logical connection across an untrusted network.

Key management: The lifecycle control of cryptographic keys.

Review Questions

Short Answer Questions

1. What is the difference between confidentiality and integrity?
2. Why is symmetric encryption normally used for bulk network traffic?
3. What purpose does a certificate serve in TLS?
4. Why should passwords not be stored as ordinary unsalted hashes?
5. What is forward secrecy?

Long Answer Questions

1. Compare symmetric and asymmetric cryptography, including their strengths, limitations and typical combined use in TLS.
2. Explain how a certificate chain is validated from an end-entity certificate to a trusted root.
3. Describe a complete cryptographic key-management lifecycle.
4. Compare TLS, IPsec and SSH in terms of operating layer, use cases and authentication.
5. Explain why authenticated encryption is preferable to confidentiality-only encryption.

Analytical / Application Questions

1. An organisation discovers that an SSH private key was committed to a public repository. Analyse the immediate and longer-term actions required to contain and recover from the incident.
2. A company is choosing between a full-tunnel and split-tunnel remote-access VPN. Evaluate the security, performance and governance trade-offs.
3. A web service uses a valid certificate but users receive warnings because the certificate name does not match the service hostname. Explain why the certificate is not sufficient and propose a correct solution.

Multiple Choice Questions with Answers

Question 1

Which mechanism is primarily designed to provide confidentiality and integrity together for network data?

A. Authenticated encryption with associated data

B. A plain cryptographic hash

C. A certificate revocation list

D. A public DNS record

Correct Answer: A. Authenticated encryption with associated data

Question 2

For 10 participants requiring one unique shared symmetric key per pair, how many keys are required?

A. 10

B. 20

C. 45

D. 100

Correct Answer: C. 45

Question 3

What is the principal function of a digital certificate?

A. To compress encrypted traffic

B. To bind a public key to an identity through a trusted issuer

C. To replace all private keys

D. To guarantee endpoint availability

Correct Answer: B. To bind a public key to an identity through a trusted issuer

Question 4

Which statement about a cryptographic hash is correct?

A. It is normally reversible with the public key

B. It provides confidentiality by itself

C. It produces a fixed-length digest from input data

D. It always authenticates the sender

Correct Answer: C. It produces a fixed-length digest from input data

Question 5

What is a major danger of reusing a nonce with an AEAD construction such as GCM?

A. It can seriously compromise security

B. It makes certificates expire sooner

C. It converts a public key into a private key

D. It prevents all traffic from being routed

Correct Answer: A. It can seriously compromise security

Question 6

Which protocol is primarily associated with secure remote administration?

A. FTP

B. SSH

C. ARP

D. ICMP

Correct Answer: B. SSH

Question 7

Which IPsec component commonly provides confidentiality and integrity for protected IP traffic?

A. ESP

B. AH only

C. DNSSEC

D. SMTP

Correct Answer: A. ESP

Question 8

What does forward secrecy aim to provide?

A. Permanent reuse of one session key

B. Protection of past sessions if a long-term private key is compromised

C. Automatic recovery from hardware failure

D. Public access to private keys

Correct Answer: B. Protection of past sessions if a long-term private key is compromised

Question 9

Which practice is most appropriate for a high-value CA private key?

A. Store it in a public source repository

B. Place it in an email attachment

C. Protect it using strong access controls and an HSM where appropriate

D. Share it among all administrators

Correct Answer: C. Protect it using strong access controls and an HSM where appropriate

Question 10

Why is certificate hostname verification important?

A. It confirms that the certificate is associated with the intended service identity

B. It increases the encryption key length automatically

C. It removes the need for a private key

D. It guarantees that the server software is unpatched

Correct Answer: A. It confirms that the certificate is associated with the intended service identity