时间戳

首页 > 解决方案 > TripleDES 加密和解密给出了奇怪的结果

c# - TripleDES 加密和解密给出了奇怪的结果

问题描述

我有一个有效的实现TripleDESCng（针对一些测试向量进行了测试），但是会发生以下情况：

当我使用示例密钥加密纯文本This is a sample message（24 个字节，因此它将是 3 个块）（十六进制为）时，我得到. 但是，当我使用相同的示例密钥对其进行解密时，我得到，当转换回 ASCII 时，它是：5468697320697320612073616D706C65206D657373616765E81F113DD7C5D965E082F3D42EC1E2CA39BCDBCCBC0A2BD95468697320697320612073616D706C650000000000000000

This is a sample.

除了我的代码之外，还有什么原因会导致这种行为？为了加密和解密，我使用 24 字节密钥（ECB 模式）。

编辑：

using (var tripleDES = new TripleDESCryptoServiceProvider())
{
   byte[] data = ASCIIEncoding.ASCII.GetBytes("This is a sample message");
   Console.WriteLine(BitConverter.ToString(data));
   tripleDES.IV = new byte[tripleDES.BlockSize / 8];
   var encryptor = tripleDES.CreateEncryptor();
   byte[] result = new byte[data.Length];
   encryptor.TransformBlock(data, 0, data.Length, result, 0);
   var decryptor = tripleDES.CreateDecryptor();
   byte[] result2 = new byte[result.Length];
   decryptor.TransformBlock(result, 0, result.Length, result2, 0);
   Console.WriteLine(BitConverter.ToString(result2));
}
Console.ReadLine();

标签： c#.netcryptography

解决方案

对于几乎所有模式1，您应该确保数据的最后部分被推送TransformFinalBlock而不是TransformBlock2，以确保它知道没有更多数据即将到来并确保最终块被刷新/写入。

一般来说，假设输出大小将与输入大小匹配是不好的形式。

模式没有问题，IV设置为0s

是的，这意味着第一个块不受您选择的模式的影响。但是所有后续块都将是，因为它们将使用链接模式和前一个块，而不是IV。因此，如果您想要ECB（您不应该3），您需要明确设置该模式。

1您的代码使用的是 CBC，而不是您在叙述中声称的 EBC。CBC 是 .NET 加密类的默认模式。

2在使用第二种方法时，请注意它的返回值，正如 mjwills 评论的那样。

3你选择了一个过时的加密算法，将它与一个过时的操作模式配对，而我上面引用的你的话意味着你不了解模式。加在一起，我建议您目前不适合编写使用加密的代码。.NET 类可以使编写加密代码看起来很容易，但您仍然必须了解如何在使用它们时做出正确的选择。最好在编写代码之前花更多时间研究这些东西。

推荐阅读