[cryptography] Questions about crypto in Oracle TDE
thierry.moreau at connotech.com
Fri Nov 9 15:46:07 EST 2012
Kevin W. Wall wrote:
> Thanks for answering.
> On Thu, Nov 8, 2012 at 1:09 PM, Adam Back <adam at cypherspace.org> wrote:
>> I'd guess they mean salt is pre-pended to the plaintext and then presume eg
>> then salt + plaintext encrypted with AES in CBC mode with a zero IV. That
>> would be approximately equivalent to encrypting with a random IV (presuming
>> the salt, IV and cipher block are all the same size) because
>> CBC-Enc( iv = Enc( salt ), plain ) == CBC-Enc( iv = 0, salt || plain )
> So what, if anything, do you think they might be using for padding?
> No padding at all? PKCS5 padding? Something else?
>> Now for indexing to set iv = 0 and salt = "" that might not be ideal as its
>> basically ECB for the first plaintext block. Particularly not good if the
>> plaintext is larger than the cipher block size and if there are repeats in
>> the first blocks worth of the plaintext.
> So for an SSN treated as a 9 char string (72-bits), for AES, that
> should not be a problem then since AES' block size is 128-bits, right?
> But would be a potential issue if used with 3DES since it's block
> size is only 64-bits.
>> IMO this fixed IV for searchability/indexability crypto pattern is a common
>> mistake. I prefer and consider it more secure to use a (keyed) MAC of the
>> plaintext as the index, and then encrypt the plaintexts conventionally with
>> a random IV.
> I agree that it's more secure. In particular, it's a lot easier to
> provide separation
> of duties and make it so that a DBA can't just dump the tables using SELECT,
> which I am pretty sure that they still could do with Oracle TDE.
> I was only considering it because it seemed like it was the easiest way
> to get from point A (plaintext SSNs) to point B (encrypted SSNs). Been
> trying to get that done for almost 2 yrs. They've been putting it off because
> of the supposed effort and using TDE should minimize their development
> effort. The question is whether TDE leaves us with acceptable risk,
> hence my attempt to better understand it.
... along the same line of thoughts as Ian G, I guess ...
I was exposed to this requirement a few years ago (the regulatory
mandate to encrypt SSN -- social security numbers -- in the database but
still maintain index searches).
I quickly guessed the requirement originated from a misunderstanding of
cryptography "laws of physics." You just can't have your cake and eat
it. You just can't encrypt a data field and use it as if in cleartext.
Moreover, if you want any incremental security, you want your attacker
determined-enough-to-copy-the-database-contents to be isolated from the
decryption key. In the requirement, nothing points to how this
incremental security is gained (e.g. one can imagine that encrypted
backups are kept separate from the backup decryption key and bingo you
get some auditors points). Will you put an HSM to do the index
decryption in order to prevent malignant host code from accessing SSN in
I guess the requirement originates from auditors with the expectation
that if you have AES so-many-bits you get X bonus points, without paying
attention to key management.
In short, not a use case for good crypto protections no matter what. So,
I agree with "the easiest way to get from point A to point B."
Application-level security breaches deserves application-level
countermeasures. IT security is a hindrance.
- Thierry Moreau
CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1
More information about the cryptography