TripleDES 密钥大小 - .NET 与 Wikipedia答案

【问题标题】：TripleDES key sizes - .NET vs WikipediaTripleDES 密钥大小 - .NET 与 Wikipedia
【发布时间】：2011-07-20 17:52:17
【问题描述】：

根据Wikipedia，TripleDES 支持 56、112 和 168 位密钥长度，但 System.Cryptography.TripleDESCryptoServiceProvider.LegalKeySizes 表示它只接受 128 和 192 位密钥长度。

我正在开发的系统需要可互操作（由我的代码加密的数据需要在 PHP、Java 和 Objective-C 中可解密），在这种情况下我不知道谁是正确的。

那么我应该相信谁呢？以及如何确保我的加密数据是可移植的？

【问题讨论】：

标签： encryption wikipedia des tripledes

【解决方案1】：

维基百科没有说 TripleDES 支持 56 位密钥。 “密钥选项”谈论“三倍长度”密钥和“双倍长度”密钥，后者“将密钥大小减少到 112 位”。原始 DES 的有效密钥大小为 56 位。但是，这样的密钥是由 64 位输入构造的，其中 8 位未使用。因此，“三倍长”密钥选项适用于由三倍 64 位（=192 位）构成的三倍 56 位（=168），而“双倍长度”选项适用于两倍 56 位密钥（=112）由两次 64 位 (=128) 构成。

由于您的 TripleDESCryptoServiceProvider 需要首先从基于 64 位的输入中派生实际密钥，因此它只需要 128 位（双倍长度）或 192 位（三倍长度）作为输入，然后在内部派生 168 或来自该输入的 112 位实际密钥。

这是 TripleDES 的标准程序，因此跨平台的可移植性应该没有问题。

【讨论】：

三天看了无用的例子然后这个答案帮助我意识到.Net如何支持128位密钥和CCCrypt功能迫使你进入192位......它将128位的前64位复制到最后所以K3 = K1。 iOS C#.Net 互操作性。如此简单。

【解决方案2】：

三重 DES 将仅使用 128/192 位密钥的 112/168 位。 .NET 要求更多位用于对齐（每个 56 位子键在 64 位边界上对齐）。

56 位 DES 已损坏，我预计它们会使其更难使用。

【讨论】：

【解决方案3】：

我相信 DES 的某些（全部？）实现仅使用密钥的每个字符 7 位（ASCII 编码）。我不确定 DES 的定义是否允许密钥中的 8 位字符，或者它是否实际上忽略了每个字节的高位。我认为是后者。

但是，在 .NET 中，密钥大小基于字节数乘以每字节 8 位，即使底层算法忽略了最高位。这可能是主要的差异。

TripleDES 使用三个不同的 56 位 DES 密钥运行 DES 三次。在一些实现中，中间运行是相反的（加密-解密-加密或“EDE”），以便对所有三个使用相同的 56 位 DES 密钥复制简单 DES 的加密。这样做是为了与两者都使用基于硬件的加密的旧系统兼容。我不确定 TripleDESCryptoServiceProvider 是使用这种“EDE”方法还是“EEE”方法（或给你一个选择）。此外，相同的 56 位 DES 密钥可用于第一次和第三次运行，使用 112 位密钥而不是它也可以使用的 168 位密钥。

经过认证的 TripleDESCryptoServiceProvider 不接受 56 位（64 位）密钥，因为它不是真正的 3DES 安全性（您可以改用 DESCryptoServiceProvider 吗？）。曾经确定 168 位 EEE（或 EDE？）3DES 不提供比使用 112 位（128 位）密钥更高的安全性。但是，可能存在一些极端（通常不可用）的攻击，其中较短的密钥理论上更容易受到攻击。这也可能适用于 EDE 与 EEE 的问题。

关于与其他语言的兼容性问题，.NET 的 *CryptoServiceProvider 类只是底层 Windows CRYPTO 库的包装 API。如果其他语言也使用 Windows CRYPTO 库，它应该是兼容的。否则，您必须确定他们使用的是 EDE 还是 EEE，并确保所有人都使用相同的（您可能对此有灵活性也可能没有），并且显然使用相同的密钥长度。它们可能都使用相同的字节顺序，但是如果您发现仍然不匹配，则可能需要检查另一件事。很可能在 Windows 上，它们都使用 CRYPTO，并且可能会匹配，只要您可以为所有选项设置相同的选项。

【讨论】：

迟了，但是：DES的定义为（奇）校验保留了每个密钥字节的低位；在 1970 年代，加密是在专用的离散硬件中完成的，比特错误是一种真正的可能性。今天几乎所有的软件或固件都有一些实现忽略奇偶校验，有些仍然检查它的兼容性；我不知道 dot-NET（或 CAPI）是做什么的。不应假定或要求键值使用 ASCII，并且肯定与定义无关。 ...
... 此外，EDE 和 EEE 早在 1990 年代就被考虑过，当时显然需要对 DES 进行“增强”，但只有 EDE 是标准化的，我会很惊讶地发现今天做 EEE 的任何实现。
@dave_thompson_085 感谢您对 EDE 标准化的说明。在奇偶校验位上，如果软件实现（转换为可能的硬件实现）在低 7 位有更多熵时（如果直接提供加密密码）占用每个提供的字节的高 7 位，那将是非常糟糕的 - -如果可能是愚蠢的）。我认为最明智的做法是保留每个字节的低 7 位并将它们与计算的奇偶校验一起转移到 3DES 实现中。当然，它可能会做一些不太明智的事情，并失去熵。

【解决方案4】：

Des 使用 64 位密钥的倍数，但丢弃了 8 位，留下了 64 位的有用密钥长度。
Triple des 可以使用双键或三键长度。
但是，因为使用相同的密钥重复 des 会解密运行 des 偶数次的消息，如果密钥共享模式，则可以部分解密内容。

因此，des 总是运行奇数次。

这也是为什么您永远不应该选择重复 64 位部分的密钥的原因。

使用 Triple des 192 位，因此您的有效密钥长度为 112 位

【讨论】：