在當代的密碼學工程中，有一個非常主流的建議：“GCM 是現(xiàn)代加密的首選，應該優(yōu)先考慮它，而不是像 CBC 這樣的傳統(tǒng)模式。” 這個建議在絕大多數(shù)情況下都很有道理。AES-GCM (Galois/Counter Mode) 憑借其卓越的性能、并行處理能力以及內(nèi)置的認證加密 (AEAD) 特性，確實能提供遠超 CBC (Cipher Block Chaining) 的機密性與完整性保障。

然而，作為在真實世界中構(gòu)建軟件的工程師，我們深知技術(shù)選型并非簡單的“非黑即白”。在某些特定的、帶有約束條件的場景下，我們是否真的只能選擇 GCM？會不會存在一些“灰色地帶”，讓看似“過時”的 CBC 反而成為更務實、更巧妙的解決方案？

在我開發(fā)開源項目 Sdcb.Chats 的過程中，就遇到了這樣一個有趣的場景。這段經(jīng)歷讓我深刻體會到，真正的工程決策，是在深刻理解原理之后，基于具體需求所做的權(quán)衡與取舍（Trade-off）。本文將結(jié)合這段實踐，深入探討 GCM 和 CBC 之間那些不常被提及的選擇考量。

GCM 的光環(huán)：為何它被譽為黃金標準？

在深入探討“特例”之前，我們必須先充分肯定 GCM 的普適優(yōu)勢。簡單回顧一下，GCM 之所以強大，主要在于：

1. 認證加密 (AEAD)：這是 GCM 最核心的優(yōu)勢。它在加密數(shù)據(jù)（提供機密性）的同時，會生成一個認證標簽（Authentication Tag）。這個標簽能保證數(shù)據(jù)在傳輸過程中未被篡改（提供完整性）。任何對密文的修改都會導致標簽驗證失敗，解密操作會直接拋出異常，從根本上杜絕了篡改風險，也讓“填充預言攻擊”等針對 CBC 的攻擊方式成為歷史。
2. 高性能：GCM 的核心是 CTR (Counter) 模式，其加密過程可以被高度并行化。在支持 AES-NI 指令集的現(xiàn)代 CPU 上，GCM 的吞吐量通常遠超需要串行加密的 CBC 模式。
3. 無需填充：作為一種流加密模式，GCM 不需要對明文進行填充（Padding），可以直接處理任意長度的數(shù)據(jù)，代碼實現(xiàn)更簡潔，也避免了與填充相關(guān)的潛在安全問題。

總而言之，當你需要為一個新系統(tǒng)設(shè)計通用的、安全的網(wǎng)絡(luò)通信協(xié)議或數(shù)據(jù)存儲加密時，請毫不猶豫地選擇 AES-GCM。

現(xiàn)實的骨感：當 GCM 的要求與需求沖突

在 Sdcb.Chats 項目中，我遇到了一個需求：將數(shù)據(jù)庫中的自增 int 或 long 類型的 ID，在 API 和前端 URL 中展示為一個看起來隨機、無規(guī)律的標識符，以防止信息泄露（如系統(tǒng)規(guī)模）和惡意猜測。同時，這個標識符最好能保持統(tǒng)一、簡潔的格式。

這看似簡單的需求，卻讓 GCM 的兩個核心要求顯得格外“礙事”。

沖突一：固定的 IV/Nonce 與 GCM 的“災難性”后果

為了保證前端邏輯的穩(wěn)定性（例如，基于 ID 的緩存和狀態(tài)管理），我需要一個確定性的加密：對于同一個輸入的整數(shù) ID，加密后的字符串結(jié)果必須永遠相同。

這意味著，我不能在每次加密時都使用隨機生成的 Nonce (Number used once)。我必須為每種加密目的（如 ChatId, MessageId）使用一個固定的初始向量（IV），或者說，一個固定的 Nonce。

這對于 GCM 來說是絕對禁止的操作。GCM 的安全性基石在于，對于同一個密鑰，Nonce 絕不能重復使用。一旦你用相同的密鑰和 Nonce 加密了不同的明文（哪怕明文之間只有微小的差異，比如連續(xù)的整數(shù) ID 1, 2, 3...），攻擊者就可以通過簡單的計算破解出密鑰流，進而恢復所有明文。

讓我們用代碼直觀地看一下后果。假設(shè)我們使用固定的 Nonce 來加密連續(xù)的整數(shù)：

using System.Security.Cryptography;
using System.Text;

// 假設(shè)我們?yōu)槟硞€加密目的，固定使用一個 Nonce
byte[] key = RandomNumberGenerator.GetBytes(16);
byte[] fixedNonce = RandomNumberGenerator.GetBytes(12);

Console.WriteLine($"Key: {Convert.ToHexString(key)}");
Console.WriteLine($"Fixed Nonce: {Convert.ToHexString(fixedNonce)}\n");

using AesGcm aesGcm = new AesGcm(key, tagSizeInBytes: 16);

for (int id = 1; id <= 5; id++)
{
    byte[] plaintext = BitConverter.GetBytes(id);
    byte[] ciphertext = new byte[plaintext.Length];
    byte[] tag = new byte[16];

    // 每次都使用相同的 Nonce！這是非常危險的！
    aesGcm.Encrypt(fixedNonce, plaintext, ciphertext, tag);

    Console.WriteLine($"ID: {id}, Plaintext: {Convert.ToHexString(plaintext)}");
    Console.WriteLine($"Ciphertext: {Convert.ToHexString(ciphertext)}");
    Console.WriteLine();
}

輸出結(jié)果可能如下：

Key: DE66C08C3C22D646422DD28D9E539912
Fixed Nonce: 23B5E92983623712E943B6DB

ID: 1, Plaintext: 01000000
Ciphertext: 75749629

ID: 2, Plaintext: 02000000
Ciphertext: 76749629

ID: 3, Plaintext: 03000000
Ciphertext: 77749629

ID: 4, Plaintext: 04000000
Ciphertext: 70749629

ID: 5, Plaintext: 05000000
Ciphertext: 71749629

請仔細觀察 Ciphertext！雖然輸入的 Plaintext 只有第一個字節(jié)在變，但輸出的 Ciphertext 也呈現(xiàn)出極其明顯的規(guī)律性（只有第一個字節(jié)在變化）。這完全違背了加密的初衷，攻擊者可以輕易地利用這種模式。

那么，CBC 在這種場景下表現(xiàn)如何呢？

CBC 模式雖然也建議每次使用隨機的 IV，但即使 IV 固定，其“鏈式”的內(nèi)在結(jié)構(gòu)也提供了更好的擴散性。每個明文塊都會與前一個密文塊進行異或，這使得即使輸入數(shù)據(jù)有規(guī)律，輸出的密文塊也會顯得非常混亂。

byte[] key = RandomNumberGenerator.GetBytes(16);
Console.WriteLine($"Key: {Convert.ToHexString(key)}");
using (Aes aes = Aes.Create())
{
    aes.Key = key;
    aes.Mode = CipherMode.CBC;
    aes.Padding = PaddingMode.PKCS7;
    // 使用固定的 IV
    aes.IV = new byte[16]; 

    Console.WriteLine("\n--- Testing CBC with Fixed IV ---\n");
    for (int id = 1; id <= 5; id++)
    {
        byte[] plaintext = BitConverter.GetBytes(id);
        byte[] ciphertext = aes.EncryptCbc(plaintext, aes.IV);

        Console.WriteLine($"ID: {id}, Plaintext: {Convert.ToHexString(plaintext)}");
        // CBC + PKCS7 padding on a 4-byte input results in a 16-byte output
        Console.WriteLine($"Ciphertext: {Convert.ToHexString(ciphertext)}");
        Console.WriteLine();
	}
}

CBC 的輸出結(jié)果：

Key: 2255D210C5397DB4454C73DC190DE821

--- Testing CBC with Fixed IV ---

ID: 1, Plaintext: 01000000
Ciphertext: 595F8EFF602FD258C59BE8F0D94D57ED

ID: 2, Plaintext: 02000000
Ciphertext: B9D180464306DF29EE58EEB2086C2C54

ID: 3, Plaintext: 03000000
Ciphertext: 0332B6765638FF5AEA3D64755AA150B9

ID: 4, Plaintext: 04000000
Ciphertext: C8A67BC6F9E5C479EE77B54ADA5BF553

ID: 5, Plaintext: 05000000
Ciphertext: 42C69ABACAB18B35B2A3A8837EB4C17C

看到了嗎？盡管輸入 ID 是連續(xù)的，并且 IV 是固定的，但輸出的密文看起來完全是隨機和無規(guī)律的，成功地隱藏了原始數(shù)據(jù)的模式。

結(jié)論一：在必須使用固定 IV/Nonce 的確定性加密場景下，CBC 的安全性表現(xiàn)遠優(yōu)于 GCM。

沖突二：輸出長度的限制與 GCM 的“累贅”

我的另一個需求，是將加密后的 ID 能夠方便地表示為一個 Guid。一個標準的 Guid 是一個 16 字節(jié)（128位）的數(shù)據(jù)結(jié)構(gòu)。

這給 GCM 帶來了第二個無法解決的問題。GCM 的輸出負載必然包含三部分：Nonce、認證標簽 (Tag) 和密文。

讓我們算一筆賬。即使我們加密一個僅 4 字節(jié)的 int ID：

• 密文：4 字節(jié)
• Nonce：通常至少 12 字節(jié)
• Tag：通常至少 12 字節(jié)（推薦 16 字節(jié)）

總長度 = 4 + 12 + 12 = 28 字節(jié)。這個長度遠遠超過了 Guid 所能容納的 16 字節(jié)。我們無法在不破壞 GCM 安全模型的前提下，將它的輸出“塞”進一個 Guid 里。

而這，恰恰是 AES-CBC 的“高光時刻”。

AES 本身是一個塊加密算法，其塊大小固定為 16 字節(jié)。當我們使用 CBC 模式配合 PKCS7 填充來加密一個小于 16 字節(jié)的數(shù)據(jù)（比如一個 4 字節(jié)的 int 或 8 字節(jié)的 long）時，算法會自動將其填充到 16 字節(jié)，然后進行加密，最終輸出的密文恰好就是 16 字節(jié)！

這簡直是為 Guid 量身定做的！

byte[] key = RandomNumberGenerator.GetBytes(16);
Console.WriteLine($"Key: {Convert.ToHexString(key)}");

int idToEncrypt = 12345;
byte[] idBytes = BitConverter.GetBytes(idToEncrypt);

byte[] encryptedBytes;
using (Aes aes = System.Security.Cryptography.Aes.Create())
{
    aes.Key = key;
    aes.IV = new byte[16]; // 固定 IV
    aes.Mode = CipherMode.CBC;
    aes.Padding = PaddingMode.PKCS7;
    encryptedBytes = aes.EncryptCbc(idBytes, aes.IV);
}

Console.WriteLine($"Input is {idBytes.Length} bytes.");
Console.WriteLine($"Encrypted output is {encryptedBytes.Length} bytes.");

// 完美轉(zhuǎn)換為 Guid
Guid finalGuid = new Guid(encryptedBytes);
Console.WriteLine($"Final Guid: {finalGuid}");

輸出：

Key: 4B8D859D12AFE340018562C8F70258D5
Input is 4 bytes.
Encrypted output is 16 bytes.
Final Guid: 84a873bb-6bb1-01b1-216c-1fba73400fda

結(jié)論二：當需要將加密結(jié)果限制在固定長度（特別是 16 字節(jié)以適配 Guid）時，AES-CBC 是一個完美且自然的選擇，而 GCM 則完全不適用。

安全性的再思考：我們放棄了什么？

選擇 CBC，意味著我們放棄了 GCM 提供的內(nèi)置完整性驗證。攻擊者理論上可以篡改我們生成的 Guid。

但這在我的場景下是可接受的風險，原因如下：

1. 低碰撞概率：篡改后的 16 字節(jié)數(shù)據(jù)，在解密后，需要恰好能解析為一個有效的、存在于數(shù)據(jù)庫中的整數(shù) ID。這個概率極低。
2. 應用層驗證：即使碰巧解密出了一個有效的 ID，后續(xù)的業(yè)務邏輯和權(quán)限驗證層（例如，驗證當前用戶是否有權(quán)訪問該 ChatId）會成為第二道、也是更堅固的防線。
3. 風險收益不對等：我們場景的核心目標是防止信息泄露和批量掃描，而不是保護像銀行交易那樣的高價值數(shù)據(jù)免于定點攻擊。為了這個目標，犧牲 GCM 的完整性保護，換取確定性加密和固定的 Guid 輸出格式，是一個非常劃算的買賣。

總結(jié)： 務實主義勝于教條主義

通過 Sdcb.Chats 項目的這次實踐，我想分享的核心觀點是：

• AES-GCM 依然是現(xiàn)代加密的首選和黃金標準。 對于絕大多數(shù)需要同時保證機密性和完整性的新應用，你應該毫不猶豫地選擇它。

• 然而，技術(shù)世界沒有“銀彈”。我們不應將“最佳實踐”奉為不可違背的教條。

• 在遇到特殊約束條件時——例如需要確定性加密（固定 IV/Nonce）或?qū)敵鲩L度有嚴格限制（如適配 Guid）——我們應該深入思考，并勇敢地選擇更適合當前場景的工具。

在這種情況下，古老的 AES-CBC 模式，在充分理解其安全邊界并做好應用層風險規(guī)避的前提下，可以煥發(fā)出新的生命力，成為一個更優(yōu)雅、更務實的解決方案。

作為工程師，我們的價值不僅在于知道“什么是最好的”，更在于知道“在何種情況下，什么是最合適的”。

感謝閱讀！希望這篇關(guān)于加密模式權(quán)衡的思考能對您有所啟發(fā)。如果您對這個話題有任何想法，或?qū)?.NET 和 AI 的結(jié)合有興趣，歡迎在下方評論，也歡迎加入我的 .NET騷操作 QQ群：495782587，或者 Sdcb Chats QQ群：498452653，一起交流探索！