我对这个主题进行了一些研究，但找不到与我的问题相似的内容。所以我希望你们中的一些好人可以帮助我。
我想在两个客户端之间的应用程序中使用AES128加密（CFB模式）进行网络连接。交换的数据仅包含特定结构的文本字符串，例如，第一个字节总是告诉收件人他们正在接收的消息类型，因此他们可以处理它们。使用AES我想确保消息的机密性，但现在出现了“完整性”的问题。
Normaly你会考虑使用MAC。但是，如果收件人能够正确解密它，即由于字符串的格式可以在他的应用程序中正确使用该消息，是不是保证没有人改变了消息？在解密期间，第三方不会改变（甚至1位）加密消息导致垃圾？
此外，我们假设该应用程序是一个多方点对点游戏，其中两个玩家在私有但AES加密的频道上相互通信。现在，消息的发起者不公平，故意发送欺诈性加密消息，以传达消息已被随机第三方改变的印象（迫使玩家退出）。现在收件人没有机会确定邮件是否被更改，或者发件人是否冒充欺诈，我是对的吗？那么诚信在这种情况下不会有多大用处，可以忽略不计？
这可能听起来像是一个奇怪的世界范例。但这是我最近在类似的应用程序中遇到的问题，我问自己是否有问题的解决方案，或者我是否有基本的AES加密理念。
答案 0 :(得分：1)
正如您所说，可以检测加密后纯文本邮件格式的变化。但它会在什么程度上出错呢？你有一些大而冗余的东西可以测试吗？如果改变后的纯文本在某个地方出现了一些模糊的异常，你打算做什么？使用CFB（与大多数模式一样），攻击者可以确保仅更改消息的最后部分，例如，保留第一个块。
你也担心作弊。
在我看来，你最好使用MAC或HMAC算法，或者在机密性之外提供完整性/身份验证的密码模式（例如EAX或GCM）。如果您确定没有其他人拥有对称密钥，则身份验证检查（例如MAC）将证明数据已由正确的密钥签名。所以不，如果真实性检查成功，用户就无法声称数据在传输中已被更改。
接下来的问题是：你能相信对称密钥只是拥有其他玩家吗？为此，您可能希望使用某种PKI方案（使用不对称密钥）以及密钥交换机制（如DH）。但如果您决定采用这种方式，那将是一段时间。
答案 1 :(得分：0)
这有点超出我的深度，但是......
是的，修改AES加密消息的加密字节会导致解密失败（这是我对c＃实现的经验）。解密的客户端将知道该消息无效。编辑：显然情况并非如此。看起来您需要CRC或哈希来验证消息是否已成功解密。更严重的问题是如果秘密AES密钥泄露（并且在对等环境中，必须发送密钥以便接收器可以完全解密该消息）。然后，第三方可以发送消息，就好像它们是合法的客户端一样，并且它们将被接受为OK。
诚信要困难得多。我不完全确定你想要的东西有多强大，但我怀疑你想要使用public key encryption。这允许您根据私钥包含消息的哈希值（如签名或MAC）以断言消息的有效性。接收方使用公钥来验证哈希值，因此原始消息是正常的。与AES等对称加密相比，公钥加密的主要优点是您不必发送私钥，只需发送公钥。这使得冒充客户变得更加困难。 SSL / TLS使用公钥加密。
在任何情况下，一旦您确定客户端发送无效消息，您就会决定是否信任该客户端。也就是说，恶意行为导致的腐败（您担心的是什么）？或者是一个错误的客户端实现（无能）？还是错误的通讯链接？这就是加密（或至少我对它的了解）不再对你有帮助的地方！
关于诚信的补充：
如果您认为没有其他人可以访问您的密钥，则CRC，哈希或HMAC都足以确保您检测到更改。只需获取消息的正文，计算CRC，散列，等等，并作为页脚附加。如果解密时散列不匹配，则消息已被更改。
秘密密钥保密的假设是非常合理的。特别是如果在一些消息之后你产生了新的消息。 SSH和WiFi的WPA都会定期生成新密钥。
如果你不能认为秘密密钥是秘密的，那么你需要去PKI签署消息。使用AES密钥进入恶意第三方，他们只需使用密钥生成他们想要的任何消息。
根据RNG在邮件中包含序列号可能会有一些里程数。如果您为双方使用相同的RNG和相同的种子，他们应该能够预测下一个序列号。第三方需要拦截原始种子，并知道已发送了多少消息以发送有效但伪造的消息。 （这假设不会丢失或丢弃任何消息。）