经过日复一日的痛苦之后，我终于发现我的数字签名项目需要两种形式的加密。第一个将是对称 (AES)，并将加密许可证数据，第二个将是非对称 (RSA)，并将>加密对称 key 。有人可以指导我使用 Android 的最佳方法吗？
对于我正在使用的公钥/私钥:“RSA/ECB/PKCS1Padding”(我认为 ECB 不好，所以我应该使用什么？，PKCS1Padding 怎么样 - 我应该使用 PKCS5Padding ？)
对于对称 key ，我可能会使用:“AES/???/?????????”(我应该使用什么模式和填充？)
The provider: "BC"
RSA Keysize: 1024 (I tried 2048 but it didn't work for some reason)
AES Keysize: ???? (suggestions)
此外，如果您知道我可以在哪里找到有关 Android 实际支持的内容的良好指南，那就太好了。
我绝不是加密专家，因此如果这里看起来有点不稳定，请告诉我更好的选择!
如果您知道一个好的组合，但不确定 Android 是否支持它，请说出来，这样我就不会浪费大量时间来发现它不受支持。
最佳答案
ECB 对于分组密码模式来说是不安全的，因为 64、128 或 256 位 block 很容易在输入流中重复使用 - 重复内容的存在将在密文中立即可见。
但是 RSA 并不用于加密输入“流”——它仅用于加密 session key (正如您似乎正在做的那样)或对消息摘要函数的输出进行签名。所以 RSA 的 ECB 模式没问题。
将 PKCS#1 填充方案与 RSA 结合使用； PKCS#5 填充方案适用于对称密码。
如果 1024 是您可以使用(或在设备上生成？)的最大 RSA key 对，那么 128 或 192 位 AES 可能存在类似的风险。根据 256 位 AES 的慢速程度，我可能会改用它，只是为了针对 AES 攻击的算法改进提供另外四到五年的缓冲。
NIST 关于使用 AES 的指南建议使用以下任一模式:CBC、CFB、OFB 或 CTR 模式。
相同的指南还提到了“添加 1”，并且完成最终 block 需要很少的 0 位”填充机制，因此使用起来应该足够安全.
但是对于这一切，我不得不建议使用 gpgme 或 openssl 或 gnutls 来完成所有工作。尝试制定自己的协议(protocol)可能会非常微妙。希望 Android 上有一些更高级别的工具包可以使签名生成/验证变得更加容易。
NIST 指南:http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf
关于java - 推荐的数字签名加密组合，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3171392/