> [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.
My terminology might have been misleading. By "indexes to external databases", I don't mean that the application that uses the database actually talks to the external databases (it doesn't use the info as a key to that external database) --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
