Java加密API与不同平台

Question

我有一个Android应用程序，它使用javax.crypto来加密文件中的某些文本数据。加密实现类似于this。该应用程序可以正常使用它先前创建的加密数据。

现在，我几乎将我的Android应用程序移植到桌面（JFace / SWT）。我对移植的应用程序使用相同的加密实现，因为它不依赖于任何特定于Android的API。移植的应用程序可以正常使用它创建的加密数据。

问题是桌面应用程序无法解密使用Android应用程序保存的数据。 Android应用程序无法解密数据，这也是使用桌面应用程序保存的。我仔细检查了普通数据和密码的字节流，以便在两个平台上进行加密。它们是相同的，因此文本编码没有问题。但是加密例程在不同平台上返回不同的加密结果，即使输入数据是逐字节相同的。

Java crypto API是否保证在不同平台上运行相同的操作？加密提供商（在我的情况下是AES / 128bit）在Android，Linux和Windows上应该以相同的方式工作吗？有没有办法调整javax.crypto以获得不同平台上的互操作性？

Answer 1

AES-128应该在两个系统上都一样。从理论上讲。

在实践中，两个系统上都有许多细节需要相同。

• 你在两边都使用相同的填充物吗？
• 您是否在两侧使用相同的模式（CBC，CTR，ECB）？
• 双方完全相同的密码？
• 你们两边都有相同的IV / Nonce吗？
• 双方都有相同的密钥派生方法吗？

检查两个系统上的任何默认值。如果默认值不匹配，则需要明确设置一侧或另一侧。

Answer 2

依赖于在不同平台上生成相同随机数的加密随机数生成器是错误的。通常，密钥导出算法中使用的密码随机盐必须从发送方传送到接收方。它可能作为秘密传达，但确实需要传达。当然，“主密码”是主要秘密。

这些盐经常被传达的一种方式是作为密文的前缀。这使得密文比明文更长，但我不认为这对你的样本技术很重要。

此外，对于完整的加密消息交换，需要将其他加密参数传送给解密器。您可以将这些内容连接到您的实现中，就像您在此处所做的那样，但依赖于可重现性似乎太脆弱了。当然，这是攻击者可以复制的东西，所以它不是你秘密的一部分。

您可能希望重新考虑密钥生成算法设置，使其更加健壮。

事后补充：当前方法中发生的事情是加密有用的RNG正以一种已消除所有随机性的方式使用！检查PBKDF2和密钥派生的建议通常很好。

Answer 3

您必须向我们展示一些代码。一个常见的初学者错误是将加密数据存储在String而不是它所带来的byte []中。字符串不是二进制数据的容器。此技术可能在许多方面失败，包括默认的charade差异。