This week's book giveaway is in the Java 8 forum. We're giving away four copies of Java 8 in Action and have Raoul-Gabriel Urma, Mario Fusco, and Alan Mycroft on-line! See this thread for details.

I'm a complete newb when it comes to using encryption (I've written some password hash methods but never used real encryption/decryption). Now one of our projects requires encrypted data. We have a crypto class which is supposed to do this, but it was written long before my time (was written by a collegue who's not around anymore). The encrypt method works fine for short strings but for longer ones it fails. I've tried to cut it down to its essentials, which are:

When run with the shortTest string, this program works fine, printing out the encrypted data length, and at the end says that the decrypted data is the same as the original data. However with the longTest string an exception is thrown in the encrypt method: "Data must not be longer than 245 bytes".

So, I googled around but the solutions I found really created more confusion than they helped. I suspect that using a mode (and padding scheme?) for the algorithm transformation might make it work for longer strings, but I couldn't find a simple WORKING example for this :/ My hope is that someone here could suggest a working combination. The algorithm should remain RSA.

Some other ideas:
- perhaps this is just a problem with the provided implementation of the RSA algorithm? And another provider might offer a working solution.
- or I could just cut long strings into parts and encrypt those.

RSA can only be used to encrypt data that is no longer than the RSA key size. With a key size of 2048 bits that would be somewhat less than 256 bytes. You could use an even larger key size, but that would make the process rather slow - RSA isn't well suited for encrypting large data sizes. The usual approach would be to use a symmetric cipher like AES or Triple-DES, and then to use RSA just to encrypt the AES/Triple-DES key.

D. Ogranos
Ranch Hand

Joined: Feb 02, 2009
Posts: 214

posted

0

So to encrypt strings of any size and store them in the database, I would basically need two fields: one for the (symmetric) encrypted data, and one for the (asymmetric) encrypted key, correct? And the key to encrypt the data would be randomly generated?

You say this is the usual approach, are there severe disadvantages to the other method of encrypting the long string in parts and storing the concatenated results?

D. Ogranos wrote:So to encrypt strings of any size and store them in the database, I would basically need two fields: one for the (symmetric) encrypted data, and one for the (asymmetric) encrypted key, correct? And the key to encrypt the data would be randomly generated?

That would be one way but I would use the approach recommended in section 13.6 of "Practical Cryptography" by Fergusen and Schneier published by Wiley. In essence, this goes a little further and generates the session key from the digest of a random array of bytes. The random array of bytes is encrypted using RSA and not the actual session key.

Also, since a symmetric cipher is being used one should used CBC mode. One can then use a random initialization vector (IV) or one can use the random array of bytes to generate the IV.

All this, the RSA encrypted random vector, the iv and the symmetric encrypted data can be written to one BLOB without the need for explicit separate 'fields'.

You say this is the usual approach, are there severe disadvantages to the other method of encrypting the long string in parts and storing the concatenated results?

If the clear text is only just a bit bigger than the RSA modulus then, apart from some complexity in working out how to partition your clear text, there is not a big problem with just using this approach but you must make sure you use PKCS1 padding and you will need to partition the cleartext into lengths of less than or equal to the modulus length in bytes - 11 (the overhead associated with PKCS1 padding). If your clear text is very long then since RSA is a very slow algorithm then your performance could be very very poor.

Retired horse trader.
Note: double-underline links may be advertisements automatically added by this site and are probably not endorsed by me.

D. Ogranos
Ranch Hand

Joined: Feb 02, 2009
Posts: 214

posted

0

Ok thanks.

I went with the second option of encoding the string in parts. The method isn't used frequently so performance shouldn't be a problem (we only really had the problem with longer strings in one or two of multiple input fields, rest can be encrypted normally).