COMP 6660 · Enterprise Cybersecurity Symmetric Cryptography

00 Introduction

Lesson 2.1 introduced cryptography's four security services and the distinction between symmetric and asymmetric approaches. This lesson takes the symmetric family in detail.

Symmetric cryptography protects the bulk of enterprise data. Every encrypted disk, encrypted database, encrypted backup, encrypted network connection, and encrypted container image ultimately relies on a symmetric algorithm. The reason is performance: symmetric algorithms are orders of magnitude faster than asymmetric ones, and enterprises process volumes of data that make asymmetric encryption of bulk data infeasible.

The symmetric family is small. Three algorithms matter in practice — DES, Triple DES, and AES — and the selection question is largely settled: AES is the modern standard, Triple DES is legacy, and DES should no longer be used at all. The interesting material is not in comparing the algorithms abstractly but in understanding why the selection question is settled, how legacy algorithms persist in enterprise systems long past their useful life, and how the choice of mode of operation, key length, and key management determines whether symmetric cryptography actually provides the security properties it promises.

This lesson examines each algorithm in turn, then addresses the two topics that matter most for enterprise practice: modes of operation and key length. It closes with criteria for selecting symmetric algorithms and with the patterns of enterprise use — and misuse — that recur across organisations.

01 Learning objectives

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

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

02 What symmetric cryptography is

Symmetric cryptography uses a single key for both encryption and decryption. Sender and receiver must both possess the key, and the security of the communication depends on that key remaining secret. This is the source of both symmetric cryptography's efficiency and its central problem.

Where symmetric cryptography is used

Because it is fast, symmetric cryptography is used wherever bulk data must be protected. In enterprise systems this includes:

• Data at rest. Full-disk encryption on endpoints and servers; database encryption; object-store encryption; backup encryption; archival encryption.
• Session encryption. Once a session key has been negotiated (using asymmetric cryptography), symmetric encryption protects the session data. This is how TLS, SSH, and IPsec protect traffic in bulk.
• Application-level encryption. Encrypted messaging, encrypted file storage, encrypted configuration, and encrypted fields within databases.
• Container and image encryption. Encrypted container images and encrypted configuration data at the platform level.
• Hardware-level encryption. Self-encrypting drives, TPM-based encryption, and secure enclaves.

The key distribution problem

Symmetric cryptography's central limitation is that both parties must share the same secret key, and that key must be delivered securely. In a small system, this is manageable. At enterprise scale — with thousands of users, systems, services, and applications — the problem becomes severe for three reasons:

• Key count grows quadratically. If every pair of communicating parties requires a distinct shared key, an enterprise with N parties needs roughly N²/2 keys. A thousand users would require nearly half a million keys.
• Key distribution must be secure. The channel used to deliver the key cannot itself depend on the key it is delivering. Some other secure mechanism — physical delivery, asymmetric cryptography, or key agreement — must be used.
• Compromise affects both parties. If a symmetric key is compromised, both the sender and the receiver are affected. There is no way to establish which party was responsible for the compromise.

These limitations are why modern systems use asymmetric cryptography for key exchange and symmetric cryptography for data protection. The two families are complementary, not competitive: asymmetric solves the key distribution problem; symmetric handles the volume.

03 DES — the Data Encryption Standard

Design and history

DES was developed in the 1970s by IBM in collaboration with the US National Security Agency and adopted as a federal standard in 1977. It was the first widely deployed symmetric cryptographic standard and formed the basis of commercial cryptography for two decades.

DES is a block cipher with a 64-bit block size and a 56-bit key. It uses a Feistel network — a design that allows encryption and decryption to use the same structure with the key schedule reversed. The design has been publicly scrutinised for decades and has proven robust against all attacks other than brute force against the key space.

Why DES is no longer secure

DES's fundamental weakness is its key length. A 56-bit key space contains approximately 7.2 × 10¹⁶ possible keys. At the time of DES's adoption, this was considered infeasible to search. By the late 1990s, purpose-built hardware could exhaust the key space in hours; today, commodity cloud resources can exhaust it in minutes or less.

DES was officially withdrawn as a federal standard in 2005, and its use in new systems has been discouraged for far longer. It nevertheless persists in legacy systems, particularly in industrial, financial, and government environments where systems may be decades old and costly to replace.

What DES teaches

• Key length matters, and estimates of "sufficient" key length are wrong more often than right. DES's designers believed 56 bits was adequate; it was not, for long.
• Cryptographic standards age. What is secure at one point in time becomes insecure as computing power grows. Systems must be designed with the ability to migrate to stronger algorithms.
• Legacy algorithms persist far past their useful life. DES was known to be weak for at least a decade before its official retirement, yet deployments continued — and in some cases continue today.

04 Triple DES (3DES)

Design and history

Triple DES was developed as a transitional response to the growing weakness of DES. Rather than designing a new algorithm, it applies DES three times with different keys, extending the effective key length without requiring a new design. The most common variant — three-key 3DES — uses a 168-bit key (three 56-bit DES keys).

The approach was effective in extending DES's useful life. Three-key 3DES provides adequate resistance to brute-force attack, and it retained DES's well-understood structure and available implementations. For many enterprises, 3DES was a lower-cost path to stronger encryption than migrating to a new algorithm.

Weaknesses of Triple DES

Three limitations have driven the migration away from 3DES:

• Limited block size. 3DES retains DES's 64-bit block size. In high-volume applications, this creates a practical vulnerability — birthday-bound attacks become feasible when a very large number of blocks is encrypted under the same key. Modern guidance recommends retiring 3DES for this reason even where the key length is adequate.
• Poor performance. Applying DES three times makes 3DES roughly three times slower than DES, and substantially slower than AES. For high-throughput applications, this is a significant operational cost.
• End-of-life status. Standards bodies and major vendors have been retiring 3DES for years. Support is diminishing, and its presence in a system is increasingly a marker of technical debt.

Where Triple DES still appears

In practice, 3DES persists in several contexts:

• Financial systems. In payment networks and ATM infrastructure, 3DES has been widely used. Migration to AES is underway but takes years.
• Legacy enterprise applications. Systems that were built before AES was standard may use 3DES and may not have been updated.
• Hardware security modules and smart cards. Some devices support 3DES for compatibility with legacy systems.
• VPN and protocol compatibility. Some legacy VPN and protocol configurations still negotiate 3DES for backward compatibility, even where it is not the preferred cipher.

The presence of 3DES in an enterprise system is not necessarily a critical vulnerability — three-key 3DES still resists brute-force attack — but it is a signal that the system has not been modernised, and it should be tracked as technical debt with a plan for migration.

05 AES — the Advanced Encryption Standard

Design and history

AES was selected through an open international competition run by NIST between 1997 and 2000. The winning design — Rijndael, developed by Belgian cryptographers Joan Daemen and Vincent Rijmen — was standardised in 2001. The open selection process was a deliberate response to concerns about the closed development of DES and is often cited as a reason for AES's high level of trust.

AES is a block cipher with a 128-bit block size and three possible key lengths: 128, 192, and 256 bits. It uses a substitution-permutation network rather than a Feistel network, which gives it different performance characteristics and different resistance to certain classes of attack. The algorithm's design has been scrutinised for two decades without revealing practical weaknesses.

Key lengths

AES's three key lengths provide different security margins:

For most enterprise applications, AES-128 provides ample security. AES-256 is appropriate where additional margin is required — for high-value data, where regulatory or policy requirements mandate it, or where resistance to future quantum attacks is a design consideration. The performance difference between AES-128 and AES-256 is small in hardware implementations and modest in software.

Why AES is the standard

• Strong design, open selection. The algorithm's design and selection process have been subjected to two decades of public scrutiny.
• Adequate block size. 128-bit blocks avoid the practical weaknesses of 64-bit block ciphers in high-volume applications.
• Flexible key lengths. 128, 192, and 256-bit keys allow selection appropriate to the application and its security requirements.
• Hardware acceleration. Most modern CPUs include AES-NI or equivalent instructions, making AES encryption effectively free in performance terms for many applications.
• Universal implementation. AES is available in every modern cryptographic library, operating system, database, and cloud platform.
• No known practical weaknesses. After two decades of analysis, no practical attack against correctly configured AES has been demonstrated.

06 Modes of operation

A block cipher encrypts one fixed-size block at a time. Most enterprise data is larger than one block. The mode of operation defines how the cipher is applied to data larger than one block — and the choice of mode matters as much as the choice of algorithm.

Why modes matter

A block cipher applied naively — encrypting each block independently with the same key — has serious weaknesses. Identical plaintext blocks produce identical ciphertext blocks, revealing patterns in the underlying data. An attacker who can observe ciphertext can therefore infer information about the plaintext without breaking the algorithm.

Modes of operation address this problem by introducing dependencies between blocks or by generating additional values — initialisation vectors, nonces, or counters — that ensure identical plaintext blocks encrypt differently. The mode is not a detail; it is a critical part of the cryptographic system's security.

Common modes

The key principle: authenticated encryption

The most important development in mode design over the past two decades has been the recognition that encryption alone is insufficient. A ciphertext can be modified in transit without the recipient being able to detect the modification, and in many cases such modifications have been exploited to devastating effect. Padding-oracle attacks against CBC mode are the clearest illustration.

Authenticated encryption addresses this by providing both confidentiality and integrity in a single operation. AES-GCM and AES-CCM are authenticated modes; AES-CBC combined with a separate MAC — applied in the correct order — provides a similar guarantee. Naive AES-CBC without authentication does not.

Modern guidance is unambiguous: use authenticated encryption unless there is a specific reason not to. AES-GCM is the most common choice, supported by every modern platform and library.

Practical pitfalls

• ECB mode. Still encountered in legacy systems and in poorly written new code. Provides no meaningful confidentiality for data larger than one block.
• IV and nonce reuse. CBC's IV and CTR/GCM's nonce must never repeat under the same key. Reuse undermines the security of the mode, sometimes catastrophically.
• Encryption without authentication. Applying CBC or CTR without a MAC leaves the ciphertext malleable. Padding-oracle attacks exploit exactly this weakness.
• Encryption-then-MAC versus MAC-then-encrypt. When combining encryption and authentication, the order matters. Encrypt-then-MAC is the safe construction; MAC-then-encrypt has been a source of vulnerabilities.
• Custom modes. Enterprises sometimes invent "modes" by composing primitives in non-standard ways. This is almost always a warning sign — the standard modes exist for good reason.

07 Key length and security strength

Key length is the most visible measure of cryptographic strength, and it is frequently misunderstood. Longer keys do not always mean stronger security, and choosing excessively long keys can impose costs without benefit.

What key length determines

Key length determines the size of the keyspace — the number of possible keys. For a key of N bits, the keyspace contains 2^N keys. Brute-force attack requires searching the keyspace, and the average search time scales with the size of that space.

Why "longer is better" is a simplification

Three considerations complicate the simple rule that longer keys mean stronger security:

• Block size limits effective strength. 3DES has a 168-bit key but a 64-bit block size. In high-volume applications, the block size — not the key length — becomes the limiting factor, because birthday-bound attacks become feasible when enough blocks are encrypted under one key. This is why modern guidance recommends retiring 3DES despite its long key.
• Implementation quality matters more than key length. A system with AES-256 but a hard-coded key, unauthenticated encryption, or an insecure mode is far weaker than a system with AES-128 correctly implemented. Key length is one of several factors, and rarely the decisive one.
• Diminishing returns. Beyond a certain key length, additional length provides no practical benefit against classical attack. The difference between AES-128 and AES-256 is unlikely to matter against any realistic adversary in the foreseeable future — though AES-256 provides greater margin against future quantum attack.

Choosing key lengths

For most enterprise applications, the following guidance applies:

• AES-128 is adequate for the vast majority of enterprise applications. It is fast, well-supported, and resistant to all known practical attacks.
• AES-256 is appropriate where additional margin is desired — for high-value data, long-lived data, or where regulatory or policy requirements mandate it. Its performance cost is small in modern implementations.
• AES-192 is rarely used in practice but is available where a middle ground is desired.
• DES and 2-key 3DES should not be used. Their key lengths are inadequate.
• 3-key 3DES should be migrated to AES. Its key length is adequate, but its block size is limiting and its support is diminishing.

08 Selecting symmetric algorithms and configurations

Selection is mostly a settled question in the symmetric domain, but the criteria still matter — both for new deployments and for assessing existing ones.

The selection criteria

Selection guidance by use case

09 Symmetric cryptography in the enterprise

Symmetric cryptography is easy to deploy and easy to deploy badly. The following patterns recur across enterprises and are worth recognising.

Common patterns of weakness

• Legacy algorithms in legacy systems. DES or 3DES persisting in systems that have not been modernised. Often present in industrial, financial, or government environments where replacement is costly.
• Unauthenticated encryption. AES-CBC applied without a MAC — or worse, AES-ECB — in applications where integrity protection is needed. Padding-oracle vulnerabilities follow from this pattern.
• Hard-coded keys. Encryption keys embedded in source code, configuration files, container images, or environment variables. Often combined with a single key shared across many systems, expanding the impact of any compromise.
• Key reuse across purposes. The same key used for encryption, authentication, and signing in different contexts. Cryptographic best practice requires distinct keys for distinct purposes.
• Nonce or IV reuse. Initialisation vectors and nonces that repeat under the same key, undermining the mode's security. Common in poorly implemented applications.
• Encryption without key rotation. Data encrypted under a key that has not changed in years or decades, with no clear process for rotation and no plan for migration.
• Provider-managed encryption assumed to be sufficient. Cloud provider default encryption used for sensitive data without considering whether customer-managed keys are more appropriate.

Assessing symmetric cryptographic posture

Assessing an enterprise's symmetric cryptographic posture is mostly an exercise in enumeration and questioning. Useful questions include:

• What algorithms are in use? Identify where DES or 3DES appears and track migration. Confirm AES is used elsewhere.
• What modes are used? Identify ECB usage (should be none) and unauthenticated CBC or CTR usage (should be remediated).
• What key lengths are in use? Confirm AES-128 or AES-256 is deployed for sensitive data. Consider whether AES-256 is warranted by regulatory or policy requirements.
• Where are keys stored? Identify keys in code, in configuration, in environment variables. Confirm the enterprise knows where its keys are and can enumerate them.
• How are keys managed? Assess key generation, distribution, rotation, and revocation. Identify keys that have never been rotated.
• Who has access to keys? Confirm that key access is restricted, logged, and reviewed. Identify any contexts in which unauthorised key access is possible.
• How would the enterprise know if a key were compromised? Assessment of detection capability for key compromise — often absent entirely.
• Is cryptographic agility present? Ability to migrate to a new algorithm or key length without redesign.

10 Key concepts

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

Symmetric cryptography

Encryption using a single shared key for both encryption and decryption. Fast and efficient, used for bulk data protection. The central challenge is secure key distribution.

Block cipher

A cipher that encrypts data in fixed-size blocks (typically 64 or 128 bits). AES and DES are block ciphers. Requires a mode of operation to handle data larger than one block.

Stream cipher

A cipher that encrypts data one bit or byte at a time, typically by combining plaintext with a pseudorandom keystream. ChaCha20 is a modern example. Suited to continuous data and low-latency applications.

DES (Data Encryption Standard)

A 1977 block cipher with a 64-bit block size and a 56-bit key. Deprecated — key length no longer adequate. Historically important, still present in legacy systems.

Triple DES (3DES)

A transitional algorithm that applies DES three times with different keys, extending effective key length to 168 bits. Deprecated — 64-bit block size is limiting, performance is poor, and support is diminishing.

AES (Advanced Encryption Standard)

The modern symmetric encryption standard. 128-bit block size; 128, 192, or 256-bit keys. Recommended for all new deployments. Extensively analysed, hardware-accelerated, universally supported.

Key length

The size of a cryptographic key in bits. Determines the keyspace and therefore the difficulty of brute-force attack. Adequate key length is necessary but not sufficient for security.

Mode of operation

The method by which a block cipher is applied to data larger than one block. Modes include ECB (insecure), CBC, CTR, GCM, and CCM. The mode matters as much as the algorithm.

ECB (Electronic Codebook)

A mode in which each block is encrypted independently. Insecure for data larger than one block — identical plaintext blocks produce identical ciphertext blocks. Should not be used.

CBC (Cipher Block Chaining)

A mode in which each plaintext block is XORed with the previous ciphertext block. Provides confidentiality but not integrity. Requires a unique initialisation vector and, in most applications, a separate MAC.

CTR (Counter mode)

A mode that generates a keystream by encrypting successive counter values. Efficient and parallelisable, but provides no integrity on its own. Requires unique counter values.

GCM (Galois/Counter Mode)

An authenticated encryption mode combining CTR encryption with a Galois-field authentication mechanism. Provides confidentiality and integrity in one operation. Recommended for most modern applications.

Authenticated encryption

Encryption that provides both confidentiality and integrity in a single operation. GCM and CCM are authenticated modes. Contrasts with unauthenticated modes such as CBC and CTR, which require a separate MAC.

Initialisation vector (IV)

A value used in some modes (notably CBC) to ensure that encryption of identical plaintext with the same key produces different ciphertext. Must not repeat under the same key.

Nonce

A value used in some modes (notably CTR and GCM) to ensure uniqueness of keystream generation. Must not repeat under the same key; reuse can catastrophically compromise confidentiality.

Padding-oracle attack

An attack that exploits error messages or timing differences to determine information about the plaintext of an encrypted message. Common against CBC mode without authentication.

Encrypt-then-MAC

A construction in which data is encrypted first, then a MAC is computed over the ciphertext. The safe way to combine encryption and authentication where an authenticated mode is not available.

AES-NI

Hardware instructions present in most modern CPUs for accelerating AES operations. Makes AES encryption effectively free in performance terms for many applications.

11 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.

12 Self-check

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

13 Summary

This lesson has examined symmetric cryptography and the algorithms and configurations that matter in enterprise practice. The essential points are:

• Symmetric cryptography protects the bulk of enterprise data. Fast and efficient, it is used for encryption at rest, session encryption, application-level encryption, and most other contexts where large volumes of data must be protected.
• Its central limitation is key distribution. Both parties must share the same secret key, and delivering that key securely at enterprise scale is a hard problem. This is why asymmetric cryptography exists alongside it.
• DES is deprecated. Its 56-bit key length is no longer adequate. It persists in legacy systems but should be migrated.
• Triple DES is legacy, being retired. Its key length is adequate, but its 64-bit block size is limiting in high-volume applications, and its performance is poor. Migration to AES is the recommended direction.
• AES is the modern standard. 128-bit block size; 128, 192, or 256-bit keys; extensively analysed; hardware-accelerated; universally supported. It should be the default for virtually all enterprise applications.
• Mode of operation matters as much as algorithm choice. ECB is insecure; CBC and CTR provide confidentiality but not integrity; GCM and CCM provide authenticated encryption. Modern guidance is unambiguous: use authenticated encryption unless there is a specific reason not to.
• Key length is necessary but not sufficient. AES-128 is adequate for most applications; AES-256 provides additional margin against quantum attack and where regulatory or policy requires it. Implementation quality matters more than key length in practice.
• Symmetric cryptographic failures follow predictable patterns. Legacy algorithms, unauthenticated encryption, hard-coded keys, key reuse, nonce or IV reuse, no rotation, and mistaken reliance on provider defaults. Recognising these patterns accelerates assessment.

These ideas prepare for Lesson 2.3, which examines asymmetric cryptography — RSA, elliptic-curve cryptography, and Diffie–Hellman — and the role these algorithms play in establishing trust and exchanging keys. Lesson 2.4 then assembles the symmetric and asymmetric primitives into public key infrastructure.