TripleDES加密和解密给出奇怪的结果 [英] TripleDES encrypting and decrypting gives strange results

问题描述

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

I have a working implementation of TripleDESCng (tested against some test vectors), but the following happens:

当我加密纯文本这是示例消息（24字节，因此这将是3个块）（十六进制为 5468697320697320620612073616D706C65206D657373616765 ）和示例密钥，得到 E81F113DD7C5D965E082F3D42EC1E2CA39BCDBCCCC002BD9 。但是，当我使用相同的示例密钥对此解密时，我得到 5468697320697320612073616D706C650000000000000000 ，当转换回ASCII时，它是：

When I encrypt plain text This is a sample message (24 bytes, thus for this it would be 3 blocks) (hex for it is 5468697320697320612073616D706C65206D657373616765) with an example key, I get E81F113DD7C5D965E082F3D42EC1E2CA39BCDBCCBC0A2BD9. However, when I decrypt this with the same example key, I get 5468697320697320612073616D706C650000000000000000, which, when converted back to ASCII, is:

这是一个示例。

除我的代码外，为什么有这种行为呢？为了加密和解密，我使用24个字节的密钥（ECB模式）。

Any reason other than my code why this would behave this way? To encrypt and decrypt, I use 24 byte keys (ECB mode).

编辑：

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();

推荐答案

几乎所有模式下 ¹ ，则应确保通过 TransformFinalBlock 而不是 TransformBlock ² ，以确保它知道不再有数据要发送，并确保最终的块被刷新/写入。

With almost all modes¹, you should make sure that the final part of your data is pushed through TransformFinalBlock rather than TransformBlock², to make sure it knows that no more data is coming and to ensure final blocks are flushed/written.

通常，这是一种不好的形式假设输出大小将与输入大小匹配。

It's bad form, in general, to assume the output size is going to match the input size.

模式不是问题，IV都设置为0s

the mode is not a problem, IV is set to 0s either way

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

Yes, that'll mean that the first block was not affected by your choice of Mode. But all subsequent blocks will be, because they will use the chaining mode and the previous block, not the IV. So if you want ECB (you shouldn't³) you need to explicitly set that mode.

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

¹Your code is using CBC, not EBC as you claim in your narrative. CBC is the default mode for .NET encryption classes.

² 使用第二种方法时，请注意它的返回值，因为mjwills

²And when using this second method, pay attention to it's return value, as mjwills commented.

³ 您已经选择了过时的加密算法，将其与过时的操作模式配对，并且我引用了您的文字以上表示您不了解模式。加在一起，我会建议，您不适合编写当前使用加密的代码。 .NET类可以使编写加密代码看起来很容易，但是您仍然必须了解如何在使用它们时做出正确的选择。最好在编写代码之前花更多的时间在研究上。

³You've picked an outdated crypto algorithm, paired it with an outdated mode of operation, and your words I've quoted above mean that you don't understand modes. Added together, I would suggest that you're not well placed to be writing code that uses crypto currently. The .NET classes can make it seem easy to write crypto code but you still have to understand how to make good choices in using them. Better to spend more time on researching these things before writing code.

这篇关于TripleDES加密和解密给出奇怪的结果的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！