[EMAIL PROTECTED] wrote:
| Oracle, for example, provides encryption functions, but the real problem
| is the key handling (how to make sure the DBA can't get the key, cannot
| call functions that decrypt the data, key not copied with the backup,
| etc.).
| There are several solutions for the key management, but the vendors
should
| start offering them.
I would argue that the real problem is that encryption slows large
searches (is percieved to slow large searches, anyway.)
Adam
Yes, encrypting indexed columns for example is a problem. But if you
limit yourself to encrypting sensitive information (I'm talking about
stuff like SIN, bank account numbers, data that serves as an index to
external databases and are sensitive with respect to identity theft),
these sensitive information should not be the bases of searches.
If they are not he basis of searches, there will be no performance
problems related to encrypting them.
If they are indexes to external databases, then they are the basis of
searches in those databases, by definition.
So my answer to people that have the perception you mentioned is that if
you want to encrypt sensitive information and that would cause performance
problems, then there are problems with your data architecture privacy wise
(you should re-structure your data, use it differently, etc.).
Not a very satisfactory answer.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
