推荐的数字签名加密组合答案

【问题标题】：Recommended Encryption combination for digital signatures推荐的数字签名加密组合
【发布时间】：2010-07-03 11:48:34
【问题描述】：

我终于 - 经过几天和几天的痛苦 - 发现我的数字签名项目需要两种形式的加密。第一个将是对称 (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 密钥大小：1024（我试过 2048 但由于某种原因它不起作用）

AES 密钥大小：???? （建议）

另外，如果您知道我在哪里可以找到关于 Android 实际支持的内容的良好指南，那就太好了。

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

如果您知道一个好的组合，但不确定它是否在 Android 上受支持，请说出来，这样我就不会浪费大量时间来发现它不支持。

【问题讨论】：

【解决方案1】：

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

但 RSA 不用于加密输入“流”——它仅用于加密会话密钥（正如您所做的那样）或签署消息摘要函数的输出。所以 RSA 的 ECB 模式很好。

在 RSA 中使用 PKCS#1 填充方案； PKCS#5 填充方案适用于对称密码。

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

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

同样的指导方针还提到了“添加1 和尽可能少的0 位来完成最终块”填充机制，因此使用起来应该足够安全。

但对于这一切，我不得不建议使用 gpgme 或 openssl 或 gnutls 来完成所有工作。尝试制定自己的协议可能非常微妙。希望 Android 上有一些更高级别的工具包可以让签名生成/验证变得更加容易。

【讨论】：

【解决方案2】：

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

【讨论】：

【解决方案3】：

如果你正在做签名，那么你应该使用Signature 类。

【讨论】：

我实际上需要从客户端上的加密文件中获取信息，所以我不认为 Signature 类允许这样做。
你说你在做数字签名。如果是这样，你没有加密任何东西。你为什么要加密文件？
有人告诉我它在另一个线程上被称为数字签名，我之前称它为许可证。基本上，我在许可证中存储了一些信息，例如设备 ID、用户名等。我需要能够检索这些信息以在他们的设备上显示给用户，并检查设备 ID 是否等于他们的许可证设备 ID。跨度>

【解决方案4】：

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

签名请使用PKCS#7签名，由该类处理，

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

【讨论】：

这看起来很有趣，但是您提供的那些链接并不是那么有用。这两个 API 可以为我做什么，尤其是 SMIME API？
也许这个例子能更好地解释它？ java2s.com/Open-Source/Java-Document/Security/Bouncy-Castle/org/…