File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Security and the fly likes Encryption of long strings Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Engineering » Security
Bookmark "Encryption of long strings" Watch "Encryption of long strings" New topic
Author

Encryption of long strings

D. Ogranos
Ranch Hand

Joined: Feb 02, 2009
Posts: 214
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.
Lester Burnham
Rancher

Joined: Oct 14, 2008
Posts: 1337
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
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?
James Sabre
Ranch Hand

Joined: Sep 07, 2004
Posts: 781

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
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).
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Encryption of long strings