encrypted tapes (was Re: Papers about "Algorithm hiding" ?)

[Ben Laurie]

astiglic at okiok.com wrote:
>>astiglic at okiok.com 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 majordomo at metzdowd.com