应该使用 AES-128 加密 4 个字节的最小字节数是多少？答案

【问题标题】：What is the minimum number of bytes that should be used to encrypt 4 bytes with AES-128?应该使用 AES-128 加密 4 个字节的最小字节数是多少？
【发布时间】：2012-03-20 11:31:42
【问题描述】：

我正在开展一个项目，该项目涉及使用 UDP 通过高性能套接字连接发送一些非常小的加密消息。我在其他帖子中读到，AES 应该使用 128 位密钥加密的最小字节数是块大小，即 16 字节。

但是，真正的问题是 - 这足以提供良好的保护吗？我正在考虑使用一种方案，将一些随机数据添加到消息中，并获得一个介于 1 和 12 之间的随机数，用于将 4 个字节的真实数据放置在块中。块中的零字节将是随机数，它是 4 字节块中的起始位置。构建块后，将使用 128 位密钥使用 AES 对其进行加密。客户端断开连接后数据没有任何价值，连接最长不超过24-48小时。像这样的东西会起作用吗，还是我应该发送更多数据以使潜在对手更难破解？

我还将加密其他在用户断开连接后确实需要保护的数据，例如信用卡号、银行帐户信息、密码哈希等。我计划为此使用带有 256 位密钥的 AES。因此，对于这种情况，同样的问题 - 应该加密的最小字节数是多少，以便为 256 位密钥提供良好的保护？ 16 个字节就够了，还是 32 个字节更好？

我计划使用 bouncy castle 的快速 AES 引擎来处理小消息。见：

http://www.bouncycastle.org/csharp/index.html

http://www.bouncycastle.org/docs/docs1.6/org/bouncycastle/crypto/engines/AESFastEngine.html?is-external=true

对于 256 位 AES 加密，我正在考虑使用 RijndaelManaged，因为它在服务器上似乎具有更好的安全功能，并且对于这些不频繁的事务而言，性能并不是什么大问题。

【问题讨论】：

您需要完整性检查，还是只需要加密？
我想我也可以明文发送随机数据的最后 4 个字节。然后，如果解密后不匹配，则可以拒绝，发送重传请求。
我认为您正在尝试创建自己的协议，虽然有完全有效的、更加标准化的解决方案。通常不赞成创建自己的加密货币。实际上，我越有经验，就越能看到制定自己的计划的危险。
我没有创建自己的 crpto 解决方案。我正在使用标准 AES 库进行所有加密。我试图将一些随机数据放入消息中的原因是使其更难破解。不应该做的是每次用户采取某种行动时都发送相同的加密块......这很明显而且很容易被破解。我正在使用 UDP 提出自己的协议，这并不少见。
提出自己的 UDP 协议很好，但是例如在单个块上使用 4 个字节的随机数据可能不行。创建客户端/服务器协议也可能容易受到 oracle 攻击。与其考虑部署 AES 的创新方法，不如看看已经有什么。

标签： .net encryption aes

【解决方案1】：

首先，密文越少，就越不容易受到攻击。看来您认为情况正好相反。

对于 UDP，我强烈建议您研究计数器模式加密。优点是可以预先计算密钥流，从而实现低延迟加密/解密。它也不需要填充，因此您不必发送比所需更多的数据（请注意，您有一个关于数据长度的侧通道，因此可以清楚地看到“是”和“否”之间的区别）。不过你确实需要一个好的 NONCE。

如果您想要完整性保护，那么 GCM 模式加密将是非常可取的。如果它不可用，请在密文上查看 HMAC 或 MAC - 但您将需要两个密钥，而不仅仅是一个。

【讨论】：

您听说过 VMAC 吗？根据一些基准，它看起来更快。有什么意见吗？
我还没有研究 VMAC，抱歉。您可以在crypto 上询问以获得最好的在线建议。
您可以接受我的回答吗？抱歉，我无法回答 VMAC 速度，但这是一个单独的问题。