How do I encrypt a string and get a equal length encrypted string?

Question

My problem is the following:

In an existing database I want to encrypt data in a couple of columns. The columns contains strings of different lengths.

I don\

Answer 1

Within your constrants, I would use AES in CFB mode, which turns it into a stream cipher and the output length will be the same as the input length. Unless you're storing the strings in blobs, you'll need to hex or base64 encode the output to make it char friendly, which will be a 100% or 33% increase in length.

One .NET implementation is here.

Answer 2

This is usually impossible, because (in a naïve way) you would expect the encrypted string to hold more information than the plain text.

Vague ideas for solving your problem:
- Map your number onto a shorter text string: two digits could map into one character.
- Can you avoid encrypting the first x digits?
- What are the possibilities for encrypting it as an integer rather than text?

Answer 3

Any block cipher will do. Essentially, you input a fixed length block and get a similar size encrypted block back. The cipher is a permutation from {0,...,2^blocklength} to {0,...,2^blocklength}. (The input length has to be padded to a block length boundary.)

The problem here is that if the columns are text, you cannot necessarily place binary cryptotext in them and you'll have to encode the data to a text format such as base64 (33% size increase).

AES is a block cipher standard that is widely available.

Answer 4

Ideally, if the existing columns are larger than a single block in a standard block cipher (16 bytes for AES, 8 bytes for TDES), then you could encrypt in CTS (cipher text stealing) mode. Unfortunately, .net does not support CTS in any of its included algorithms. :-(

Normally CTS uses a random IV that would have to be stored along with the ciphertext, but you can just use the row ID or even a constant value if you don't mind identical plaintext values encrypting to identical ciphertext.

Answer 5

You might look for a tweakable block cipher. If your rows have a unique identifier (e.g. a primary key) then the unique identifier can be used as a tweak. The advantage of this kind of encryption is that you don't need any IV's to randomize the encryption. Even if a column contains the same value multiple times, this value gets encrypted differently, because of the tweak.

A less secure solution is to use a block cipher in counter mode and use the unique identifier to compute the counter. But this mode has a severe disadvantage: You can't securely reencrypt fields unless you also change the unique identifier.

Since both cases don't randomize the ciphertext, it is possible that an attacker can observe if a certain field has changed. This might leak some valuable information. Also note that neither case gives you any data integrity. Even if an attacker can not decrypt information, he might still be able to change it to his advantage.

Answer 6

You should take a minute and think of the real problem you're trying to solve. I've seen very few instances where database encryption was really nessecary, since information rarely flows directly from the database to an end user.

If you need to protect content of the database, then you should perhaps look into its standard access control mechanisms instead.