1

I am trying to encrypt few database columns (string values) using Java AES algorithm. This is to protect certain sensitive data. For some users these data should decrypted.

In Java AES encryption, if my input character length is 60, I am getting encrypted string length as 88.

But I don't want a change the length of the encrypted data. We have huge amount to tables and many applications are using those tables. We want to minimize the impact of encrypting certain fields in the tables.

Is there is any recommended solution? OR is there is any recommended algorithm, code sample, etc?

Thanks, Prabakaran N

  • 1
    Code sample, i.e. chaining mode used. You are most likely doing AES-CBC which will add 128 bit (IV) to your data padded itself padded to 128 bits. Good databases offer colum encryption features, you may want to investigate that. – Bruno Rohée May 28 '14 at 10:54
1

What is described in the question is Format Preserving Encryption. However, expect a steep learning curve, and a severe lack of ready made implementations.

0

Depending on what security you are trying to achieve, this might not be possible: A certain amount of output expansion is necessary to provide protection against certain attacks.

Consider the case of a database that stores health records in the form of a list of illnesses that a person is affected by; also, consider that "high blood pressure" encrypts to 0x1234abcd using "plain" AES (or any block cipher) in ECB mode. (ECB has other problems besides being deterministic, but I'll focus on that aspect here.)

An attacker might not know the meaning of 0x1234abcd, but he can easily identify all patients sharing that record!

More elaborate attacks are possible if the attacker has write access to the database: They could, for example, insert random illnesses, look at the corresponding ciphertexts and build a table with plaintext-ciphertext correspondences.

This is why block ciphers are almost exclusively used in a mode of operation that expands the input by a certain length: The expansion is (among other things) necessary to allow multiple message encryption under a single key.

Depending on the content of your database, the mentioned attack might or might not be a problem, but in the overwhelming majority of all applications, it is desirable ECBto use a CCA-secure cryptosystem, which is necessarily probabilistic, and therefore also length-extending.

0

You could consider using a cipher in CTR mode, which essentially turns it into a stream cipher. The output length should equal the input length, but you still need to come up with a unique nonce for each record. If you have a unique identifier for each record, you can use that to generate your nonce for the counter. Be careful: using the same nonce twice with the same key allows an attacker to trivially recover the plaintext.

  • The caveat here is that this would require the ability to store/use the output in its binary form. If that is not possible for this application and the ciphertext does need to be string encoded, it will still be longer than then plaintext message in this format. – Xander Sep 21 '14 at 2:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.