On Nov 14, 11:30 am, Bernard Dhooghe <dhoog...@yahoo.comwrote:
Is it a good idea to push operational constraints in a database
engine?
Why should it not be? To me the database is just another tool, and if
can serve particular purpose, there's little to be gained in
reinventing the wheel by rolling your own.
I understand that all clients can encrypt/decrypt without additional
tool, obfuscating is the challenge then (the question posted here).
So additional programming is needed (again, as with a home-made
encrypt/decrypt capability).
The original question was about key management, and I believe that
challenge essentially remains the same whether on chooses to use
database encryption (DB2 encrypt/decrypt) or client encryption (C,
Perl, Python, etc.).
Another drawback of using the available encrypt/decrypt routine is
that the encrypted info is in the DB2 log and the encrypt/decrypt
algorithm is, as far as I know, not given by IBM. How will tools that
process logs be able to tackle this?
How would log processing of encrypted data differ from processing any
other kind of binary data?
http://tinyurl.com/2k2hvh
"Creating indexes on encrypted data is a good idea in some cases.
Exact matches and joins of encrypted data will use the indexes you
create. Since encrypted data is essentially binary data, range
checking of encrypted data would require table scans."
In conclusion, maybe some design "team" must decide where to go with
first.
Hey, that's me :)
--
