AES-CFB128流式加密实战：C++与OpenSSL实现大文件与网络流处理

1. 项目概述：为什么CFB128模式值得你投入时间？

如果你在C++项目中处理过AES加密，大概率用过ECB或CBC模式。ECB简单直接，但安全性堪忧，相同的明文块会得到相同的密文块，像一张未经打乱的像素图。CBC引入了初始化向量（IV）和链式反馈，安全性大幅提升，成为许多场景下的默认选择。但当你需要处理一个10GB的日志文件，或者一个来自网络的实时视频流，要求边读边加密、边解密边播放时，CBC的“块处理”特性就让你犯了难——你必须等待凑齐一个完整的16字节AES块才能开始工作。这时，一个常被忽略但极其强大的模式就该登场了：CFB（Cipher Feedback）模式，特别是我们今天要实战的CFB128。

别再只把AES的知识停留在ECB和CBC了。CFB128模式本质上是一种将分组密码（如AES）转换为自同步流密码的方法。它允许你以字节（甚至比特）为单位进行加密和解密，完美契合“流式”处理的需求。想象一下，你有一个持续写入的管道（pipe），或者一个需要即时加密并发送的TCP数据包，CFB128可以让你像操作普通数据流一样操作加密流，无需关心块边界。本次实战，我们将彻底抛弃对文件整体读入内存再加密的“笨重”做法，使用C++和OpenSSL库，实现一个真正高效、内存友好的流式文件加密解密工具。无论你是处理大文件、网络流，还是构建需要实时加解密的系统服务，掌握CFB128都将为你打开一扇新的大门。

2. 核心原理：CFB128如何将块密码“变成”流密码？

要玩转CFB128，必须理解其内核工作原理，否则配置参数时就会一头雾水。我们把它拆解开来，对照更熟悉的CBC模式，你会看得更清楚。

2.1 CFB128的基本工作流程

CFB模式有一个核心寄存器，通常初始化为初始化向量（IV）。在CFB128中（对应AES-128/192/256），这个寄存器的大小正好是一个AES块，即128位（16字节）。加密过程可以概括为以下几步：

1. 初始化：将IV放入移位寄存器。
2. 加密寄存器：使用AES密钥加密这个寄存器中的内容，得到一个“密钥流块”。
3. 处理明文：取明文的下一个字节（或比特，CFB128通常以字节为单位），与“密钥流块”的第一个字节进行异或（XOR）操作，得到密文的第一个字节。
4. 移位反馈：这是CFB的“Feedback”精髓。将密文字节（注意，是刚产生的密文，不是明文）反馈到寄存器的末尾，同时将寄存器最前端的一个字节移出。整个寄存器向左移位一个字节，为新一轮操作做准备。
5. 循环：重复步骤2-4，直到所有明文处理完毕。

解密过程与之完全对称，唯一的区别在于第三步：将接收到的密文字节与“密钥流块”的第一个字节进行异或，得到明文字节。随后，同样是将这个接收到的密文字节（而非解密出的明文）反馈到寄存器中。这意味着加密和解密方必须使用完全相同的IV和密钥，并且保持寄存器状态同步。

2.2 与CBC模式的本质区别

理解差异能帮你做出正确选择：

注意：CFB模式有多种变体，如CFB1、CFB8、CFB128。数字代表每次移入反馈寄存器的比特数。CFB128即一次反馈128比特（16字节），但每次仍只加密/解密1字节（如果配置为8位反馈）。OpenSSL中通常使用CFB128，它提供了字节粒度的操作便利性。不要被“128”迷惑，它指的是寄存器大小和一次加密的密钥流长度，不代表每次处理的数据量。

2.3 OpenSSL中的CFB实现要点

在OpenSSL的EVP_*高级接口中，使用CFB模式时，你需要明确两个关键点：

1. IV是必须的，且长度必须等于分组长度（AES是16字节）。它的保密性要求没有密钥高，但必须不可预测，通常随机生成。
2. 不需要设置填充。在初始化上下文EVP_CipherInit_ex时，应将填充参数设置为0。如果错误地启用了填充，OpenSSL可能会在最终EVP_CipherFinal_ex调用时因为数据长度不是块长度的整数倍而报错。

3. 环境准备与OpenSSL集成

工欲善其事，必先利其器。我们的实战基于C++和OpenSSL库。确保你的开发环境已经就绪。

3.1 OpenSSL库的安装与链接

如果你在Linux/macOS上，通常可以通过包管理器安装开发包：

# Ubuntu/Debian sudo apt-get install libssl-dev # CentOS/RHEL sudo yum install openssl-devel # macOS (使用Homebrew) brew install openssl

在Windows上，可以从OpenSSL官网下载预编译库，或者使用vcpkg等包管理器安装。

在你的C++项目中，需要正确链接OpenSSL的加密库（libcrypto）。以CMake为例，一个简单的CMakeLists.txt配置如下：

cmake_minimum_required(VERSION 3.10) project(AES_CFB128_Stream) set(CMAKE_CXX_STANDARD 11) # 查找OpenSSL库 find_package(OpenSSL REQUIRED) add_executable(aes_cfb_stream main.cpp) # 链接OpenSSL的Crypto库 target_link_libraries(aes_cfb_stream OpenSSL::Crypto)

3.2 核心头文件与命名空间

在代码中，你需要包含以下关键头文件：

#include <openssl/evp.h> // 用于EVP高级加密接口 #include <openssl/err.h> // 用于错误处理 #include <openssl/rand.h> // 用于生成随机IV #include <iostream> #include <fstream> #include <vector> #include <cstring>

使用EVP接口是OpenSSL推荐的现代方式，它抽象了具体的算法，提供了统一的加解密、摘要生成等操作接口，比直接使用AES_*系列低级函数更安全、更易用。

实操心得：务必在程序开始时初始化OpenSSL的错误字符串。在调试时，这能救命。在main函数开头调用ERR_load_crypto_strings();和OpenSSL_add_all_algorithms();（较新版本可能自动初始化，但显式调用更稳妥）。这样，当调用ERR_error_string(ERR_get_error(), nullptr)时，你能看到人类可读的错误信息，而不是一个错误码。

4. 实战：流式加密解密文件的核心实现

理论说得再多，不如一行代码。我们现在来构建一个完整的、支持大文件的流式加密解密类。核心思想是：使用固定大小的缓冲区，循环读取文件块，通过EVP接口的EVP_CipherUpdate进行“流式”处理。

4.1 核心类设计与初始化

我们设计一个AES_CFB_Stream类，封装加密和解密操作。

class AES_CFB_Stream { public: enum class Mode { ENCRYPT, DECRYPT }; AES_CFB_Stream(Mode mode, const std::vector<unsigned char>& key, const std::vector<unsigned char>& iv); ~AES_CFB_Stream(); bool processFile(const std::string& inputFilePath, const std::string& outputFilePath); // 也可以添加 processBuffer 方法用于处理内存数据流 private: bool initCipher(); EVP_CIPHER_CTX* m_ctx; Mode m_mode; std::vector<unsigned char> m_key; std::vector<unsigned char> m_iv; static const size_t BUFFER_SIZE = 4096; // 4KB缓冲区，可根据磁盘IO特性调整 };

构造函数负责保存参数，initCipher完成EVP上下文的初始化和参数设置。

AES_CFB_Stream::AES_CFB_Stream(Mode mode, const std::vector<unsigned char>& key, const std::vector<unsigned char>& iv) : m_mode(mode), m_key(key), m_iv(iv), m_ctx(nullptr) { // 基本参数校验 if (m_key.size() != 16 && m_key.size() != 24 && m_key.size() != 32) { throw std::invalid_argument("Key must be 16, 24, or 32 bytes for AES-128, -192, or -256."); } if (m_iv.size() != 16) { // AES块大小是16字节 throw std::invalid_argument("IV must be exactly 16 bytes for AES."); } m_ctx = EVP_CIPHER_CTX_new(); if (!m_ctx) { throw std::runtime_error("Failed to create EVP_CIPHER_CTX."); } if (!initCipher()) { EVP_CIPHER_CTX_free(m_ctx); throw std::runtime_error("Failed to initialize cipher."); } } AES_CFB_Stream::~AES_CFB_Stream() { if (m_ctx) { EVP_CIPHER_CTX_free(m_ctx); } }

4.2 密码上下文初始化：选择正确的算法与模式

initCipher函数是整个加密解密的灵魂，这里的选择直接影响行为。

bool AES_CFB_Stream::initCipher() { const EVP_CIPHER* cipher = nullptr; // 根据密钥长度选择具体的AES算法 switch (m_key.size()) { case 16: cipher = EVP_aes_128_cfb128(); break; case 24: cipher = EVP_aes_192_cfb128(); break; case 32: cipher = EVP_aes_256_cfb128(); break; default: return false; // 理论上不会走到这里，因为构造函数已校验 } // 初始化操作：1表示加密，0表示解密 int init_result = EVP_CipherInit_ex(m_ctx, cipher, nullptr, m_key.data(), m_iv.data(), (m_mode == Mode::ENCRYPT) ? 1 : 0); if (init_result != 1) return false; // **关键步骤：禁用填充！CFB模式不需要填充。** EVP_CIPHER_CTX_set_padding(m_ctx, 0); return true; }

注意事项：EVP_aes_*_cfb128()这个函数名可能有点误导。它确实代表CFB模式，且反馈寄存器大小为128位，但默认情况下，它每次处理**8位（1字节）**的CFB。OpenSSL也提供了EVP_aes_*_cfb8()和EVP_aes_*_cfb1()，但cfb128是字节操作最常用的。如果你需要一次处理多于一个字节（例如一个int），你需要多次调用Update，或者使用EVP_Cipher的“一次调用”特性，但内部仍然是字节处理逻辑。

4.3 流式处理文件的引擎：processFile详解

这是最核心的函数，展示了如何像用水泵抽水一样，一段一段地处理文件。

bool AES_CFB_Stream::processFile(const std::string& inputFilePath, const std::string& outputFilePath) { std::ifstream inFile(inputFilePath, std::ios::binary); std::ofstream outFile(outputFilePath, std::ios::binary); if (!inFile.is_open() || !outFile.is_open()) { std::cerr << "Failed to open input or output file." << std::endl; return false; } std::vector<unsigned char> inBuffer(BUFFER_SIZE); // 输出缓冲区可能需要比输入缓冲区稍大，但CFB模式是流式，输入输出长度1:1。 std::vector<unsigned char> outBuffer(BUFFER_SIZE + EVP_MAX_BLOCK_LENGTH); // 预留一个块的安全空间 int bytesRead = 0; int outLen = 0; while (inFile.good() && !inFile.eof()) { inFile.read(reinterpret_cast<char*>(inBuffer.data()), inBuffer.size()); bytesRead = static_cast<int>(inFile.gcount()); // 实际读取的字节数 if (bytesRead > 0) { // **核心调用：EVP_CipherUpdate** // 它处理`bytesRead`字节的数据，更新内部CFB寄存器状态。 if (EVP_CipherUpdate(m_ctx, outBuffer.data(), &outLen, inBuffer.data(), bytesRead) != 1) { std::cerr << "Error during cipher update." << std::endl; return false; } outFile.write(reinterpret_cast<const char*>(outBuffer.data()), outLen); } } // **关键区别：CFB模式可能不需要Finalize，但调用是安全的** // 对于无填充的流模式，Finalize通常不产生额外输出，但用于清理上下文。 if (EVP_CipherFinal_ex(m_ctx, outBuffer.data(), &outLen) != 1) { // 如果这里出错，很可能是因为错误地启用了填充。 std::cerr << "Error during cipher finalization." << std::endl; return false; } // 如果outLen>0，写入最终数据（在CFB无填充模式下，通常为0） if (outLen > 0) { outFile.write(reinterpret_cast<const char*>(outBuffer.data()), outLen); } inFile.close(); outFile.close(); return true; }

流程解析：

1. 打开文件：以二进制模式打开，防止文本模式对换行符等进行转换。
2. 缓冲区循环：每次从输入文件读取最多BUFFER_SIZE字节到inBuffer。
3. 调用Update：将inBuffer中的数据（长度为bytesRead）送入EVP_CipherUpdate。该函数会立即进行CFB模式的加密或解密，并将结果写入outBuffer，同时输出实际处理的数据长度outLen。对于CFB模式，outLen通常等于输入的bytesRead。
4. 写入输出：将outBuffer中前outLen字节写入输出文件。
5. 循环：直到文件读完。
6. 调用Finalize：即使CFB不需要处理填充，也应当调用EVP_CipherFinal_ex。它会检查上下文状态并完成清理。在无填充模式下，outLen通常为0。如果这一步失败，请回头检查是否误开了填充。

实操心得：缓冲区大小的选择。BUFFER_SIZE的选择是性能与内存的权衡。太小（如128字节）会导致频繁的I/O和EVP调用，增加开销。太大（如1MB）可能不会带来显著的吞吐提升，反而增加单次操作延迟，且占用更多内存。4KB或16KB是常见的选择，因为它与许多文件系统和磁盘的块大小对齐。对于网络流，可能需要更小的缓冲区（如1.5KB，接近MTU）来减少延迟。

5. 密钥与IV的安全生成与管理

加密系统的安全性不仅取决于算法，更取决于密钥管理。IV的生成同样至关重要。

5.1 生成密码学安全的随机数

绝对不要使用rand()或std::random_device（在某些平台上熵不足）来生成密钥或IV。必须使用密码学安全的随机数生成器（CSPRNG）。OpenSSL提供了RAND_bytes函数。

std::vector<unsigned char> generateRandomBytes(size_t length) { std::vector<unsigned char> buffer(length); if (RAND_bytes(buffer.data(), length) != 1) { // RAND_bytes失败可能意味着随机数发生器未正确播种 throw std::runtime_error("Failed to generate cryptographically secure random bytes."); } return buffer; } // 生成一个256位（32字节）的AES密钥和一个128位（16字节）的IV auto key = generateRandomBytes(32); // AES-256 auto iv = generateRandomBytes(16);

5.2 IV的使用与传输

IV不需要保密，但必须不可预测，且对于同一个密钥，每次加密都应使用不同的IV。常见的做法是：

• 随机生成：如上所示，每次加密随机生成一个IV。
• 存储与传输：将IV（16字节）前置于密文文件或数据流中。解密时，先读取前16字节作为IV。
• 固定IV的危险：如果重复使用相同的密钥和IV，CFB模式会变得不安全，攻击者可能分析出部分信息。

一个改进的processFile加密函数可以这样处理IV：

bool encryptFileWithRandomIV(const std::string& plainFile, const std::string& cipherFile, const std::vector<unsigned char>& key) { auto iv = generateRandomBytes(16); AES_CFB_Stream encrypter(AES_CFB_Stream::Mode::ENCRYPT, key, iv); std::ofstream outFile(cipherFile, std::ios::binary); if (!outFile.is_open()) return false; // 1. 先将IV写入密文文件头部 outFile.write(reinterpret_cast<const char*>(iv.data()), iv.size()); outFile.close(); // 先关闭，让processFile重新以追加模式打开？这里设计需优化。 // 更优设计：修改processFile，接受一个已经打开并写入了IV的输出流。 // 或者，将IV作为参数传给processFile，让它自己处理。 // 此处为概念演示，实际项目需要更严谨的流设计。 return encrypter.processFile(plainFile, cipherFile); // 注意，这会覆盖IV，需要调整 }

更健壮的设计是修改processFile，使其接受一个已经定位到正确位置（IV之后）的输出流，或者将IV的读写逻辑整合到类中。

6. 性能优化与高级话题

掌握了基础实现后，我们可以探讨如何让它更快、更稳健。

6.1 多线程与异步I/O

对于超大文件，I/O往往是瓶颈。可以考虑使用异步I/O（如Linux的io_uring）或生产者-消费者模型配合多线程。

• 一个I/O线程：专门负责从文件读取数据块到队列。
• 多个工作线程：从队列取出数据块，使用独立的EVP上下文（但共享密钥和IV？注意CFB状态不能共享！）进行加密。这很棘手，因为CFB是串行的，一个上下文的输出状态依赖于前一个输入。你不能简单地将文件块分给多个线程并行加密。
• 一个I/O线程：将加密后的数据块按顺序写回文件。

因此，CFB模式本身不适合并行加密。如果追求极致性能且场景允许，可以考虑使用CTR（计数器）模式，它本质也是流密码，但可以并行加密/解密。或者，如果文件是静态的，可以使用ECB或CBC模式结合并行处理不同块（CBC加密不行，但解密可以）。

6.2 错误处理与资源清理

我们的示例代码错误处理比较基础。在生产环境中，必须做到：

• 使用RAII管理资源：我们已经用类管理了EVP_CIPHER_CTX。文件句柄也应使用RAII（如std::unique_ptr配合自定义删除器，或确保在异常路径下关闭文件）。
• 详细的错误日志：使用ERR_get_error()和ERR_error_string()获取OpenSSL的错误堆栈信息。
• 内存清零：在密钥和IV等敏感数据使用完毕后，应使用OPENSSL_cleanse()或手动用memset（注意防止编译器优化）清空内存，防止内存残留攻击。

void secureErase(std::vector<unsigned char>& data) { if (!data.empty()) { OPENSSL_cleanse(data.data(), data.size()); } data.clear(); }

6.3 认证加密（AEAD）的考量

CFB模式只提供机密性，不提供完整性（Integrity）和真实性（Authenticity）。攻击者可能篡改密文中的某些字节，导致解密出的明文出现可控的错误（虽然CFB有错误传播，但攻击者可能利用这一点）。在现代安全应用中，推荐使用认证加密模式，如GCM（Galois/Counter Mode）或CCM。这些模式在提供机密性的同时，还会生成一个认证标签（Tag），用于验证密文在传输过程中未被篡改。

如果你的应用场景对完整性有要求，应考虑升级到GCM模式。OpenSSL中对应EVP_aes_*_gcm()。不过GCM的使用比CFB稍复杂，需要处理认证标签。

7. 常见问题与调试技巧实录

在实际开发和调试中，你肯定会遇到各种问题。以下是我踩过的一些坑和解决方法。

7.1 编译链接问题

问题：undefined reference to EVP_CIPHER_CTX_new等链接错误。解决：确保正确链接了libcrypto库。在CMake中，使用target_link_libraries(your_target OpenSSL::Crypto)。在命令行编译时，添加-lcrypto。在Windows的Visual Studio中，正确配置附加依赖项libcrypto.lib和库目录。

7.2 运行时崩溃或异常

问题：程序在EVP_CipherUpdate或EVP_CipherFinal_ex时崩溃。排查：

1. 检查指针：确保传入EVP_CipherUpdate的输入/输出缓冲区指针有效，且输出缓冲区足够大。输出缓冲区大小至少是输入长度 + EVP_MAX_BLOCK_LENGTH，这是一个安全裕量。
2. 检查上下文：确保EVP_CIPHER_CTX已成功创建（EVP_CIPHER_CTX_new返回非空）并正确初始化（EVP_CipherInit_ex返回1）。
3. 检查密钥/IV长度：这是最常见的问题。AES-128密钥必须是16字节，AES-192是24字节，AES-256是32字节。IV必须是16字节。使用std::vector::size()仔细核对。
4. 检查模式匹配：确保加密和解密使用的是相同的模式（EVP_aes_256_cfb128()）、密钥和IV。

7.3 解密结果不正确或乱码

问题：加密后的文件解密出来是乱码。排查步骤：

1. IV一致性：这是CFB/OFB等模式最常见的错误。加密时使用的IV必须原封不动地用于解密。确保解密程序读取的IV与加密时写入的IV完全一致（字节对字节）。
2. 密钥一致性：确认加密和解密使用的是同一个密钥。
3. 操作顺序：确认加密和解密流程完全对称。例如，加密时先写IV再写密文，解密时就要先读IV再读密文。
4. 文件格式：确保文件以二进制模式（std::ios::binary）打开，否则在Windows平台上，\n会被转换成\r\n，破坏数据。
5. 填充问题：如果你在CFB模式下错误地启用了填充，EVP_CipherFinal_ex可能会失败或添加额外字节。确保调用EVP_CIPHER_CTX_set_padding(ctx, 0)。
6. 数据损坏：检查加密后的文件是否在传输或存储过程中被修改。可以计算并对比哈希值（如SHA256）。

7.4 性能瓶颈分析

问题：加密/解密速度很慢。排查：

1. 使用Release模式编译：Debug模式下的优化级别很低，会影响加密这类计算密集型操作。
2. 检查缓冲区大小：使用工具（如iostat,iotop）监控磁盘I/O。如果I/O利用率很低，可能是缓冲区太小，增加BUFFER_SIZE（如从4K到64K）可能提升吞吐。如果CPU是瓶颈，缓冲区大小影响不大。
3. OpenSSL硬件加速：现代OpenSSL会自动利用CPU的AES-NI指令集进行加速。你可以通过openssl speed aes命令测试本机的AES性能。如果速度异常慢，可能是旧版本或编译时未开启硬件加速支持。
4. 算法强度：AES-256比AES-128慢大约40%。如果安全性要求允许，可以考虑使用AES-128。

7.5 内存泄漏检查

虽然我们使用了RAII，但在复杂错误处理路径中仍可能泄漏资源。可以使用Valgrind（Linux）或Visual Studio的内存诊断工具来检查。确保在所有退出路径（包括异常）上，EVP_CIPHER_CTX都被正确释放。

8. 完整示例代码与使用方式

将以上所有部分整合，下面是一个完整的、可编译运行的示例main.cpp。它演示了如何生成随机密钥IV，加密一个文件，然后解密它并验证结果。

#include <openssl/evp.h> #include <openssl/err.h> #include <openssl/rand.h> #include <iostream> #include <fstream> #include <vector> #include <cstring> #include <stdexcept> // ... 此处插入上面定义的 AES_CFB_Stream 类、generateRandomBytes、secureErase 函数 ... int main() { // 初始化OpenSSL ERR_load_crypto_strings(); OpenSSL_add_all_algorithms(); try { // 1. 生成密钥和IV std::cout << "Generating random AES-256 key and IV..." << std::endl; auto key = generateRandomBytes(32); // AES-256 auto iv = generateRandomBytes(16); // 2. 准备测试文件 std::string plainText = "This is a secret message to be encrypted using AES-CFB128 stream mode.\n"; std::string inputFile = "test_plain.txt"; std::string encryptedFile = "test_encrypted.bin"; std::string decryptedFile = "test_decrypted.txt"; { std::ofstream out(inputFile); out << plainText; } // 3. 加密 std::cout << "Encrypting file..." << std::endl; { // 在实际项目中，IV应该保存在密文头部。这里简化演示。 AES_CFB_Stream encrypter(AES_CFB_Stream::Mode::ENCRYPT, key, iv); if (!encrypter.processFile(inputFile, encryptedFile)) { std::cerr << "Encryption failed!" << std::endl; return 1; } } // 4. 解密 (使用相同的key和iv) std::cout << "Decrypting file..." << std::endl; { AES_CFB_Stream decrypter(AES_CFB_Stream::Mode::DECRYPT, key, iv); if (!decrypter.processFile(encryptedFile, decryptedFile)) { std::cerr << "Decryption failed!" << std::endl; return 1; } } // 5. 验证 std::string recoveredText; { std::ifstream in(decryptedFile); recoveredText.assign((std::istreambuf_iterator<char>(in)), std::istreambuf_iterator<char>()); } if (plainText == recoveredText) { std::cout << "SUCCESS: Decrypted text matches original!" << std::endl; } else { std::cout << "FAILURE: Decrypted text does NOT match!" << std::endl; std::cout << "Original: " << plainText << std::endl; std::cout << "Decrypted: " << recoveredText << std::endl; } // 6. 清理敏感数据 secureErase(key); secureErase(iv); // 清理测试文件 (可选) // std::remove(inputFile.c_str()); // std::remove(encryptedFile.c_str()); // std::remove(decryptedFile.c_str()); } catch (const std::exception& ex) { std::cerr << "Error: " << ex.what() << std::endl; // 打印OpenSSL错误堆栈 char errBuf[512]; ERR_error_string_n(ERR_get_error(), errBuf, sizeof(errBuf)); std::cerr << "OpenSSL error: " << errBuf << std::endl; return 1; } // 清理OpenSSL全局状态 EVP_cleanup(); ERR_free_strings(); return 0; }

编译并运行这个程序，你将看到成功加密和解密的输出。这个示例提供了一个坚实的起点，你可以根据实际需求扩展它，例如添加命令行参数解析、处理IV的存储、增加错误恢复机制等。

我个人在实际项目中使用CFB128模式处理过实时传感器数据流，它的“流式”特性让代码非常干净，无需关心数据包的边界，加密层对业务逻辑几乎是透明的。最大的教训就是一定要妥善保管和传递IV，任何一字节的偏差都会导致后续所有数据解密失败。对于新的项目，如果不需要兼容旧系统，我会更倾向于使用GCM模式，它在提供流式加密的同时还解决了完整性问题，算是一步到位。但理解CFB，无疑是深入理解流密码和分组密码工作模式的一个绝佳阶梯。