推荐用于数字签名的加密组合

我终于 – 在痛苦的日子和日子之后 – 发现我的数字签名项目需要两种加密forms。第一个将是对称的（AES）并将加密许可证数据 ，第二个将是非对称（RSA） ，将加密对称密钥 。有人可以指出我用于Android的最佳方法。

For the public/private keys I am using: "RSA/ECB/PKCS1Padding" （我的ECB很糟糕，所以我应该使用什么？，PKCS1Padding怎么样？我使用PKCS5Padding怎么办？）

For the symetric keys I will probably use: "AES/???/?????????" （我应该使用什么模式和填充？）

提供者：“BC”

RSA Keysize：1024（我试过2048，但由于某些原因它没有用）

AES Keysize：???? （建议）

另外，如果你知道我在哪里可以找到关于Android实际支持的一个很好的指南。

我绝不是加密专家，所以如果有什么看起来有点不稳定，请告诉我一个更好的选择！

如果你知道一个很好的组合，但不确定它是否支持Android，请说明，这样我最终不会浪费很多时间来发现它不受支持。

ECB对于分组密码模式是不安全的，因为它很容易在输入流中重复使用64,128或256位块 – 重复内容的存在将立即在密文中可见。

但是RSA不用于加密输入’流’ – 它只用于加密会话密钥（如你似乎正在做的那样）或签署消息摘要function的输出。所以RSA的ECB模式很好。

将PKCS＃1填充方案与RSA一起使用; PKCS＃5填充方案适用于对称密码。

如果1024是您可以使用（或在设备上生成？）的最大RSA密钥对，则可能128或192位AES具有类似的风险。根据256位AES的速度慢，我可能会使用它，只是为了提供另外四到五年的缓冲，以防止AES攻击中的算法改进。

NIST关于使用AES的指南建议使用以下任何一种：CBC，CFB，OFB或CTR模式。

同样的指南还提到’添加1和完成最终块’填充机制所需的0位，因此它应该足够安全使用。

但是对于所有这些，我必须建议使用gpgme或openssl或gnutls来完成所有工作。试图制作自己的协议可能非常微妙。希望Android上有一些更高级别的工具包，使签名生成/validation更容易。

NIST的指南： http ： //csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf

谈到AES的操作模式，你可以去CBC。如果您的RSA模数为1024位，则不需要大于128位的AES密钥。如果它与许可证和软件保护有关，人们将绕过代码，而不是破坏密码:)

如果您正在使用签名，则应使用Signature类。

你不应该重新发明轮子。使用BouncyCastle支持的标准机制。

对于签名，您应该使用PKCS＃7签名，该签名由此类处理，

对于加密，您可以使用S / MIME API，它为您处理对称密钥生成/加密/包络，