AES 加密模式演進：從 ECB、CBC 到 GCM 的 C# 深度實踐
在當今這個數字化的世界里，數據安全至關重要。無論是網上銀行、即時通訊還是云存儲，我們都依賴于強大的加密技術來保護我們的信息不被竊取或篡改。在這眾多加密技術中，高級加密標準（AES）無疑是現代對稱加密的基石。
AES 本身是一種塊加密算法（Block Cipher），它以固定大小的塊（對于 AES 是 16 字節）來處理數據。但如何安全、高效地加密一整條長于 16 字節的數據呢？這就需要引入 “塊加密模式”（Block Cipher Mode of Operation）。這些模式定義了如何使用塊加密算法來處理任意長度的數據。
本文將帶領大家穿越時空，回顧 AES 塊加密模式從 70 年代至今的發展歷程，主要聚焦于三個關鍵階段：ECB -> CBC -> GCM。我們將深入探討每個階段的優缺點，并通過 C# 代碼示例，直觀地展示它們在實際應用中的工作方式和特性。
70年代：ECB 模式 (Electronic Codebook)
ECB 是最古老、最簡單的塊加密模式。它的工作原理非常直接：將明文數據分成固定大小的塊（AES為16字節），然后使用相同的密鑰對每個塊進行獨立的加密。
優點：
- 簡單：實現非常簡單。
- 可并行化：由于每個塊的加密都是獨立的，因此可以并行處理，加密速度快。
缺點：
- 安全性極低：這是 ECB 模式的致命缺陷。如果明文中存在重復的塊，那么加密后的密文中也會出現相同的重復塊。這會暴露原始數據的模式和結構，使得攻擊者能夠輕易地分析出一些信息。
傳輸方式：
ECB 模式的通信非常簡單。通信雙方只需要提前協商好密鑰（通常通過非對稱加密等帶外方式），要傳輸的數據就是純粹的密文。由于是分塊加密，明文數據在加密前需要被填充（Padding）到塊大小的整數倍。
值得一提的是，ECB 和 CBC 這些經典的塊加密模式，其概念和設計可以追溯到上世紀70年代，最初是為當時的主流加密算法 DES 所設計的。后來，當 AES 在2001年成為新標準后，這些成熟的模式也被自然地沿用到了 AES 上。
C# 實現
在 C# 中，我們可以使用 System.Security.Cryptography.Aes 類來實現 ECB 加密。
using System;
using System.Security.Cryptography;
using System.Text;
public class EcbExample
{
public static byte[] Encrypt(byte[] plainText, byte[] key)
{
using (var aes = Aes.Create())
{
aes.Key = key;
aes.Mode = CipherMode.ECB;
// PKCS7 padding is default and recommended
aes.Padding = PaddingMode.PKCS7;
using (var encryptor = aes.CreateEncryptor(aes.Key, aes.IV)) // IV is ignored in ECB mode
{
return encryptor.TransformFinalBlock(plainText, 0, plainText.Length);
}
}
}
public static byte[] Decrypt(byte[] cipherText, byte[] key)
{
using (var aes = Aes.Create())
{
aes.Key = key;
aes.Mode = CipherMode.ECB;
aes.Padding = PaddingMode.PKCS7;
using (var decryptor = aes.CreateDecryptor(aes.Key, aes.IV)) // IV is ignored in ECB mode
{
return decryptor.TransformFinalBlock(cipherText, 0, cipherText.Length);
}
}
}
}
// --- 測試 ---
byte[] key = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F };
// 兩個相同的塊 "Hello, World! 1" 和 "Hello, World! 1"
byte[] plainText = Encoding.UTF8.GetBytes("Hello, World! 1Hello, World! 1");
byte[] payload = EcbExample.Encrypt(plainText, key);
// 觀察輸出，你會發現加密后的 Base64 字符串中存在重復的片段
Console.WriteLine($"Plain text blocks are identical, notice the repeating pattern in ciphertext:");
Console.WriteLine($"Payload length: {payload.Length}: {Convert.ToBase64String(payload)}");
byte[] decrypted = EcbExample.Decrypt(payload, key);
Console.WriteLine($"Decrypted: {Encoding.UTF8.GetString(decrypted)}");
輸出如下：
Plain text blocks are identical, notice the repeating pattern in ciphertext:
Payload length: 32: 9YDAsBnGsYVSgd6jiGiPMAPy1HYfMI7/noh3zWZ/u3k=
Decrypted: Hello, World! 1Hello, World! 1
ECB 的缺陷：圖像加密演示
為了更直觀地展示 ECB 模式的缺陷，我們用它來加密一張 RGB24 格式的位圖。我們將使用 OpenCvSharp4 庫來處理圖像數據。
注意： 此代碼需要安裝 OpenCvSharp4/OpenCvSharp4.runtime.win等 NuGet 包。
using OpenCvSharp4;
public static class EcbBitmapDemo
{
public static void DemonstrateFlaw(byte[] imageBytes, byte[] key)
{
using (var originalBitmap = Cv2.ImDecode(imageBytes, ImreadModes.Color))
{
// 獲取像素的原始字節數據
byte[] pixelData = originalBitmap.AsSpan<byte>().ToArray();
// 使用ECB模式加密像素數據
// 注意：為了演示，我們只加密像素數據，文件頭等元數據保持不變
// 這也是為什么加密后文件仍能被識別為圖片
byte[] encryptedPixelData = EcbExample.Encrypt(pixelData, key);
// 創建一個新的位圖來存放加密后的數據
using (var encryptedBitmap = new Mat(originalBitmap.Rows, originalBitmap.Cols, originalBitmap.Type()))
{
// 因為PKCS7填充可能會增加數據長度，而我們為了可視化，只需將加密后與原始圖像等長的數據寫回即可
Marshal.Copy(encryptedPixelData[..encryptedBitmap.AsSpan<byte>().Length], 0, encryptedBitmap.Data, encryptedBitmap.AsSpan<byte>().Length);
// 保存加密后的圖像
Cv2.ImWrite("encrypted_image.png", encryptedBitmap);
}
}
}
}
// 調用
using HttpClient http = new();
byte[] imageBytes = await http.GetByteArrayAsync("https://cv-public.sdcb.pub/2025/qq-qrcode-dotnet666.jpg");
EcbBitmapDemo.DemonstrateFlaw(imageBytes, key);
// 此時查看輸出的 `encrypted_image.png` 文件，你會發現圖像的顏色變得混亂，但原始圖像的輪廓依然清晰可見。
當您使用一張類似下面的圖片進行加密時：
結果輸出如下：
你會驚奇地發現，盡管圖像的顏色變得混亂，但原始圖像的輪廓，包括二維碼、甚至文字等圖案依然清晰可見！這是因為圖像中大面積的相同顏色（例如背景的白色）被加密成了相同的密文塊，從而暴露了原始數據的結構。這在現實世界的應用中是絕對不能接受的。
70年代末：CBC 模式 (Cipher Block Chaining)
為了解決 ECB 模式的安全問題，CBC 模式應運而生。它引入了一個名為**初始向量（Initialization Vector, IV）**的概念。
在 CBC 模式中，每個明文塊在加密前，都會先與前一個密文塊進行異或（XOR）操作。對于第一個明文塊，由于沒有“前一個密文塊”，它會與 IV 進行異或操作。
$C_i = E_K(P_i \oplus C_{i-1})$
$C_0 = E_K(P_0 \oplus IV)$
優點：
- 安全性高：通過引入 IV 和鏈式操作，即使明文塊相同，產生的密文塊也不同，成功掩蓋了原文的模式。
- 廣泛應用：是 TLS 1.2 等許多協議中長期使用的標準模式。
缺點：
- 加密過程無法并行：由于每個塊的加密都依賴于前一個塊的加密結果，因此加密過程是串行的，在需要高吞吐量的場景下性能受限。
- 解密過程可以并行：值得注意的是，解密過程（$P_i = D_K(C_i) \oplus C_{i-1}$）是可以并行的，因為解密每個塊只需要當前密文塊和前一個密文塊。
- 容易受到填充預言攻擊（Padding Oracle Attack）：雖然 CBC 本身是安全的，但如果實現不當（例如，泄露了關于填充是否正確的錯誤信息），它可能會受到此類攻擊。
傳輸方式：
CBC 模式下，傳輸的數據需要包含 IV 和密文。IV 是公開的，不需要保密，但必須是隨機且每次加密都不同的。通常的做法是將 IV 放置在密文的前面一起傳輸。
C# 實現
public class CbcExample
{
public static byte[] Encrypt(byte[] plainText, byte[] key)
{
using (var aes = Aes.Create())
{
aes.Key = key;
aes.Mode = CipherMode.CBC; // 設置為 CBC 模式
aes.Padding = PaddingMode.PKCS7;
// Aes.Create() 會自動生成一個隨機的 IV
byte[] iv = aes.IV;
using (var encryptor = aes.CreateEncryptor(aes.Key, aes.IV))
{
byte[] cipherText = encryptor.TransformFinalBlock(plainText, 0, plainText.Length);
// 將 IV 和密文拼接在一起傳輸
byte[] result = new byte[iv.Length + cipherText.Length];
Buffer.BlockCopy(iv, 0, result, 0, iv.Length);
Buffer.BlockCopy(cipherText, 0, result, iv.Length, cipherText.Length);
return result;
}
}
}
public static byte[] Decrypt(byte[] cipherTextWithIv, byte[] key)
{
using (var aes = Aes.Create())
{
aes.Key = key;
aes.Mode = CipherMode.CBC;
aes.Padding = PaddingMode.PKCS7;
// 從傳輸的數據中提取 IV
byte[] iv = new byte[aes.BlockSize / 8];
Buffer.BlockCopy(cipherTextWithIv, 0, iv, 0, iv.Length);
// 提取真正的密文
byte[] cipherText = new byte[cipherTextWithIv.Length - iv.Length];
Buffer.BlockCopy(cipherTextWithIv, iv.Length, cipherText, 0, cipherText.Length);
aes.IV = iv;
using (var decryptor = aes.CreateDecryptor(aes.Key, aes.IV))
{
return decryptor.TransformFinalBlock(cipherText, 0, cipherText.Length);
}
}
}
}
// --- 測試 ---
byte[] keyCbc = new byte[] { 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1A, 0x1B, 0x1C, 0x1D, 0x1E, 0x1F };
byte[] payloadCbc = CbcExample.Encrypt(Encoding.UTF8.GetBytes("Hello, World!"), keyCbc);
// payload 是 IV + 密文
Console.WriteLine($"--- CBC Example ---");
Console.WriteLine($"Payload (IV+Cipher) length: {payloadCbc.Length}: {Convert.ToBase64String(payloadCbc)}");
byte[] decryptedCbc = CbcExample.Decrypt(payloadCbc, keyCbc);
Console.WriteLine($"Decrypted: {Encoding.UTF8.GetString(decryptedCbc)}");
輸出如下：
--- CBC Example ---
Payload (IV+Cipher) length: 32: 065/eNjJAgk87D2EDs/VQy7nKIME2zDXZBivs6W2/c4=
Decrypted: Hello, World!
2007年：GCM 模式 (Galois/Counter Mode)
隨著對性能和安全性的要求越來越高，CTR 和 GCM 模式應運而生。
CTR (Counter) 模式 是 GCM 的前身。它將塊加密算法（如AES）轉換成了一個流加密算法。它通過加密一個遞增的“計數器”來生成一個密鑰流，然后將這個密鑰流與明文進行異或操作得到密文。由于每個計數器的加密都是獨立的，CTR 模式完全可以并行化，性能極高。
GCM (Galois/Counter Mode) 則是 CTR 模式的“究極進化版”。它是一種認證加密（Authenticated Encryption, AE）模式，更準確地說是帶有關聯數據的認證加密（Authenticated Encryption with Associated Data, AEAD）。
GCM 模式 = CTR 模式加密 (提供機密性) + GMAC (提供完整性驗證)
優點：
- 高性能：與 CTR 模式一樣，GCM 的加解密過程都可以完全并行化，通常比 CBC 快得多，尤其是在有硬件加速支持的現代 CPU 上。
- 同時提供機密性和完整性：GCM 在加密的同時會生成一個認證標簽（Authentication Tag）。接收方在解密時，不僅需要密鑰和 Nonce，還需要這個 Tag。如果密文或“關聯數據”（如不加密的元數據）在傳輸過程中被篡改，Tag 驗證就會失敗，解密操作會直接拋出異常。這從根本上解決了 CBC 模式可能被篡改的問題。
- 流式處理：作為流加密模式，GCM 不需要對明文進行填充（Padding），可以處理任意長度的數據。
缺點：
- 實現復雜：GCM 的內部實現比 CBC 復雜得多。
- Nonce 復用是災難性的：與 IV 類似，GCM 使用一個稱為 Nonce（Number used once）的值。Nonce 必須保證對于同一個密鑰永遠不重復使用。一旦 Nonce 被復用，會導致災難性的安全后果，攻擊者可以恢復出明文。Nonce 通常為 12 字節。
傳輸方式:
GCM 模式下，傳輸的數據通常包含 Nonce、認證標簽 (Tag) 和密文。這三者都是公開的，接收方需要全部這三樣東西以及共享密鑰才能成功解密和驗證。
C# 實現
從 .NET Core 3.0 開始，C# 提供了 System.Security.Cryptography.AesGcm 類來原生支持 GCM 模式。
using System.Security.Cryptography;
public class GcmExample
{
private const int NonceSize = 12; // 96 bits, a standard nonce size for GCM
private const int TagSize = 16; // 128 bits, a standard tag size for GCM
public static byte[] Encrypt(byte[] plainText, byte[] key)
{
// Nonce must be random and unique for each encryption with the same key
byte[] nonce = new byte[NonceSize];
RandomNumberGenerator.Fill(nonce);
byte[] tag = new byte[TagSize];
byte[] cipherText = new byte[plainText.Length];
using (var aesGcm = new AesGcm(key, TagSize))
{
aesGcm.Encrypt(nonce, plainText, cipherText, tag);
}
// For transmission, we concatenate nonce, tag, and ciphertext
byte[] result = new byte[nonce.Length + tag.Length + cipherText.Length];
Buffer.BlockCopy(nonce, 0, result, 0, nonce.Length);
Buffer.BlockCopy(tag, 0, result, nonce.Length, tag.Length);
Buffer.BlockCopy(cipherText, 0, result, nonce.Length + tag.Length, cipherText.Length);
return result;
}
public static byte[] Decrypt(byte[] cipherTextWithNonceAndTag, byte[] key)
{
byte[] nonce = new byte[NonceSize];
byte[] tag = new byte[TagSize];
byte[] cipherText = new byte[cipherTextWithNonceAndTag.Length - NonceSize - TagSize];
// Extract nonce, tag, and ciphertext from the payload
Buffer.BlockCopy(cipherTextWithNonceAndTag, 0, nonce, 0, nonce.Length);
Buffer.BlockCopy(cipherTextWithNonceAndTag, nonce.Length, tag, 0, tag.Length);
Buffer.BlockCopy(cipherTextWithNonceAndTag, nonce.Length + tag.Length, cipherText, 0, cipherText.Length);
byte[] decryptedData = new byte[cipherText.Length];
using (var aesGcm = new AesGcm(key, TagSize))
{
// Decrypt will throw AuthenticationTagMismatchException if the tag is invalid
aesGcm.Decrypt(nonce, cipherText, tag, decryptedData);
}
return decryptedData;
}
}
// --- 測試 ---
byte[] keyGcm = new byte[] { 0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2A, 0x2B, 0x2C, 0x2D, 0x2E, 0x2F };
byte[] payloadGcm = GcmExample.Encrypt(Encoding.UTF8.GetBytes("Hello, World!"), keyGcm);
// payload 是 Nonce + Tag + 密文
Console.WriteLine($"\n--- GCM Example ---");
Console.WriteLine($"Payload (Nonce+Tag+Cipher) length: {payloadGcm.Length}: {Convert.ToBase64String(payloadGcm)}");
byte[] decryptedGcm = GcmExample.Decrypt(payloadGcm, keyGcm);
Console.WriteLine($"Decrypted: {Encoding.UTF8.GetString(decryptedGcm)}");
輸出如下：
--- GCM Example ---
Payload (Nonce+Tag+Cipher) length: 41: mPSeXCj9iJYwUZ3RCAxbAFHVKPB5/POWtI/+Fx5dIRb1nlsPWwWX8kg=
Decrypted: Hello, World!
你可能想問，為什么長度是41呢？讓我們算一算：
- Nonce: 12字節
- Tag: 16字節
- Ciphertext: 13字節（"Hello, World!"）
- 總長度: 12 + 16 + 13 = 41字節剛剛好，是這樣來的，GCM不需要做任何填充。
完整性驗證：CBC vs GCM
GCM 最重要的特性之一就是內置的完整性驗證。如果密文在傳輸中被篡改，GCM 會立即發現并拒絕解密。而 CBC 模式則無法做到這一點，它會“成功”解密，但得到一堆亂碼，應用程序需要自己去判斷解密后的數據是否有效（比如，通過檢查 JSON 反序列化是否成功）。
讓我們來演示一下：
public static void TamperingDemo()
{
Console.WriteLine("--- Tampering Demonstration ---");
byte[] key = new byte[16];
RandomNumberGenerator.Fill(key);
// 1. 使用更長的明文，確保至少有兩個密文塊
byte[] plainText = Encoding.UTF8.GetBytes("This is a much longer secret message to demonstrate the vulnerability!");
// --- CBC Tampering ---
Console.WriteLine("\nTesting CBC tampering...");
byte[] cbcPayload = CbcExample.Encrypt(plainText, key);
Console.WriteLine($"Original CBC payload length: {cbcPayload.Length} bytes.");
// IV (16 bytes) + Ciphertext Block 1 (16 bytes) + ...
// 我們篡改第一個密文塊的第一個字節。
// IV 在 payload 的索引 0-15，所以第一個密文塊從索引 16 開始。
int tamperIndex = 16;
Console.WriteLine($"Tampering byte at index {tamperIndex}...");
cbcPayload[tamperIndex] ^= 0xFF; // Flip the bits of this byte
try
{
byte[] decryptedCbc = CbcExample.Decrypt(cbcPayload, key);
Console.WriteLine("CBC Decryption SUCCEEDED (but data is corrupt):");
Console.WriteLine($"Corrupted data: {Encoding.UTF8.GetString(decryptedCbc)}");
}
catch (CryptographicException e)
{
// 這次不應該會觸發這個異常
Console.WriteLine($"CBC Decryption failed unexpectedly with an exception: {e.Message}");
}
// --- GCM Tampering ---
Console.WriteLine("\nTesting GCM tampering...");
byte[] gcmPayload = GcmExample.Encrypt(plainText, key);
// 同樣篡改一個非末尾的字節
gcmPayload[tamperIndex] ^= 0xFF; // Flip the bits of a ciphertext byte
try
{
byte[] decryptedGcm = GcmExample.Decrypt(gcmPayload, key);
// This line will NOT be reached
Console.WriteLine("GCM Decryption SUCCEEDED. This should not happen!");
}
catch (System.Security.Cryptography.AuthenticationTagMismatchException) // 更具體的異常類型
{
Console.WriteLine("GCM Decryption FAILED as expected due to tag mismatch!");
}
}
// --- 測試 ---
// TamperingDemo();
輸出結果：
--- Tampering Demonstration ---
Testing CBC tampering...
Original CBC payload length: 96 bytes.
Tampering byte at index 16...
CBC Decryption SUCCEEDED (but data is corrupt):
Corrupted data: ?NL?R? 17?+?\??%?nger secret message to demonstrate the vulnerability!
Testing GCM tampering...
GCM Decryption FAILED as expected due to tag mismatch!
這個演示清晰地表明：如果不用 GCM，服務器會成功解密被篡改的數據，只是解密后的內容是錯誤的。而 GCM 則能在解密階段就直接通過認證標簽驗證失敗來阻止這一切，為應用層提供了一道堅固的安全屏障。
性能對比：CBC vs GCM
為了展示 GCM 在性能上的優勢，我們使用強大的 BenchmarkDotNet 庫來進行一次基準測試。
注意： 此代碼需要安裝 BenchmarkDotNet NuGet 包。
using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;
[MemoryDiagnoser]
public class CryptoBenchmarks
{
private byte[] _key;
private byte[] _data;
[Params(1024, 1024 * 1024)] // Test with 1KB and 1MB and 10MB of data
public int DataSize;
[GlobalSetup]
public void Setup()
{
_key = new byte[16];
RandomNumberGenerator.Fill(_key);
_data = new byte[DataSize];
RandomNumberGenerator.Fill(_data);
}
[Benchmark(Baseline = true)]
public byte[] CbcRoundtrip()
{
byte[] encrypted = CbcExample.Encrypt(_data, _key);
return CbcExample.Decrypt(encrypted, _key);
}
[Benchmark]
public byte[] GcmRoundtrip()
{
byte[] encrypted = GcmExample.Encrypt(_data, _key);
return GcmExample.Decrypt(encrypted, _key);
}
}
// --- 運行測試 ---
// var summary = BenchmarkRunner.Run<CryptoBenchmarks>();
典型的基準測試結果：
| Method | DataSize | Mean | Error | StdDev | Ratio | RatioSD | Gen0 | Gen1 | Gen2 | Allocated | Alloc Ratio |
|---|---|---|---|---|---|---|---|---|---|---|---|
| CbcRoundtrip | 1024 | 3.242 μs | 0.0278 μs | 0.0260 μs | 1.00 | 0.01 | 0.6752 | - | - | 5.52 KB | 1.00 |
| GcmRoundtrip | 1024 | 2.410 μs | 0.0280 μs | 0.0248 μs | 0.74 | 0.01 | 0.5379 | - | - | 4.42 KB | 0.80 |
| CbcRoundtrip | 1048576 | 1,408.722 μs | 20.4198 μs | 18.1016 μs | 1.00 | 0.02 | 496.0938 | 496.0938 | 496.0938 | 4103.41 KB | 1.00 |
| GcmRoundtrip | 1048576 | 1,212.838 μs | 23.8959 μs | 23.4690 μs | 0.86 | 0.02 | 513.6719 | 513.6719 | 513.6719 | 4102.72 KB | 1.00 |
| CbcRoundtrip | 10485760 | 18,785.008 μs | 205.7381 μs | 171.8006 μs | 1.00 | 0.01 | 437.5000 | 437.5000 | 437.5000 | 40963.87 KB | 1.00 |
| GcmRoundtrip | 10485760 | 14,657.252 μs | 144.8966 μs | 135.5364 μs | 0.78 | 0.01 | 578.1250 | 578.1250 | 578.1250 | 40964.77 KB | 1.00 |
從基準測試結果中，我們可以得出以下核心結論：
- GCM 性能全面領先：在所有測試的數據規模下（1KB, 1MB, 10MB），GCM 模式的加密解密總耗時均優于 CBC 模式。
- 量化優勢：根據測試數據，GCM 的速度比 CBC 快約 14% 到 26%。例如，在處理 1MB 數據時，GCM 的耗時大約是 CBC 的 86%（Ratio = 0.86），處理 10MB 數據時優勢擴大到 22%（Ratio = 0.78）。
- 性能優勢來源：這種性能差異主要源于算法的并行特性。雖然現代 CPU 的 AES-NI 硬件指令集同時加速了 CBC 和 GCM 的底層AES加密操作，但 GCM 的 CTR 核心使其加解密過程可以被高度并行化，從而獲得了超越 CBC 串行加密的額外性能提升。
其它冷門的模式
除了主流的 ECB、CBC、GCM 外，還有一些其它模式：
- CFB (Cipher Feedback)：類似于 CBC，也將塊加密器轉換為流加密器。它將前一個密文塊加密后的結果與當前明文塊異或來生成當前密文塊。與 CBC 類似，加密無法并行。
- OFB (Output Feedback)：它通過反復加密 IV 來生成一個與明文獨立的密鑰流，然后與明文異或。它也是一個流加密模式，但與 CFB/CBC 不同，它對傳輸錯誤不敏感（一個比特的錯誤只影響一個比特），但也因此容易受到惡意篡改。
這些模式現在已經較少使用，因為 GCM 提供了更好的性能和內置的安全性。
總結
我們一起回顧了 AES 塊加密模式從簡單到復雜，從只關注機密性到兼顧性能與完整性的演進之路：
- ECB：最簡單的模式，因安全性問題基本被淘汰，只適用于極少數特殊場景。
- CBC：通過引入 IV 和鏈式操作解決了 ECB 的問題，成為了很長一段時間的行業標準，但存在加密串行和無內置完整性驗證的缺點。
- GCM：現代加密的黃金標準。它結合了 CTR 模式的高性能和并行化能力，并加入了 GMAC 認證，同時提供了數據的機密性、完整性和真實性，是目前構建新系統時的首選。
這條發展路徑清晰地展示了密碼學在應對不斷變化的安全威脅和性能需求時，是如何持續創新和完善的。作為開發者，理解這些模式的特性和適用場景，是構建安全、可靠系統的基礎。
感謝閱讀到這里，如果感覺本文對您有幫助，請不吝評論和點贊，這也是我持續創作的動力！
也歡迎加入我的 .NET騷操作 QQ群：495782587，一起交流 .NET 和 AI 的各種有趣玩法！
浙公網安備 33010602011771號