Lesson 2.1: Cryptographic Foundations

00 Introduction

Unit 1 developed the vocabulary of enterprise security. Unit 2 turns to the technologies that enforce it. Cryptography is the foundation on which most of those technologies rest.

Cryptography is the discipline of securing information through mathematical transformations. It enables enterprises to store data without exposing it, transmit data across untrusted networks, verify that data has not been altered, prove the identity of a message's source, and establish the trust relationships that identity systems depend on. Almost every security objective from Lesson 1.3 — confidentiality, integrity, availability, authenticity, accountability, and non-repudiation — relies on cryptographic mechanisms.

This lesson establishes the foundation for the six that follow. It introduces what cryptography does, the security services it provides, the two major approaches (symmetric and asymmetric), the discipline of key management, the primitive building blocks from which cryptographic systems are assembled, and — most importantly — the ways cryptography fails in practice. The last of these is where enterprises most often come unstuck. Cryptographic algorithms are rarely broken; cryptographic systems routinely are.

The material here is conceptual. You will not implement cryptographic algorithms. You will, however, be expected to evaluate cryptographic choices — to judge whether an enterprise's use of encryption is sound, whether its key management is defensible, and whether the cryptographic components of a system meet the enterprise's objectives. That is a judgement about engineering, not mathematics.

How to read this lesson

Sections 1–5 establish the conceptual foundation. Sections 6–7 turn to failure modes and enterprise application. If you are short on time, read Sections 6 and 7 carefully — the failure modes and enterprise application are what the rest of the course assumes you can reason about.

01 Learning objectives

By the end of this lesson you should be able to:

Lesson objectives

Explain what cryptography is and the four security services it provides.
Distinguish symmetric from asymmetric cryptography and identify where each is appropriate.
Describe the role of key management and explain why it is the most common cryptographic failure point.
Identify the principal cryptographic primitives and what each is used for.
Analyse common cryptographic failure modes in enterprise systems.
Evaluate cryptographic applications against enterprise requirements.

These objectives contribute to Unit 2 outcome U2.1 (cryptographic principles), and to Module 1 outcomes M1.9 (cryptographic principles) and M1.10 (algorithm selection). See the Unit 2 learning outcomes page for the full mapping.

02 What cryptography does

Cryptography is best understood by what it enables rather than by what it is. At the enterprise level, cryptography provides four capabilities:

Protecting confidentiality

Making information unreadable to parties who do not hold the appropriate key.
Applies to data at rest (storage, backups, endpoints) and data in transit (between systems, users, and services).
The most visible use of cryptography, but not the only one — and not the most important.

Detecting modification

Enabling detection of unauthorised changes to data, messages, or files.
Provides integrity — one of the most under-appreciated cryptographic services.
Underpins trust in everything from software updates to financial transactions.

Establishing authenticity

Verifying that a message, document, or software artifact originates from the party it claims to originate from.
Enables digital signatures, code signing, and trusted updates.
Central to trust infrastructure — from TLS certificates to secure boot.

Enabling non-repudiation

Providing cryptographic evidence that a specific party performed a specific action.
Stronger than password-based authentication, which can be repudiated on the basis that credentials were shared or stolen.
Required in contexts where actions must be legally or commercially defensible.

The relative prominence of these capabilities has shifted over time. Early enterprise cryptography focused almost exclusively on confidentiality — the protection of secret information. Modern cryptography is equally concerned with integrity and authenticity, because modern attacks increasingly target the integrity of transactions, software, and trust relationships rather than just the confidentiality of data.

Cryptography's role in the enterprise

Cryptography appears in enterprise systems at every layer:

Data at rest. Full-disk encryption, database encryption, object-store encryption, backup encryption, and file-level encryption.
Data in transit. TLS for web and API traffic, IPsec for network traffic, SSH for administrative access, and encrypted messaging protocols.
Identity and access. Password storage, authentication tokens, federated identity assertions, and multi-factor authentication mechanisms.
Software integrity. Code signing, secure boot, package verification, and supply-chain attestation.
Trust infrastructure. Certificate authorities, public key infrastructure, time-stamping services, and hardware security modules.
Blockchain and distributed systems. Cryptographic primitives underpin distributed ledgers, consensus protocols, and decentralised identity systems.

The ubiquity of cryptography means that failures in cryptographic implementation rarely stay local. A weak key management system affects every system that depends on the affected keys. A compromised certificate authority affects every party that trusts it. This is why cryptography deserves the attention it receives, and why treating it as a technical detail to be delegated is a recurring source of enterprise breach.

The most useful habit

When you encounter a cryptographic control in an enterprise — encryption at rest, TLS, code signing — ask not "is it encrypted?" but "how is the key managed?". Cryptographic algorithms are almost always adequate. Key management is where enterprises fail. The habit of asking about key management will serve you throughout the course.

03 The four security services

Cryptographic systems provide four distinct security services. Each is provided by specific mechanisms, and each has distinct failure modes. Understanding which services are needed in a given context is the first step in evaluating a cryptographic design.

Confidentiality

Confidentiality is provided by encryption: the transformation of plaintext into ciphertext using an algorithm and a key, such that only parties holding the appropriate key can recover the plaintext. Encryption addresses the risk of unauthorised reading — whether of data at rest (on storage media), in transit (across networks), or, with newer techniques, in use (during processing).

The strength of encryption depends on three things: the algorithm, the key length, and the key management practices. The algorithm is rarely the weakest link. Key length matters, but beyond a certain point additional length provides diminishing returns. Key management is where most failures occur.

Integrity

Integrity is provided by hashing and by message authentication codes. A hash function produces a fixed-length value from arbitrary input; if the input changes, the hash changes. This allows a party to verify that data has not been modified since the hash was computed.

Hashes alone do not establish authenticity — an attacker who can modify the data can also modify the hash. Message authentication codes (MACs) combine a hash with a shared secret key, so that only a party holding the key can generate a valid MAC. This provides both integrity and authenticity to parties who share the key.

Authenticity

Authenticity is provided by digital signatures. A digital signature is generated using a private key and verified using the corresponding public key. It confirms both that the signed content has not been altered (integrity) and that the signature was produced by the holder of the private key (authenticity).

Digital signatures are central to trust infrastructure. TLS certificates, code signing, signed updates, and secure boot all rely on digital signatures. Their strength depends on the security of the private key — which is why key protection is such a critical concern for signing systems.

Non-repudiation

Non-repudiation is provided by digital signatures combined with trustworthy key management and time-stamping. It differs from authenticity in emphasis: authenticity establishes that a message came from the claimed source; non-repudiation establishes that the source cannot credibly deny having sent it.

Non-repudiation requires that the signer's private key be protected so that the signer cannot claim the key was compromised. It also requires trusted time-stamping so that the signer cannot claim the action occurred at a different time. These are demanding requirements, and non-repudiation is correspondingly more difficult to achieve than authenticity.

Security services and the mechanisms that provide them
Service	Mechanism	Key requirement
Confidentiality	Encryption	A shared secret key (symmetric) or a recipient's public key (asymmetric)
Integrity	Hashing, message authentication codes	No key (hash alone) or shared secret (MAC)
Authenticity	Digital signatures, MACs	Signer's private key, or shared secret
Non-repudiation	Digital signatures, trusted timestamps, protected keys	Protected private key, trusted time source

Common confusion

Encryption and hashing are frequently confused. Encryption is reversible (given the key); hashing is not. Encryption is used to protect confidentiality; hashing is used to detect modification. Encrypting a password instead of hashing it is a common error — passwords should be hashed (with a salt and a modern password-hashing function), not encrypted, because encryption implies the ability to recover the plaintext.

04 Symmetric and asymmetric approaches

Cryptography divides into two broad families, distinguished by the relationship between the keys used for encryption and decryption. The distinction matters because each family has different properties, different strengths, and different appropriate uses. The two are not alternatives; they are complements.

Symmetric cryptography

In symmetric cryptography, the same key is used to encrypt and to decrypt. Sender and receiver must both possess the key — hence the alternative name, "shared-secret cryptography". Symmetric algorithms are fast, well understood, and well suited to bulk encryption of data at rest and in transit.

The challenge of symmetric cryptography is key distribution. If two parties wish to communicate securely, they must first establish a shared secret key through some secure channel. Doing this at enterprise scale — between thousands of systems, users, and services — is impractical without additional mechanisms. This is the problem that asymmetric cryptography was developed to solve.

The principal symmetric algorithms — DES, Triple DES, and AES — are examined in Lesson 2.2. For now, the essential point is that symmetric cryptography is fast and efficient but requires a secure means of distributing the key.

Asymmetric cryptography

In asymmetric cryptography, encryption uses one key and decryption uses a different, mathematically related key. The two keys form a pair: a public key that can be widely distributed, and a private key that must be kept secret. Data encrypted with the public key can only be decrypted with the private key, and vice versa.

The principal advantage of asymmetric cryptography is that it solves the key distribution problem. Parties can exchange public keys openly, and no shared secret needs to be communicated in advance. This makes asymmetric cryptography foundational to modern trust infrastructure — digital signatures, certificate authorities, and TLS all rely on it.

The principal disadvantage is performance. Asymmetric algorithms are substantially slower than symmetric algorithms, and are unsuited to bulk encryption. For this reason, real-world cryptographic systems typically use asymmetric cryptography to establish a shared secret key, then use symmetric cryptography to protect the actual data.

The principal asymmetric algorithms — RSA, elliptic-curve cryptography, and Diffie–Hellman — are examined in Lesson 2.3. Digital signatures and public key infrastructure are examined in Lesson 2.4.

How the two work together

The combination of symmetric and asymmetric cryptography is the basis of virtually every secure network protocol in use today. The pattern runs as follows:

Establish trust Parties exchange public keys or obtain certificates from a trusted authority, establishing trust in each other's public keys.
Negotiate a shared secret Using asymmetric cryptography (or a key-agreement protocol such as Diffie–Hellman), the parties establish a shared symmetric key.
Protect data with symmetric encryption The shared symmetric key is used to encrypt the actual data, exploiting symmetric cryptography's speed and efficiency.
Provide integrity with message authentication MACs or authenticated encryption ensure that the data has not been modified in transit.

This is essentially the pattern used by TLS, SSH, IPsec, and most other secure protocols. When you see "encryption" in an enterprise context, the underlying mechanism is almost always this hybrid approach.

Symmetric and asymmetric cryptography compared
Dimension	Symmetric	Asymmetric
Keys	One shared key	Key pair (public and private)
Performance	Fast	Slow (orders of magnitude slower)
Key distribution	Requires secure channel	Public key can be shared openly
Use cases	Bulk data encryption; at-rest encryption; session encryption	Key exchange; digital signatures; certificates
Scalability	Poor — requires pairwise keys	Good — public keys can be widely distributed
Principal algorithms	DES, Triple DES, AES	RSA, ECC, Diffie–Hellman
Typical enterprise use	Data at rest; session encryption in TLS	TLS handshake; code signing; certificate infrastructure

How to tell them apart

A quick test: does the same key both encrypt and decrypt? If yes, symmetric. Are there two keys, one of which can be shared openly? If yes, asymmetric. In practice, you rarely encounter one without the other — asymmetric to establish trust and exchange keys, symmetric to protect data at scale.

05 Key management

Cryptographic algorithms are rarely broken. Cryptographic systems routinely are — and key management is the most common point of failure.

Key management is the set of practices and mechanisms used to generate, distribute, store, use, rotate, and destroy cryptographic keys. It is the operational discipline that determines whether cryptography provides the security properties it promises. An enterprise with strong algorithms and weak key management has weak cryptography, regardless of the sophistication of the algorithms involved.

The key management lifecycle

Generation

Keys must be generated using a cryptographically secure random number generator. Weak randomness is a recurring failure mode — some high-profile incidents have involved keys generated with predictable values, rendering otherwise strong algorithms useless.

Distribution

Keys must reach the parties that need them without being exposed. For symmetric keys this is a hard problem — the very channel that needs protecting cannot be used to distribute the key. Asymmetric cryptography solves this by allowing public keys to be shared openly.

Storage

Keys at rest must be protected from unauthorised access. Hardware security modules (HSMs) and key management services provide protected storage; storing keys in configuration files, source code, or unencrypted storage is a frequent weakness.

Use

Keys must be used within protected environments, with access restricted to the systems and processes that need them. Logging and auditing of key use supports detection of compromise.

Rotation

Keys must be replaced periodically — and immediately if compromise is suspected. Rotation limits the impact of a key compromise by bounding the period of exposure. Enterprises that never rotate keys accumulate unquantified risk.

Revocation

Keys that are compromised or no longer needed must be revoked, and the revocation must be communicated to parties relying on them. Certificate revocation is a persistent practical problem in enterprise environments.

Destruction

Keys that are no longer needed must be securely destroyed, so that historical data encrypted with them cannot be decrypted if later recovered. Destruction is the least visible step and the easiest to neglect.

Why key management fails

Key management fails for structural reasons that recur across enterprises:

Keys are hard to see. Unlike users, systems, and applications, keys do not appear in most asset registers. Enterprises frequently do not know where their keys are, who manages them, or what systems depend on them.
Keys are hard to change. Rotating a key requires coordinating every system that depends on it. The perceived cost of rotation discourages it, and the key remains in place long past its intended lifetime.
Convenience competes with security. Storing keys in configuration files, environment variables, or source code is convenient. Using a hardware security module or a key management service is not. The convenient option is often chosen.
Accountability is diffuse. Key management often sits at the boundary between security, operations, application teams, and platform teams. Each may assume another owns the problem.
Complexity accumulates. Over time, enterprises accumulate keys for different systems, protocols, applications, and third-party services. Each is managed separately, and the aggregate picture becomes impossible to maintain.

Key management in cloud environments

Cloud adoption has complicated key management in some respects and simplified it in others. Providers offer key management services that handle much of the operational complexity — generation, storage, rotation — and integrate with their encryption offerings. The enterprise retains accountability for the policies that govern key use, the classification of data protected by each key, and the decisions about who can access what.

The shared responsibility model applies to keys as it does to other controls. The provider secures the underlying key management infrastructure; the enterprise is responsible for configuring it appropriately, managing access to keys, and deciding which data is protected by which keys. Enterprises that treat cloud key management as a solved problem by the provider often discover that they have not configured it well, and that the resulting exposure is theirs.

The single most common cryptographic failure

If you were to identify the single most common cryptographic failure in enterprise systems, it would be this: the enterprise does not know where its keys are, who can access them, or what they protect. This is not a mathematical failure — it is a management failure. Addressing it requires inventory, policy, and governance, not stronger algorithms.

06 Cryptographic primitives

Cryptographic systems are built from a small number of primitive building blocks. Understanding what each primitive does, and what it does not do, is essential to evaluating cryptographic designs.

Block ciphers

Encrypt data in fixed-size blocks (typically 128 bits). AES is the dominant block cipher. Requires a mode of operation to handle data longer than one block, and the choice of mode matters substantially for security.

Stream ciphers

Encrypt data one bit or byte at a time, typically by combining the plaintext with a pseudorandom keystream. Efficient for continuous data streams and low-latency applications. ChaCha20 is a modern example.

Hash functions

Produce a fixed-length digest from arbitrary input. Used for integrity verification, password storage, digital signatures, and blockchain systems. SHA-256 is the most widely used modern hash function.

Message authentication codes

Combine a hash function or block cipher with a shared secret key to provide both integrity and authenticity. HMAC is the most common construction. Used extensively in network protocols and API authentication.

Key derivation functions

Derive cryptographic keys from passwords, passphrases, or other secret material. Designed to be computationally expensive so that brute-force attacks on weak inputs are infeasible. PBKDF2, bcrypt, scrypt, and Argon2 are common examples.

Random number generators

Produce the random values on which most cryptographic operations depend. Cryptographically secure random number generators (CSPRNGs) are essential; weak random number generation is a recurring and often catastrophic failure mode.

Key exchange protocols

Allow two parties to establish a shared secret key over an untrusted channel. Diffie–Hellman and its elliptic-curve variants are the foundations of modern secure protocols.

Public-key encryption

Encrypt data using a recipient's public key, so that only the holder of the corresponding private key can decrypt. RSA and elliptic-curve variants are the principal examples. Used for key transport and small payloads, not bulk data.

Digital signatures

Produce a value that can be verified using the signer's public key, confirming both integrity and authenticity. RSA signatures and ECDSA are the dominant schemes. Central to trust infrastructure.

Composition matters

Cryptographic systems are rarely built from a single primitive. A single secure protocol may combine half a dozen primitives in specific ways. The composition is where design expertise matters most — and where subtle failures are introduced.

A modern TLS connection, for example, combines key exchange (to establish a shared secret), digital signatures (to authenticate the server), symmetric encryption (to protect application data), and message authentication (to detect modification). Each primitive is used for a specific purpose, in a specific order, with specific parameters. Getting any of these wrong can undermine the security of the whole.

This is why the industry has moved toward standardised, well-reviewed protocols and libraries rather than custom cryptographic constructions. Enterprises should not design their own cryptographic protocols; they should use established ones, correctly.

The most useful question

When you encounter a cryptographic system, ask: what primitives does this use, and are they being used in the standard way? Custom constructions, non-standard parameters, and "clever" designs are almost always a warning sign. The history of cryptographic failures is dominated by implementations that were novel where they did not need to be.

07 How cryptography fails

Cryptographic algorithms are rarely the weak point in enterprise systems. Cryptographic systems routinely are. Understanding the failure modes is essential to evaluating cryptographic choices.

Failure mode 1 — Weak or predictable keys

Keys generated from weak random sources, derived from predictable values (dates, device identifiers, passwords), or reused across systems or users provide far less protection than the algorithm's nominal strength. Some of the most significant cryptographic failures in history have involved keys that were generated with inadequate randomness.

The countermeasure is to use cryptographically secure random number generators and to avoid any temptation to derive keys from user-provided material without a proper key-derivation function.

Failure mode 2 — Poor key management

Keys stored in configuration files, source code, environment variables, or unencrypted storage are vulnerable to unauthorised access. Keys that are never rotated accumulate exposure. Keys that are not revoked when they should be continue to provide access long after they should have been retired. As Section 4 argued, key management is the most common point of cryptographic failure.

Failure mode 3 — Weak algorithm or mode choices

Legacy algorithms (DES, MD5, SHA-1, RC4) remain in use in many enterprises, often in systems that have not been updated. Weak modes of operation (ECB mode in block ciphers, for example) introduce structural weaknesses even with strong algorithms. Cryptographic parameters that were appropriate a decade ago may be inadequate today.

The countermeasure is to retire legacy algorithms, use modern modes (such as GCM or CBC with authenticated encryption), and periodically reassess cryptographic parameters in light of evolving attack capabilities.

Failure mode 4 — Implementation errors

Subtle implementation flaws — timing attacks, padding oracle vulnerabilities, improper error handling, memory safety issues — can undermine strong algorithms. These are difficult to detect through code review alone and are the primary reason enterprises should use well-tested cryptographic libraries rather than writing their own.

Failure mode 5 — Protocol design flaws

Even with strong algorithms and correct implementations, flawed protocol design can undermine security. Failure to authenticate messages, failure to prevent replay, or misuse of cryptographic primitives for purposes they were not designed for are recurring patterns. Historical protocol vulnerabilities — in early versions of TLS, in WEP, and in various proprietary protocols — illustrate the pattern.

Failure mode 6 — Improper certificate validation

TLS implementations that fail to properly validate certificates — accepting expired certificates, ignoring hostname mismatches, or failing to check revocation — expose connections to man-in-the-middle attacks. This is one of the most common and most exploited cryptographic failures in enterprise environments.

Failure mode 7 — Cryptographic agility problems

Systems that hard-code cryptographic choices cannot adapt when algorithms are deprecated or when new threats emerge. When SHA-1 was deprecated, or when TLS 1.0 and 1.1 were retired, enterprises with hard-coded cryptographic parameters found themselves scrambling to update systems that had not been designed to be updated. Cryptographic agility — the ability to change algorithms and parameters without redesigning systems — is increasingly recognised as a design requirement.

Cryptographic failure modes and their countermeasures
Failure mode	Countermeasure
Weak or predictable keys	Cryptographically secure random number generation; proper key derivation functions
Poor key management	Centralised key management; hardware security modules; rotation policy; revocation processes
Weak algorithm or mode choices	Modern algorithms (AES, SHA-256, ECC); authenticated modes; periodic reassessment
Implementation errors	Use well-reviewed libraries; avoid custom cryptographic code; regular security review
Protocol design flaws	Use standard protocols; avoid custom protocols; follow published guidance
Improper certificate validation	Use standard TLS libraries; verify certificate chains, hostnames, expiry, and revocation
Cryptographic agility problems	Design for change; abstract cryptographic choices; plan for algorithm migration

The most consequential failure

Of the seven failure modes, poor key management is both the most common and the most consequential. Enterprises frequently invest in strong algorithms and then undermine them by mismanaging the keys that make the algorithms useful. Every cryptographic control in an enterprise should be accompanied by a clear answer to: where is the key, who has access to it, how often is it rotated, and how would we know if it were compromised?

08 Cryptography in the enterprise

Cryptography is not a single control but a set of mechanisms deployed throughout the enterprise estate. Evaluating their collective adequacy requires reasoning about coverage, key management, and the objectives each mechanism serves.

Where cryptography appears

Cryptography across the enterprise estate
Domain	Typical cryptographic mechanisms	Primary objectives served
Data at rest	Full-disk encryption, database encryption, object-store encryption, backup encryption, file-level encryption	Confidentiality, integrity
Data in transit	TLS, IPsec, SSH, encrypted messaging	Confidentiality, integrity, authenticity
Identity and access	Password hashing, authentication tokens, federated assertions, MFA mechanisms	Confidentiality, authenticity, accountability
Software integrity	Code signing, package verification, secure boot, supply-chain attestation	Integrity, authenticity
Trust infrastructure	Certificate authorities, public key infrastructure, time-stamping, hardware security modules	Authenticity, non-repudiation
Backup and archival	Backup encryption, archived data encryption, key escrow	Confidentiality, integrity, availability

Evaluating cryptographic adequacy

Evaluating whether an enterprise's cryptography is adequate is not a question about algorithms. It is a question about coverage, key management, and alignment with objectives. Useful questions include:

Coverage. Is encryption applied consistently to all data that requires it? Are there gaps — legacy systems, third-party platforms, backup media, endpoint devices — where sensitive data is unprotected?
Key management. Where are keys stored? Who has access? How are they rotated? How would the enterprise know if a key were compromised?
Algorithm currency. Are legacy algorithms still in use? Are cryptographic parameters current with modern guidance?
Protocol configuration. Are TLS configurations hardened? Are certificate validation, cipher suites, and protocol versions correctly configured?
Cryptographic agility. Can the enterprise migrate to new algorithms when needed without redesigning systems?
Alignment with objectives. Does the cryptography actually serve the objectives the enterprise needs? Encrypting data that does not need encryption while leaving sensitive data unprotected is a common pattern.

Common enterprise cryptographic weaknesses

A small number of weaknesses recur across enterprises. Recognising them accelerates assessment:

Unmanaged keys. Keys scattered across applications, configuration files, and cloud services, with no central inventory or policy.
Legacy algorithms. SHA-1, MD5, DES, RC4, and TLS 1.0/1.1 persisting in systems that have not been modernised.
Certificate validation failures. Applications that accept any certificate, ignore hostname mismatches, or fail to check revocation.
Unencrypted backups. Backups stored without encryption, often on media that is more exposed than the production systems they protect.
Missing encryption in transit. Internal traffic assumed to be safe because it stays "inside" the enterprise — an assumption no longer valid in cloud and hybrid environments.
Weak password storage. Passwords hashed with fast hashes (MD5, SHA-1) without salt or with inadequate iteration counts.
Hard-coded secrets. Keys, passwords, and tokens embedded in source code, container images, or build artefacts.

Worked example — evaluating a healthcare provider's encryption

A healthcare provider is reviewing its cryptographic posture. It has implemented full-disk encryption on clinical workstations, TLS on its patient portal, and database encryption on its electronic health record system.

Initial assessment: The provider has addressed the most visible encryption requirements. Coverage at the endpoints, on the portal, and in the primary database meets regulatory expectations.

Deeper questions: The assessment continues by asking about the areas that are easy to overlook:

Are backups encrypted with keys that are managed independently of the production keys? If not, a compromise of production keys compromises backups too.
Are the encryption keys for the EHR system stored in a hardware security module, or in application configuration? If the latter, a compromise of the application server exposes both data and keys.
Is TLS configuration hardened, or does it still support legacy ciphers for compatibility with clinical devices?
Are medical device communications encrypted? Many clinical devices use older protocols that lack modern cryptography, and their communications may be unprotected on internal networks.
Is encryption key access logged and reviewed, so that unauthorised use can be detected?
Is there cryptographic agility — can the provider migrate away from algorithms or protocols when they are deprecated?

The exercise illustrates that assessing cryptographic adequacy requires going beyond the headline encryption controls to examine key management, configuration, coverage gaps, and cryptographic agility. The provider's cryptography may be adequate in the visible areas and inadequate in the areas that matter most.

09 Key concepts

The terms below are used throughout the course. Capture them in your own words as you work through the lesson.

Cryptography: The discipline of securing information through mathematical transformations. Provides confidentiality, integrity, authenticity, and non-repudiation services.
Plaintext / ciphertext: Plaintext is information in its original form; ciphertext is the encrypted form. Encryption transforms plaintext into ciphertext; decryption reverses the transformation.
Symmetric cryptography: Encryption using a single shared secret key for both encryption and decryption. Fast and efficient, but requires secure key distribution. Principal algorithms: DES, Triple DES, AES.
Asymmetric cryptography: Encryption using a mathematically related key pair — a public key that can be widely distributed and a private key that is kept secret. Solves key distribution but is slower than symmetric cryptography. Principal algorithms: RSA, ECC, Diffie–Hellman.
Key: A value used with a cryptographic algorithm to encrypt, decrypt, sign, or verify. The security of a cryptographic system depends on the secrecy and management of its keys.
Key management: The set of practices and mechanisms used to generate, distribute, store, use, rotate, revoke, and destroy cryptographic keys. The most common point of cryptographic failure in enterprises.
Key rotation: The periodic replacement of cryptographic keys, and the immediate replacement of keys whose compromise is suspected. Limits the impact of a key compromise by bounding the period of exposure.
Hash function: A function that produces a fixed-length digest from arbitrary input, such that any change to the input produces a different digest. Used for integrity verification, password storage, and digital signatures. SHA-256 is the most widely used modern hash function.
Message authentication code (MAC): A value computed from a message and a shared secret key, providing both integrity and authenticity to parties who share the key. HMAC is the most common construction.
Digital signature: A cryptographic value generated using a private key and verified using the corresponding public key, providing integrity, authenticity, and — with appropriate key management — non-repudiation.
Encryption at rest: Encryption applied to data stored on media — disks, databases, object stores, backups. Protects against unauthorised reading if media is lost or accessed.
Encryption in transit: Encryption applied to data moving between systems. Protects against interception. TLS is the dominant protocol for web and API traffic; IPsec for network traffic.
Authenticated encryption: Encryption that provides both confidentiality and integrity in a single operation. Modern modes such as AES-GCM are authenticated; naive encryption without integrity is a common source of vulnerability.
Cryptographic agility: The ability of a system to change cryptographic algorithms and parameters without redesign. Increasingly recognised as a design requirement as algorithms are deprecated and new threats emerge.
Cryptographically secure random number generator (CSPRNG): A random number generator suitable for cryptographic use — producing values that are unpredictable to an adversary. Weak randomness is a recurring and often catastrophic failure mode.
Hardware security module (HSM): A dedicated hardware device for generating, storing, and using cryptographic keys, with strong protection against extraction or misuse. Used for high-assurance key management.

10 Activities

The activities below help you test your understanding and prepare for the unit discussion and Assignment 1. They are not graded, but completing them will improve the quality of your forum contribution.

Activity 1 — Cryptographic service mapping

For an enterprise context you know well, identify three places where cryptography is used. For each, determine:

which of the four security services (confidentiality, integrity, authenticity, non-repudiation) the cryptographic control is providing;
which primitives are likely involved (encryption, hashing, MAC, digital signature, key exchange);
where the keys are managed and who can access them;
what would happen if a key were compromised.

The final question is often the most revealing. If you cannot answer it confidently, the enterprise's key management practices may not be adequately understood.

Activity 2 — Failure mode analysis

Choose three of the seven failure modes from Section 6 — for example, weak keys, poor key management, and improper certificate validation — and write a short analysis (300–400 words) of each:

how the failure mode typically occurs in enterprise systems;
what harm follows from it;
what countermeasures are available;
whether the countermeasures are primarily technical or managerial.

Note the balance between technical and managerial countermeasures. Most cryptographic failures are addressed primarily through management discipline, not through better algorithms.

Activity 3 — Preparing for Forum 2

Forum 2 invites you to discuss identity, access control, and Zero Trust. The cryptographic foundations from this lesson underpin much of that discussion: authentication mechanisms rely on cryptography, identity systems rely on cryptographic assertions, and Zero Trust architectures rely on cryptographic guarantees of device and identity trust.

Review the Forum 2 prompts and note where the material from this lesson — particularly around key management, cryptographic failure modes, and cryptographic agility — will strengthen your analysis.

11 Self-check

Answer the questions below before moving to Lesson 2.2. If you cannot answer a question confidently, revisit the corresponding section.

12 Summary

This lesson has established the foundation of cryptographic reasoning. The essential points are:

Cryptography provides four security services. Confidentiality (through encryption), integrity (through hashing and MACs), authenticity (through digital signatures), and non-repudiation (through signatures with trustworthy key management and time-stamping).
Two families of cryptography exist. Symmetric cryptography is fast but requires secure key distribution; asymmetric cryptography solves key distribution but is slower. Real-world systems combine both — asymmetric for trust and key exchange, symmetric for bulk data.
Key management is the operational discipline that determines whether cryptography works. Generation, distribution, storage, use, rotation, revocation, and destruction must all be managed. Failures here are more common and more consequential than failures in algorithms.
Cryptographic systems are built from a small set of primitives. Block ciphers, stream ciphers, hash functions, MACs, key derivation functions, random number generators, key exchange protocols, public-key encryption, and digital signatures. Composition matters, and custom constructions are almost always a warning sign.
Cryptography fails in predictable ways. Weak or predictable keys, poor key management, legacy algorithms, implementation errors, protocol design flaws, improper certificate validation, and lack of cryptographic agility.
Evaluating cryptographic adequacy requires asking the right questions. Where is the key? Who has access? How is it rotated? How would we know if it were compromised? These questions are more revealing than any question about algorithm strength.
Most cryptographic failures are managerial, not mathematical. The countermeasures are primarily about discipline, governance, and process — not about better algorithms.

These ideas underpin the rest of Unit 2. Lesson 2.2 examines symmetric algorithms (DES, Triple DES, AES) and the trade-offs that determine which to select. Lesson 2.3 covers asymmetric algorithms (RSA, ECC, Diffie–Hellman). Lesson 2.4 addresses digital signatures and public key infrastructure — where the cryptographic primitives introduced here are assembled into trust infrastructure. Lessons 2.5–2.7 apply cryptography to identity, access control, and Zero Trust.

Before moving on

Make sure you can name the four cryptographic security services, distinguish symmetric from asymmetric cryptography, explain why key management is the most common failure point, and name at least five of the seven failure modes from Section 6. If you cannot yet do all four, revisit Sections 2, 4, and 6.

Next lesson

Lesson 2.2 — Symmetric Cryptography examines DES, Triple DES, and AES, comparing the algorithms and the criteria for selecting among them in enterprise applications.