[EMAIL PROTECTED] wrote:
[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)
.
Example:
Cash_Ur_check is in the business of cashing checks. To cash a check,
they ask you for "sensitive information" like SIN, bank account number,
drivers licence number, etc. They use the information to query
Equifax or the like to see if the person has a good credit rating, if
the rating is o.k. they cash the check. They keep all the information
in the database, because if the client comes back 2 months later, they
will send the same query to Equifax to see if the credit rating hasn't
changed.
These sensitive information are "indexes" to external databases (but
Cash_Ur_check doesn't directly connect to these other databases).
Cash_Ur_check doesn't need to use these data as indexes. Cash_Ur_check
can use first/middle/last name of person as an index, or attribute some
random number to the person, or something else, they should not use the
SIN to identify a person. They should not do searches on SIN to find a
person given his SIN.
Sure, but Equifax should.
I have many other examples in mind, which I came across in the real world.
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.
No, of course I would sit down with the client and the software developers
and examine their needs and constraints suggest how they can structure
their data in a better way. I've done it several times over the years.
There is no universal answer, but in my experience I found there is often
good solutions.
Let me throw back a precise question to you, to see if you disagree with
what I said. Are you saying that it is often inevitable to index
"sensitive" data? That is, are you saying that you often have to use
"sensitive" data as the basis of searches?
Yes.
--
>>>ApacheCon Europe<<< http://www.apachecon.com/
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]
