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

标签 c# .net cryptography

我有一个 TripleDESCng 的工作实现(针对一些测试向量进行了测试),但是发生了以下情况:

当我加密纯文本时 这是一个示例消息(24 字节,因此它是 3 个 block )(十六进制为 5468697320697320612073616D706C65206D657373616765)和一个例子 key ,我得到 E81F113DD7C5D965E082F3D42EC1E2CA39BCDBCCBC0A2BD9。但是,当我使用相同的示例 key 解密时,我得到 5468697320697320612073616D706C650000000000000000,当转换回 ASCII 时,它是:

这是一个示例

除了我的代码之外,还有其他原因会导致这种行为吗?为了加密和解密,我使用 24 字节 key (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();

最佳答案

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

一般来说,假设输出大小与输入大小匹配是一种错误的形式。

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

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


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

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

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

关于c# - TripleDES 加密和解密给出奇怪的结果,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/51612996/

相关文章:

c# - 我什么时候应该在 IEnumerable<T> 的上下文中使用 .Count() 和 .Count

c# - 如何使用 .net 库生成强命名的 SNK key 文件

java - 复制字节数组

c# - 如何在多个 Linq IQueryable 上执行 sql Union

c# - ASPX C# 代码安全

c# - 组合框 C# 中没有显示任何内容

c# - 将只有几列的数据复制到另一个数据表中

c# - 使用 C#/.NET 使用自定义文件格式的过滤器处理程序扩展 Windows 搜索索引

.net - 内存泄漏和弱引用

java - 使用 BouncyCaSTLe 在 Java 中使用 ECIES 进行加密