Securely Encrypt 64bits w/o per element overhead?

问题:

I have a long in my database. I like to encrypt it. I could use xor but that is not very secure as a pattern can be seen and the xor value may be revealed. IIRC AES has a key and an initialize vector (IV) which can be thought as a seed (when talking about random numbers). I believe the IV should be randomly made. This is so a different pattern occurs when encrypting the same data with the key.

How might i securely encrypt 64bits? I suspect it may not be truely secure w/o a random IV/seed. But i do not want to store it. At the moment the other option i can think of is having a cryptographic RNG and running it say 10000 times if the value is the 10000th index then xor the value. But performance wise that doesn't scale.

How do i properly and securely encrypt 64bits w/o storing extra bits for each 64bits? I'm thinking maybe feed a crypto RNG with (seed xor index) run it X times and xor that with the value. But i have a feeling someone has a better idea?

回答1:

AES has a block size of 128 bits, so if you use that, you'll end up encrypting as much padding as meaningful data.

You could use DES (or, preferably, 3DES), since its block size is 64 bits.

The initialization vector should be difficult for the attacker to predict, but it's not actually secret like the key is, so it can be chosen algorithmically; see, for example, the ESSIV algorithm used to generate per-sector IVs for disk encryption. You could use the same scheme — just replace the "sector number" with something analogous like the record's unique ID number — so you don't actually have to store the IV, just regenerate it using the algorithm at decryption time. (But if you ever modify the record's unique ID, make sure you decrypt and re-encrypt with the new IV!)

You can avoid using an IV entirely if you encrypt using ECB mode, but that's not really a good idea. For a given key, the same plaintext always encrypts to the same ciphertext in ECB mode, so an attacker would be able to see that your secret number is the same in two records even if he can't determine the actual value. Assuming that you're not using different keys for each record, you want to have a different IV for each record.

回答2:

If you have an index of some kind, you can use CTR mode encryption, with the index as a NONCE. In that case you can safely use AES. Be warned that there is an important caveat: if you use the same NONCE a second time then you leak the plain text (because you can retrieve the key stream). If an attacker can view your system in time, this could also hold for encrypting a new value into the database.