不带JCE的Java中的S/MIME

我正在尝试编写一个小程序，用S/MIME对电子邮件进行签名

显然，我只想用所需的材料做一个小罐子。 显然，Java这样做的方式包括在周围放置一个巨大的神圣的签名弹跳城堡JCE罐子

问题是：在不接触JCE并让它抱怨“验证”提供程序的情况下获取s/MIME的最简单方法是什么？也许有一个S/MIME实现不依赖于JCE？也许可以使用Bouncy Castle S/MIME使用他们的轻量级API，而不必接触JCE？也许还有别的办法

对我来说很明显，无论Sun是否同意，没有任何东西可以阻止纯java开源加密算法工作，因此这不是一个理论可能性的问题，而是：哪种方式最不痛苦

当然，通过抓取Bouncy Castle纯java JCE实现，将其包重命名为java.security1，并进行任何我想要的更改，我总是可以很早就变得丑陋——但这种方式现在看起来太痛苦了

---

更新我目前直接使用Bouncy Castle的问题：我尝试从密钥库加载密钥，这涉及到使用SecretKeyFactory，这反过来会拒绝我的Bouncy Castle构建。

BC S/MIME写在CMS包上，因此，问题实际上转移到修改CMS包，以便所有加密都使用轻量级类完成

对于Bouncy Castle的.NET版本，类似的事情已经或多或少成功地完成了。我们正在尝试（承认这是一个缓慢的过程）重构Java版本，以便CMS可以与JCE或轻量级应用程序一起工作。同样的问题也影响到BC API的其他部分，例如PKCS#12密钥库内置在JCE提供程序中，OpenPGP包写入JCE等。这些API的.NET端口也将其重写到轻量级API中

不过，您的问题可能比一般情况更简单。大概您只需要CMSSignedDataGenerator和支持类。您可能不需要addSigner或generate的各种变体。如果您只是预先决定了摘要/签名算法，那么所有提供程序的内容都很容易替换为对特定轻量级实现的硬编码调用

---

如果不使用密钥库，您只需在PKCS#8文件（可能是PEM编码的）中存储一个私钥就可以了。证书也是如此。

在不使用JCE的情况下对消息进行签名非常简单。 真正的问题是读取PKCS的12个键

我这样做： *已将JDKPKCS12KeyStore类复制到。 *在它的任何地方，都将Security.getInstance（）替换为bcProvider.getService（）.newInstance（）（返回Spi-s） *在那些Spi-s（在BC源代码中）中，将所需的方法公开，而不是保护

---

这看起来像是一个黑客，但似乎确实有效。

是的，我可以轻松地在邮件上签名，而无需使用JCE。真正的问题是读取PKCS的12个键。我会在那里描述它。