Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have some columns in some tables that are sensitive and would like to protect them "anyways". Also, since Azure SQL demands application level encryption, we have to roll our own. There would be a single application-wide AES128 'master key' (=secret bits, stored/accessed securely only by application binary at runtime). Each row in each table would use it's own row-specific IV.

I'm looking for strong reasons anyone would want to vote against AES128 as a suitable cipher for the above (I think it is).

share|improve this question
Determining the effectiveness of cryptographic protection is all dependent on what you are trying to protect, and from what/whom. Otherwise this question is unanswerable. Can you update this to explain what you are wanting to protect and from what kinds of attack(er)s? – Steve Jan 24 '13 at 8:32
I'm very curious how you are accomplishing #1 on the list in a cloud environment. The only way I really know to pull this off is do cryptographic operations against a hardware TPM. – AJ Henderson Jan 24 '13 at 14:11
To reiterate a point in Thomas' answer, do not reuse your IVs. There is no such thing as a "good middle ground" with crypto. Your implementation is either secure or it is broken, and IV reuse is broken, broken, broken. Period. – Stephen Touset Jan 25 '13 at 0:37
up vote 4 down vote accepted
  • You are sharing IV: cells from a given row will use the same IV. This is bad. Don't do that.

  • You use CBC; this is a mode which is known to have a few security issues (in particular, it is sensitive to "how much random" the IV is), and it will involve padding (since CBC encrypts only full blocks, you have to extend the data elements to the next size which is a multiple of the block size).

  • If you modify one of the encrypted cells, then you must reencrypt it. If you use the same key and same IV, then you have lost (security wise). Therefore, you must alter the IV for that cell. If you use the same IV for the whole row (which is bad), then you must reencrypt the other cells of the row as well.

  • A MAC is needed if potential attackers could modify the data in place; it is not if attackers are assumed to be passive only. Note that an attacker could modify the encrypted data in order to observe how your system reacts, and try to deduce things about the encrypted data. As a general rule, you are better off with a MAC than without.

I would therefore suggest altering your scheme into the following:

  • Use an authenticated encryption mode with associated data which combines encryption and integrity, like EAX or GCM.
  • User a per-cell IV, stored in the cell itself. EAX and GCM do not need a random IV, only an IV which is never repeated (for a given key), so you could use a simple counter: maintain a system-wide global counter, incremented every time you need to encrypt a new cell value (when you allocate a cell, and also when you replace the contents of the cell); store the counter in the cell itself (that way, a 64-bit counter will be enough, no need to go to a full 128-bit value).
  • AEAD modes include an integrity check which is computed over the data which is encrypted and some additional data which you can choose (the "additional data" is used for computation but is not stored in the encrypted result; you must provide it again upon decryption, so that the integrated MAC can be checked). Encode in that "additional data" the row and column numbers for the cell. That way, an evil active attacker will not be able to silently swap cell contents (the MAC will be OK only if the cell contents are still where they should be).

Also, don't indulge in the "rotating master key" fantasy. The only reason why you would have to change the master key is in case it was stolen; and, in that case, you must change it right away for the whole database. No need for a smooth, gradual transition: this is an emergency situation. Therefore, no need to keep a version number for the master key. An identifier for the cryptographic algorithm, on the other hand, is a good idea; it can fit on a single byte (or even less than that).

Encrypt the binary data, not a Base64 encoding of it. Encryption output will be binary anyway. Applying Base64 on the input will just make the data 33% larger, for no good reason.

share|improve this answer
Great argument on rotating master key. Making it seamless was overcomplicating many things. I'll leave it as an offline/disaster operation. I'll leave the key-version field in there is we ever go there. I need to read on EAX and GCM. BTW, I also clarified my question drastically (added the system wide diagram + loose threat model). Does that raise any additional concerns? – DeepSpace101 Jan 25 '13 at 0:23
I have to thank you for introducing me to A-E crypto algorithms. GCM looks promising (though on .NET/C# it's only via a 3rd party library: OCB's benchmarks look great and seems it's licensing has been relaxed recently ( Too recently actually; doubt any implementation will be ready for months. – DeepSpace101 Jan 25 '13 at 6:10

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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