Recommended Encryption combination for digital signatures

Question

Hi

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.

Answer 1

When it comes to the mode of operation for AES, you can go for CBC. If your RSA modulus is 1024 bits, there is no need for AES key larger than 128 bits. If it has to do with licenses and software protection, people will bypass the code, not break the crypto :)

Answer 2

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

Answer 3

If you are doing signatures than you should use the Signature class.

Answer 4

You shouldn't re-invent the wheels. Use standard mechanisms supported by BouncyCastle.

For signature, you should use PKCS#7 signature, which is handled by this class,

http://bouncycastle.gva.es/www.bouncycastle.org/docs/mdocs1.4/org/bouncycastle/cms/CMSSignedDataGenerator.html

For encryption, you can use the S/MIME APIs, which handles symmetric key generation/encryption/enveloping for you,

http://www.bouncycastle.org/wiki/display/JA1/CMS+and+SMIME+APIs