[cryptography] Questions about crypto in Oracle TDE

Kevin W. Wall kevin.w.wall at gmail.com
Thu Nov 8 23:17:08 EST 2012


On Thu, Nov 8, 2012 at 6:22 PM, Morlock Elloi <morlockelloi at yahoo.com> wrote:
> We have been using a different approach for securing particular fields in the database.
>
> The main issue with symmetric ciphers inside (distributed) systems is that the encrypting entity is always the most numerous weak point. Whoever subverts your input flow - and there are lots of opportunities there - gets keys to everything. Your distributed system is not really distributed - it's mostly distributing vulnerabilities.
>
> However, if you use asymmetric crypto (say, 1024 or 2048-bit RSA), give only public key(s) to encrypting flows, and reserve the secret key(s) for modules that need the actual plaintext access (a rare situation in practice), then:
>
> - the storage size remains the same;
>
> - you can use the first 512 bits or so for indexing (you may get a collision once before the Universe cools down, or whatever your belief about the curvature is.)
>
> - there are no ECB issues (for field sizes < 1024 or 2048 bits, most are);
>
> - the extra CPU cost for modular arithmetic (to insert or search) is negligible (at least in use cases we've seen so far);
>
> - the security requirements on the input side drop down big time. You can (continue to) have bozos code your 'apps'.
>
> More philosophically, the database is just a wire with a delay. You would never directly use symmetric keys in other communications (by sharing them under the table), would you?

They are using Oracle 10.2 where Oracle TDE only supports AES and
3DES, so if I wanted to do something
like this, TDE is not going to be the solution, in which case I'm not
going to have the encrypt done by
the DB; instead, I would have the application do it using our standard
crypto libraries.  TDE was being
looked at because from the application's point of view, it is transparent.

I think that doing the encryption / decryption in the application is
more secure (much better
separation of duties; the DBA can't decrypt the tables), but it is
also more effort.  There's a
security vs. effort trade-off.  I'm just trying to determine where the
acceptable risk level is
at and that means understanding how TDE works.

-kevin
-- 
Blog: http://off-the-wall-security.blogspot.com/
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We *cause* accidents."        -- Nathaniel Borenstein



More information about the cryptography mailing list