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
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 :)
If you are doing signatures than you should use the Signature class.
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
Related
I am writing software in Java that will run on Android, Windows, Linux and OSX and want the devices to all talk to each other securely.
My initial thought was just to use a asymmetric algorithm (eg. RSA) and share the public keys manually. Then sessions would be encrypted just using RSA. I hit problems with this due to buffer size, then I read about CBC etc and the problems of data leakage if some form of XOR of data was not performed.
So...I looked at using AES/CBC/{padding}. Initially this sounded good: just share the key, an IV and away we go.
But these apps all talk to each other in both directions at any time, so keeping the IV in sync did not seem possible, resulting in a new IV being sent with every message. Not a big deal, but one of the advantages of AES over RSA is data size, and now I'm going to be adding 32 bytes to every message. Though I guess keeping a 'receiver' and a 'sender' Cipher would probably work.
Now I am back to considering alternatives, and trying to avoid too much roll-your-own.
Is there any substantial reason not to use RSA and CBC (or similar) done manually? ie. break data into chunks, pad as necessary, and encrypt with RSA, doing whatever XOR strategy seems most reliable.
Is there a better was to keep secure and trusted comms between pairs of peers without creating an SSL CA? Or, is there a way of hooking into the certificate verifier so that I can use my pre-shared public keys to validate the peer connections?
Any other suggestions/examples for best/simple multi-platform peer-peer secure comms?
You should look into implementing a hybrid cryptosystem. If I can guess your knowledge about the subject correctly you should really be using a pre-existing one like TLS, or DTLS, as you're not going to design a cryptographically safe protocol out of the blue.
Note that the certificates are required to create a PKI, and the asymmetric crypto of course comes with it. You should however only have to use the asymmetric crypto during the handshake which includes the initial authentication and session key negotiation.
I am trying to implement RSA encryption using blocks to cut down the run time of decrypting with large bits lengths. The way my program is now, it works but reads individual characters and decrpyts them. So as you might imagine, the run time for large bit lengths is long.
Is there a way to easily implement decryption using blocks so that it works faster for these large bit lengths. Examples of code with an implementation would be nice if it is easy and feasible. Thanks.
From your description, it appears that you're using the following encryption scheme:
for i=0 to length(input):
output(RSA_encrypt(key, input[i]))
This is not a secure encryption scheme. You appear to be asking for a way to do something similar to
for i=0 to blocks(input):
output(RSA_encrypt(key, block(i, input)))
That is likewise not secure. Secure RSA-based encryption schemes generally involve encrypting a unique session key with RSA then encrypting the message using a symmetric cipher such as AES. For instance, see RSAES-OAEP. Don't try implementing it yourself, because you're likely to get it wrong. Instead, use a reputable cryptographic library.
Always remember the Rules of Crypto:
Never design your own crypto.
Never implement your own crypto.
Anyone can design crypto that they can't break themselves.
I am implementing RSA manually on java (yes i know not the best idea but it is for university purposes). My algorithm is working good enough with small texts but when big texts come into consideration the algorithm breaks as the number of bits is superior than my key.
I am looking into the possibility to implement a padding scheme in order to fragment my plain text into small ones and then encrypt them.
Is there any suggestion on how to the padding?
Thanks in advance.
I'm sorry that I'm writing an answer that contains basically the same information as divanov's answer, but an edit to add all the little details that I think are important would be a complete rewrite of the answer.
Generally you don't want to asymmetrically encrypt your data directly, but instead use RSA to exchange a symmetric key that is used to encrypt your data symmetrically. You can do it like this (idea taken from "Cryptography Engineering" by Ferguson, Kohno and Schneier, a book I can wholeheartedly recommend):
Assuming that l is the bit length of your modulus n, generate an l-1 bit long random number r. Encrypt r with the RSA public key.
Use a cryptographic hash function to generate the symmetric key k out of r. I would advise the use of sha256: k=sha256(r)
Encrypt you data with a block cipher like AES256 using a proper "mode" like CBC.
The advantage of this procedure is that you do not have to care about RSA paddings at all (and there is a lot of stuff that can go wrong with them). Please don't check the structure of r after decrypting, though, and just stuff if into the hash function as you otherwise might open yourself up to padding oracle attacks (akin to this one) that are beyond the scope of my answer though.
Note that for a real world scenario you have to care about authenticity of the data, too. The only common use case where encryption is mostly enough is "data at rest", i.e. if no data is transmitted over the network and you only care about physical theft of your data.
When one needs to encrypt longer plain text than a assymetric key typically random symmetric cipher block key is generated, for example, AES128 and then it is used to encrypt the data. At the end of a process symmetric key is encrypted with RSA public key and saved along with the cipher text.
A decryption consists of recovering symmetric key with a private RSA key and then using the former to decrypt the long message.
One of the reasons to do so is that RSA is much slower than, for example, AES. Another one is that block cipher has no limitation for a size of a message.
I have a question relating to the use of an Initialization Vector in AES encryption. I am referencing the following articles / posts to build encryption into my program:
[1] Java 256-bit AES Password-Based Encryption
[2] http://gmailassistant.sourceforge.net/src/org/freeshell/zs/common/Encryptor.java.html
I was originally following erickson's solution from the first link but, from what I can tell, PBKDF2WithHmacSHA1 is not supported on my implementation. So, I turned to the second link to get an idea for my own iterative SHA-256 hash creation.
My question comes in how the IV is created. One implementation ([1]) uses methods from the Cypher class to derive the IV where are the other ([2]) uses the second 16 bytes of the hash as the IV. Quite simply, why the difference and which is better from a security standpoint? I am kinda confused to the derivation and use of IVs as well (I understand what they are used for, just not the subtler differences), so any clarification is also very welcome.
I noticed that the second link uses AES-128 rather than AES-256 which would suggest to me that I would have to go up to SHA-512 is I wanted to use this method. This seems like it would be an unfortunate requirement as the user's password would have to be 16 characters longer to ensure a remotely secure hash and this app is destined for a cell phone.
Source is available on request, though it is still incomplete.
Thank you in advance.
The IV should not be generated from the password alone.
The point of the IV that even with the same key and plaintext is re-used, a different ciphertext will be produced. If the IV is deterministically produced from the password only, you'd get the same ciphertext every time. In the cited example, a salt is randomly chosen, so a new key is generated even with the same password.
Just use a random number generator to choose an IV. That's what the cipher is doing internally.
I want to stress that you have to store either the IV (if you use the first method) or a salt (if you use the second method) together with the ciphertext. You won't have good security if everything is derived from the password; you need some randomness in every message.
Cryptographers should generate IVs using a secure pseudo-random random number generator.
Application developers should use existing, off the shelf cryptography. I suggest that you use SSL with certificates to secure your network traffic and GPG to secure file data.
There are so many details that can make an implementation insecure, such as timing attacks. When an application developer is making decisions between AES 128 and AES 256 it is nearly always pointless since you've likely left a timing attack that renders the extra key bits useless.
My understanding is that Initialization Vector is just random input to encryption algorithm, otherwise you would always get same result for same input. Initialization Vector is stored together with cipher text, it's not secret in any way. Just use secure random function to generate initialization vector. PBKDF* algorithms are used to derive secret keys of desired length for encryption algorithms from user-entered passwords.
First implementation that you link to simply lets Cipher object to generate Initialization Vector. Then it fetches this generated IV to store it together with cipher text.
Second one uses part of hash bytes. Any approach that generates non-repeating IVs is good enough.
Most important property of IV is that it doesn't repeat (very often).
The IV is just a consequence of the use of block chaining. I presume that this is more than a simple API design question. I assume that you know that the reasoning for using it is so that the same plaintext will not show up as the same ciphertext in multiple blocks.
Think about recursion from the last block where the Nth ciphertext block depends in some way on the (N-1)th block, etc. When you get to the first block, 0th block, you need some data to get started. It doesn't matter what that data is as long as you know it before you attempt to decrypt. Using non-secret random data as an initialization vector will cause identical messages encrypted under the same key to come out as completely different ciphertext.
It's similar in concept to salting a hash. And that source code looks a little fishy to me. An IV should simply be fresh-at-encryption-time random bits dependent upon nothing, like a nonce. The IV is basically part of the encrypted message. If you re-encrypt identical data with identical key, you should not be able to correlate the messages. (Hey, think about the consequences of correlating by ciphertext length as well.)
As with everyone else here, I've always known IVs to be just chosen randomly using the standard algorithms for doing so.
The second reference you provided, though, doesn't seem to be doing that. Looks like he salts a password and hashes it. Then takes that hash and splits it up into halves. One half is the encryption key, one is the IV. So the IV is derived from the password.
I don't have any strong breaks for such a method, but it's bad design. The IV should be independent and random all on its own. Maybe if there's a weakness in the hashing algorithm or if you choose a weak password. You don't want to be able to derive the IV from anything else or it's conceivable to launch pre-computation attacks.
I am using PBE encryption to encrypt and decrypt some text on an Android application but I get the BadPaddingException: with the "pad block corrupted" message when I use the wrong private key to decrypt the text.
My question, since I am not well versed with encryption in Java, is if this is the normal behavior of the encryption API, because I need to do some logic in the case when the wrong key is entered, but I do not know the private key, nor do I store it anywhere (storing just the encrypted and decrypted check text).
Thanks,
Mihai
It is normal that most key mismatches result in a "bad padding error". But this is not 100% foolproof either. For instance, in the case of symmetric encryption with PKCS#5 padding (a very common way to pad data), about 0.4% of wrong keys will not result in a bad padding. The decrypted data will still be garbage, but, out of freak chance, that garbage turned out to end with a valid padding. Your application must not make it apparent whether a decryption failure is due to bad padding, or to garbage with freakishly valid padding: that information (whether the key is part of the 0.4% of keys which yield a proper padding) is a leak which can have severe consequences. There have been some attacks against SSL connections that way.
Yeah, less then ideal ( http://developer.android.com/reference/javax/crypto/BadPaddingException.html ). The decryption logic needs to strip the padding before it gets to the actual cypher-text and things go bad in that early stage.
In short, yes, BadPaddingException is what you should expect if the wrong password/key was used during decryption.
Edit: But as others have pointed out, this isn't something you should communicate out of your decryption code. It's simply a way of knowing that an incorrect key was used.