CFB1、CFB8 与 CFB128 的差别在反馈长度，不在密钥长度

像 AES-256-CFB1 这样的名称带着两个数字，而它们回答的是不同的问题。256 是 AES 密钥长度。1 是 CFB 的反馈长度，也就是段大小，描述的是该模式如何推进自身状态。若把 1 当成密钥长度来读，这个名字看起来就像一次灾难性的错误配置，这也是这个问题反复出现的原因。

在评判名称之前，先确定你看到的是三个量中的哪一个：密钥大小、分组大小还是段大小。按通常意义，只有第一个才是安全参数。

三个数字，三个量

AES 接受 128、192 或 256 位的密钥，无论选哪一种，分组都是 128 位。分组大小属于 AES，而不属于模式。CFB 后缀是第三个量：模式每一步消耗并回馈多少数据。OpenSSL 的 AES 文档对这些 CFB 变体明确列出了相应的移位长度。

CFB1 每次回馈一位，CFB8 一个字节，CFB128 一整个分组。三者内部用的都是同一个 128 位分组密码；变化的只是每次运算取用所计算分组中的多少位。因此后缀改变的是开销与缓冲行为，而不是密钥强度。

为什么分组大小永远不会变

AES 是分组固定为 128 位的分组密码，而模式是围绕它搭建的结构。它们没有一个会为了让分组去匹配段大小而缩小分组。CFB1 的实现仍然会计算一个完整的 AES 分组，然后只取其中一位结果。其余位在这一步被丢弃，效率开销正出在这里。

所以一位的反馈并不意味着一位的密钥，也无法按后缀给名称排出高低。CFB128 并不比 CFB32 强四倍，它只是处理更大的段。

段大小究竟改变了什么

段大小改变每一步回馈多少密文，以及每一步能承载多少明文。它还改变错误传播与缓冲行为，这对类流式用法很重要。面向字节的段与缓冲区对齐，面向位的则不然。

在实践中选模式的是协议，而不是操作者。VPN 的数据通道使用其协议规定的构造，并带有自己的完整性保护，而库里的清单只告诉你存在哪些名称。

如何读懂没有限定的 CFB 标签

没有限定的 CFB 标签需要它的实现语境。在 OpenSSL 1.0.2 的头文件中，EVP_aes_128_cfb 是 EVP_aes_128_cfb128 的宏，192 位和 256 位密钥也有对应的别名。那只是某个分支的 API 命名约定，并不表示每个库、文件格式或 GUI 都以同样方式展开这个缩写。请查看你面前这个版本的头文件或文档。

如果旧配置写着 CFB 而对方接受了，协商出的参数总会记录在某处：日志、配置转储或 API 响应。去读那些记录，而不是从显示字符串推断段大小。

模式名称不会告诉你的事

名称只描述加密行为，别的什么也不描述。VPN 仍然需要完整性保护、密钥派生与对端认证，而 CFB 一样都不提供。把 CFB8 换成 CFB1 也不是外观上的改动：线路上的行为不同，双方必须支持同一种构造。库里有这个名字，也不能证明已部署的网关会在其数据通道上接受它。

对于任何仍在维护的东西，请采用协议的完整保护安排与运维策略，并记录库与网关版本、确切选项以及协商结果。旧名称解释的是你在读什么；它并不能为恢复该配置提供理由。