4

有没有办法在 C#中执行私钥加密？

我知道中的标准RSACryptoServiceProvider，System.Security.Cryptography但这些类只提供公钥加密和私钥解密。此外，它们还提供数字签名功能，该功能使用内部私钥加密，但没有任何可公开访问的功能来执行私钥加密和公钥解密。

我在 codeproject 上找到了这篇文章，这是执行这种加密的一个很好的起点，但是，我正在寻找一些现成的代码，因为文章中的代码很难加密任意长字节包含随机值的数组（这意味着任何值，包括零）。

你知道一些很好的组件（最好是免费的）来执行私钥加密吗？
我用.NET 3.5.

注意： 我知道这通常被认为是使用非对称加密的不好方法（使用私钥加密并使用公钥解密），但我只需要那样使用它。

附加说明

考虑你有 

var bytes = new byte[30] { /* ... */ };

并且您想使用它2048bit RSA来确保没有人更改此数组中的任何内容。

通常，您将使用数字签名（即。RIPEMD160），然后将其附加到原始字节并发送给接收者。

所以，你有30 字节的原始数据，以及额外的 256 字节的数字签名（因为它是 a 2048bit RSA），总共286 字节。然而，这256 个字节中只有160 位实际上是散列的，因此正好有1888 位（236 个字节）未使用。

所以，我的想法是这样的：

取30 字节的原始数据，附加哈希（20 字节），现在加密这50 字节。您会收到256 字节长的消息，比286 字节短得多，因为“您能够将实际数据推送到数字签名中”。

ECDSA 资源

MSDN
Eggheadcafe.com
c-plusplus.de
MSDN 博客
Wiki

DSA 资源

代码项目
MSDN 1
MSDN 2
MSDN 3

最终解决方案

如果有人对我如何解决这个问题感兴趣，我将使用1024bit DSAand SHA1，它在许多不同版本的 Windows（Windows 2000和更新版本）上得到广泛支持，安全性足够好（我没有签署订单，我只需要以确保某些孩子无法破解他 iPhone 上的签名 (:-D))，并且签名大小只有40 字节长。

4

4 回答 4

3

您尝试设计的内容被称为“带有消息恢复的签名方案”。

设计一个新的签名方案很困难。设计具有消息恢复功能的新签名方案更加困难。我不知道有关您的设计的所有细节，但很有可能它容易受到所选消息攻击。

带有消息恢复的签名方案的一种建议是 RSA PSS-R。但不幸的是，这个提议受到了专利的保护。

IEEE P1363 标准化小组曾经讨论过添加带有消息恢复的签名方案。但是，我不确定这项工作的当前状态，但可能值得一试。

于 2010-07-24T09:31:52.387 回答
2

您的公钥是您的私钥的子集。您可以将您的私钥用作公钥，因为它只会使用所需的完整密钥的组件。

在 .NET 中，您的私钥和公钥都存储在RSAParameters结构中。该结构包含以下字段：

  • D
  • DP
  • DQ
  • 指数
  • 逆Q
  • 模数
  • 磷
  • 问
于 2010-07-23T20:49:12.380 回答
2

如果您处于数据如此之小以至于数字签名相比之下很大的地步，那么您就有了多余的签名。解决方案不是推出自己的算法，而是减少现有的算法。您绝对不想尝试以业余方式将密钥与哈希组合：这已经被破坏了，这就是我们拥有 HMAC 的原因。

所以这是基本的想法：

  1. 使用加密强的 RNG 创建会话密钥。

  2. 通过 PKE 传输。

  3. 使用会话密钥生成 HMAC-SHA1（或 HMAC-RIPEMD160，或其他）。

  4. 如果给定数据的散列大小大得离谱，则通过将顶部与底部进行异或将其切成两半。根据需要重复。

  5. 发送数据和（可能减少的）哈希。

  6. 接收者使用数据和会话密钥重新生成散列，然后将其与传输的散列进行比较（可能在第一次将其删除之后）。

  7. 经常更改会话密钥。

这是滚动自己的系统和使用不合适的系统之间的一种折衷。

我对建设性的批评持开放态度......

于 2010-07-23T23:10:02.223 回答
1

我现在明白了，在阅读评论后。

答案是：不要这样做。

加密签名算法不是您可以从中挑选或修改步骤的算法。特别是，假设签名看起来sig像encrypt(hash),orig + sig与不同。encrypt(orig + hash)此外，即使是过时的签名算法，如PKCS v1.5，也没有一开始那么简单encrypt(hash)。

像您描述的那样的技术为了聪明而牺牲了安全性。如果您没有 256 字节签名的带宽，那么您需要以下之一：

  1. 不同的算法，
  2. 更多带宽，或
  3. 较小的钥匙。

如果您选择（1），请确保这不是您编造的算法！一个简单的事实是加密很难。

于 2010-07-23T21:18:12.307 回答