没有 JCE 的 Java 中的 S/MIME
我正在尝试编写一个可以使用 S/MIME 签署电子邮件的小程序。
显然我想制作一个小罐子，只装所需的东西。 显然，Java 的方法涉及到在周围放置一个巨大的带有神圣签名的 Bouncy Castle JCE 罐子。
问题是：在不接触 JCE 并让它抱怨“验证”“提供者”的情况下获得 S/MIME 的最简单方法是什么？也许有一个不依赖于 JCE 的 S/MIME 实现？也许可以使用 Bouncy Castle S/MIME 来使用其轻量级 API，而无需接触 JCE？也许还有其他办法吗？
对我来说很明显，无论Sun是否批准，没有什么可以阻止纯java开源加密算法的工作，所以这不是理论上可能性的问题，而是：哪种方式最不痛苦？
当然，我总是可以通过获取 Bouncy Castle 纯 java JCE 实现、将其包重命名为 java.security1 并进行我想要的任何更改来尽早变得丑陋 - 但这种方式现在看起来太痛苦了。
更新 我当前直接使用 Bouncy Castle 的问题：我尝试从密钥库加载密钥，这涉及使用 SecretKeyFactory，这反过来会拒绝我的 Bouncy Castle 构建。
I'm trying to write an applet that would sign e-mail with S/MIME.
Obviously I want to make one small jar with only the required stuff.
Obviously the Java way of doing that involves having a huge sacred signed Bouncy Castle JCE jar around.
The question is: What's the easiest way of getting S/MIME without touching JCE and having it complain about "authenticating" "providers"? Maybe there is a S/MIME implementation that doesn't depend on JCE? Maybe it is possible to use Bouncy Castle S/MIME using their lightweight API without touching JCE? Maybe there is any other way?
It is obvious to me that nothing can prevent a pure-java open source crypto algorithms from working regardless of whether Sun approves, so it's not a question of theoretical possibility, rather: which way is the least painful?
Of course, I can always go ugly early by grabbing Bouncy Castle pure-java JCE implementation, renaming its packages to java.security1, and making any changes I want - but this way looks too painful right now.
UPDATE My current problem with using Bouncy Castle directly: I try to load keys from keystore, which involves using SecretKeyFactory, which in turn rejects my Bouncy Castle build.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
BC S/MIME 是在 CMS 包上编写的，因此问题实际上是修改 CMS 包，以便所有加密都是使用轻量级类完成的。
对于 Bouncy Castle 的 .NET 版本，类似的事情已经完成了，或多或少是成功的。我们正在尝试（诚然，这是一个缓慢的过程）重构 Java 版本，以便 CMS 内容可以与 JCE 或轻量级一起使用。同样的问题也会影响 BC API 的其他部分，例如 PKCS#12 密钥库内置于 JCE 提供程序中，OpenPGP 包写入 JCE 等。这些的 .NET 端口也将它们重写为轻量级 API。
不过，您的问题可能比一般情况更简单。想必您只需要 CMSSignedDataGenerator 和支持类。您可能不需要 addSigner 或generate 的所有无数变体。如果您只是预先决定您的摘要/签名算法，那么所有提供程序的内容都将很容易替换为对特定轻量级实现的硬编码调用。
也许您可以只在 PKCS#8 文件（可能是 PEM 编码）中存储单个私钥，而不是密钥库。证书也是如此。
BC S/MIME is written over the CMS package, so the question really devolves to modifying the CMS package so all the crypto is done using the light-weight classes.
Something similar has been done already, more-or-less successfully, for the .NET version of Bouncy Castle. We're trying (admittedly it's a slow process) to refactor the Java version so the CMS stuff can work with either JCE or lightweight. The same issue affects other parts of the BC API too e.g. the PKCS#12 keystore is built into the JCE provider, the OpenPGP package is written to JCE, etc. The .NET ports of these rewrote them to the light-weight API also.
Your problem is probably simpler than the general case though. Presumably you only need the CMSSignedDataGenerator and supporting classes. You probably don't need all the myriad variations of addSigner or generate. If you just decide on your digest/signature algorithms up front, then all the provider stuff will be easy to replace with hardcoded calls to specific lightweight implementations.
Instead of a keystore, maybe you could get away with just storing a single private key in a PKCS#8 file (PEM encoded perhaps). Similarly for the certificate.
不使用 JCE 来签署消息非常简单。
真正的问题是读取 PKCS#12 密钥。
我这样做了：
* 复制了 JDKPKCS12KeyStore 类。
* 在其中的所有地方，将 Security.getInstance() 替换为 bcProvider.getService().newInstance() （返回 Spi-s）
* 在那些 Spi-s 中（BC 来源）将所需的方法公开而不是受保护。
它看起来像一个黑客，但似乎确实有效。
It's pretty straightforward to sign messages without using JCE.
The real problem was reading PKCS#12 keys.
I did this:
* Copied JDKPKCS12KeyStore class over.
* Everywhere in it, replaced Security.getInstance() with bcProvider.getService().newInstance() (which returns Spi-s)
* In those Spi-s (in BC sources) made required methods public instead of protected.
It looks like a hack, but seems to actually work.