数字签名的推荐加密组合 [英] Recommended Encryption combination for digital signatures

问题描述

我终于在痛苦的日子和日子之后，想出了我的数字签名项目需要两种形式的加密。第一个将是对称（AES），并加密许可证数据，第二个将是不对称（RSA）将会加密对称密钥。有人可以给我指点Android的最佳方法。

对于我使用的公钥/私钥：RSA / ECB / PKCS1Padding（我主管欧洲央行是坏的，所以我应该使用什么？PKCS1Padding - shoudl我使用PKCS5Padding？）

对于对称密钥，我可能会使用：AES / ??? / ???（我应该使用什么模式和填充） p>

提供者：BC

RSA密码：1024（我试过2048但是它没有因为某些原因而工作）

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

另外，如果你知道在哪里可以找到一个很好的指南，在Android中实际支持哪些是伟大的。 / p>

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

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

解决方案

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上有一些更高级别的工具包，使签名生成/验证更容易。

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

I have finally - after days and days of agony - figured out that I need two forms of encryption for my Digital Signatures Project. The first will will be symmetric (AES) and will encrypt the license data and the second will be a asymmetric (RSA) an will encrypt the symmetric key. Can someone give me pointers on the best methods to use for Android.

For the public/private keys I am using: "RSA/ECB/PKCS1Padding"(I head ECB is bad so what should I use?, what about the PKCS1Padding - shoudl I be using PKCS5Padding?)

For the symetric keys I will probably use: "AES/???/?????????" (What mode and padding should I use?)

The provider: "BC"

RSA Keysize: 1024 (I tried 2048 but it didn't work for some reason)

AES Keysize: ???? (suggestions)

Also if you know where I can find a good guide on what is actually supported in Android that would be great.

I am in no way an encryption expert so if anything looks a little precarious here please tell me a better alternative!

If you know of a good combination but are not sure if it is supported on Android please say so, so that I don't end up wasting a whole lot of time to find it is not supported.

解决方案

ECB is unsafe for block cipher modes, because it is too easy for 64, 128, or 256 bit blocks to be re-used in an input stream -- the presence of repeated content would be immediately visible in the ciphertext.

But RSA is not used for encrypting input 'streams' -- it is only ever used for encrypting session keys (as you appear to be doing) or signing the output of message digest functions. So ECB mode for RSA is fine.

Use the PKCS#1 padding scheme with RSA; PKCS#5 padding scheme is intended for symmetric ciphers.

If 1024 is the largest RSA keypair you can use (or generate on the device?) then probably 128 or 192 bit AES is a similar risk. Depending on how much slower 256-bit AES is, I might use it instead, just to provide another four or five years buffer against algorithmic improvements in AES attacks.

NIST's guidelines on using AES recommend using any of: CBC, CFB, OFB, or CTR modes.

The same guidelines also mention the 'add 1 and as few 0 bits are required to complete the final block' padding mechanism, so it should be safe enough to use.

But for all this, I have to suggest using gpgme or openssl or gnutls to do all your work. Trying to make your own protocols can be very subtle. Hopefully there's some higher-level toolkits on the Android to make signature generation / verification much easier.

NIST's guidelines: http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf

这篇关于数字签名的推荐加密组合的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！