2

我对该主题进行了一些研究，但找不到与我的问题相似的任何内容。所以我希望你们中的一些伟大的人可以帮助我。

我想在我的应用程序中的两个单独客户端之间的网络中使用 AES128 加密（CFB 模式）。正在交换的数据仅由特定结构的文本字符串组成，例如，第一个字节总是告诉接收者他们正在接收的消息类型，以便他们可以处理它们。使用 AES 我想确保消息的机密性，但现在出现了“完整性”的问题。

通常，您会考虑使用 MAC。但是，如果接收者能够正确解密消息，是否可以保证没有人更改过消息，也就是说，由于字符串的格式，消息可以在他的应用程序中正确使用？第三方更改（甚至 1 位）加密消息不会在解密期间导致垃圾吗？

此外，让我们假设该应用程序是一个多方点对点游戏，其中两个玩家在一个私有但 AES 加密的通道上相互通信。现在消息的发起者不公平，并故意发送欺诈性加密消息来传达消息已被随机第三方更改的印象（迫使玩家退出）。现在收件人将没有机会确定消息是否已被更改或发件人是否存在欺诈行为，对吗？那么在这种情况下，诚信没有多大用处，可以忽略不计？

这听起来像是一个奇怪的例子。但这是我最近在类似应用程序中遇到的问题，我问自己是否有解决问题的方法，或者我是否了解了 AES 加密的基本理念。

4

2 回答 2

1

正如您所说，您可能会检测到加密后纯文本消息格式的变化。但在什么层面上会出错呢？你有足够大和冗余的东西来测试吗？如果更改后的纯文本会导致某处出现一些模糊的异常，你会怎么做？例如，使用 CFB（与大多数模式一样），攻击者可以确保仅更改消息的最后一部分，并保持第一个块完好无损。

你也担心作弊。

在我看来，最好使用 MAC 或 HMAC 算法，或在机密性之上提供完整性/身份验证的密码模式（例如 EAX 或 GCM）。如果您确定没有其他人拥有对称密钥，则身份验证检查（例如 MAC）将证明数据已由正确的密钥签名。所以不，如果真实性检查成功，用户不能声称数据已在传输中更改。

下一个问题变成：你能相信对称密钥只属于其他玩家吗？为此，您可能希望使用某种 PKI 方案（使用非对称密钥）以及 DH 等密钥交换机制。但那是以后的事了，如果你决定走那条路。

于 2011-12-19T01:56:28.970 回答
0

这有点超出我的深度，但是...

是的，修改 AES 加密消息的加密字节应该会导致解密失败（这是我对 c# 实现的经验）。解密的客户端会知道消息是无效的。编辑：显然情况并非如此。看起来您需要 CRC 或哈希来验证消息是否已成功解密。更严重的问题是，如果秘密 AES 密钥被泄露（在对等环境中，必须发送密钥，以便接收者可以完全解密消息）。然后第 3 方可以发送消息，就好像他们是合法客户端一样，他们将被接受为 OK。

诚信更难。我不完全确定你想要的东西有多健壮，但我怀疑你想使用public key encryption。这允许您根据私钥包含消息的散列（如签名或 MAC），以断言消息的有效性。接收者使用公钥来验证散列，因此原始消息是正常的。与 AES 等对称加密相比，公钥加密的主要优点是您不必发送私钥，只需发送公钥即可。这使得冒充客户变得更加困难。SSL / TLS使用公钥加密。

无论如何，一旦您确定了发送无效消息的客户端，您就处于决定是否信任该客户端的世界。也就是说，是否是恶意行为导致的腐败（您担心的是什么）？还是客户端执行错误（无能）？还是通信链路故障？这就是加密（或至少我对它的了解）不再帮助您的地方！

关于完整性的附加信息：

如果您假设没有其他人可以访问您的密钥，那么 CRC、哈希或 HMAC 都足以确保您检测到更改。只需获取消息的正文，计算 CRC、散列等，然后附加为页脚。如果解密时哈希值不匹配，则消息已被更改。

秘密密钥保持秘密的假设是非常合理的。特别是如果在一些消息之后您生成新消息。SSH 和 WiFi 的 WPA 都会定期生成新密钥。

如果你不能假设密钥是秘密的，那么你需要去 PKI 对消息进行签名。使用恶意第 3 方中的 AES 密钥，他们将使用密钥生成他们想要的任何消息。

在基于 RNG 的消息中包含序列号可能需要一些里程。如果您为双方使用相同的 RNG 和相同的种子，他们应该能够预测接下来会出现什么序列号。第 3 方需要拦截原始种子，并知道已经发送了多少消息来发送有效但伪造的消息。（这假设永远不会丢失或丢弃任何消息。）

于 2011-12-18T22:26:19.973 回答