Bouncy Castle、Crypto++、椭圆曲线加密 (ECC)、解码失败答案

【问题标题】：Bouncy Castle, Crypto++, Elliptic Curve Crypto (ECC), failing to decodeBouncy Castle、Crypto++、椭圆曲线加密 (ECC)、解码失败
【发布时间】：2011-12-21 22:42:25
【问题描述】：

我们有一个使用 Crypto++ 库的 ECC 部分的 C++ 解决方案，但必须转向 .NET 解决方案。由于 Microsoft 的 ECC 代码的文档很少，我目前正在尝试使用文档最少的 Bouncy Castle 库（至少有可用的源代码）。我已经使用 BC 进行加密和解密工作正常；解密已经用 Crypto++ 加密的数据被证明有些问题。

我的最新问题是，当我尝试解密字符串时，我收到“IMac 代码不等于”异常。 BC 是否会在密文中添加某种 MAC？有谁知道是什么原因造成的？

谢谢，帕特里克

【问题讨论】：

你怎么能问出像你这样的问题并提供绝对零代码？您可以在 IESEngine 类中获得该异常，因此显然您正在使用 ECIES。是的，IES 确实计算了 MAC。您的 Crypto++ 代码是否使用 IES？
我问的是充气城堡的作用，而不是我的代码的作用...感谢有关 IES 的提示，这就是我需要知道的 :)
你让它工作了吗？您应该发布有效的 ECIES 代码以完整解决这个问题:)
对不起，Sid，我不再为同一家公司工作，因此无法访问代码，也不记得我做了什么让它工作:(。
我知道这是一个迟到的答案，但这是一个应该引起注意的好问题。

标签： c# .net bouncycastle crypto++

【解决方案1】：

我的最新问题是，当我尝试解密字符串时，我收到“IMac 代码无法相等”异常。

此消息似乎不是当前 BC 发行版的一部分：

$ cd bouncy-castle-153
$ grep -IR "IMac codes failed to equal" *
$

它确实似乎是某人 GitHub 的一部分；见PassKit IesEngine.cs。

它可能是过去 BC 发行版的一部分。

BC 是否在密文中添加某种 MAC？

IesEngine.cs 这个名字告诉我它是一个Integrated Encryption Scheme。它们并不为人所知，也经常不被使用，但它们是非常好的方案。它们将许多原语组合成一个，这使得正确使用很容易，也很难错误使用。从技术上讲，IND-CCA2 是一个强有力的安全概念。

我知道有两种类型的方案。第一个是整数上的 IES，第二个是椭圆曲线上的 IES。整数上的一也称为Discrete Logarithm Integrated Encryption Scheme，椭圆曲线上的一通常称为Elliptic Curve Integrated Encryption Scheme。 Crypto++ 和 Bouncy Castle 等库都提供了它们。

回到您的问题，集成加密方案提供的其中一项功能是密文上的 MAC。

有人知道是什么原因造成的吗？

不幸的是，有很多事情可能会导致这种情况。由于每个委员会都在调整计划，大多数 IES 不兼容。更糟糕的是，我从未见过公开的一组测试向量。您必须努力使事物互操作。

在 Crypto++ 和 Bouncy Castle 的情况下，由于没有测试向量，它们都遭受了轻微的错误，因此它们的处理方式略有不同。这意味着 ECIES 方案不能很好地互操作（或者更准确地说，根本没有）。您可以在 Crypto++ wiki 上的 Bouncy Castle Patch 阅读详细信息。

展望未来，Crypto++ 5.7 将与 Bouncy Castle 1.54 开箱即用。将来，BC 所需的类将记录在Crypto++ wiki 和Crypto++ manual。

【讨论】：

【解决方案2】：

请注意，上面提到的 Crypto++ 5.6.3 充气城堡补丁仅适用于 1.53 之前的充气城堡版本。

对于较新的版本，您可以调整 Crypto++ 补丁以允许 8 字节 Mac 或在 java 端使用 OldECIES 类以实现互操作性。

【讨论】：