Java标准加密API与特定提供商（Bouncy Castle）

我正在开发一个java应用程序，它使用一些基本/通用的加密（AES、3DES、DH、ECDH），并且应该在尽可能多的平台（主要是Win/Linux/Android）上运行。关于加密部分，我认为最好使用标准JavaAPI，这样用户就可以使用他们想要的任何加密提供者

幸运/不幸的是，我继承了一些固定在Bouncy Castle上的旧代码。

---

现在，我必须在放弃独立于任何加密提供者的想法，还是更新/重写旧代码以使用标准API之间做出决定。更新/重写的工作量是可行的，但值得吗？

Android本质上是一个重新命名的弹跳城堡。原来的@zapl Android已经使用了Bouncy Castle provider的自定义版本。@MisterSmith这就是第二个链接所解释的：所提供的Bouncy Castle可以没有AES，并且Android可以覆盖您尝试提供完整版本的Bouncy Castle，因为它检测到它已经存在。SpongyCastle重命名所有内容以防止优化，并允许您确保有AES。@zapl我使用了内置Android provider的完整AES-256，与Java SE不同，Java SE默认限制为128。@MisterSmith通过标准API提供的加密算法取决于设备上安装的内容。每个设备可能有不同的设置。例如，旧设备。甚至年纪更大的人也有。如果您想与所有这些功能兼容，就必须提供一个实现。我没有找到任何进一步的证据证明设备不存在AES，但我认为这是可能的。