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

[astiglic at okiok.com]

> On Wednesday 08 June 2005 21:20, astiglic at okiok.com wrote:
>> 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.
>
> I can name at least one obvious case where "sensitive" data -- namely
> credit
> card numbers -- is in fact something you want to search on: credit card
> billing companies like CCbill and iBill.  Without the ability to search by
> CC#, customers are pretty screwed.
>
> That said, I will never buy the "only encrypt sensitive data" argument.
> In my
> experience, you *always* end up leaking something that way.

There are exceptions, I grant you that, but my hypothesis is that in most
cases you can do without indexing on the "sensitive" data you have.

Encrypting everything in your database, I say that will never work.  If
you do that, then you will have performance trouble, and nobody want's
that.  You can do stuff like encrypt everything at the OS level, but that
doesn't help protect database backups and it doesn't prevent your DBA to
look at data he's not supposed to.  If you encrypt everthing at the DBMS
level or at the application (client or middleware) level, than you cannot
encrypt indexed data.

--Anton
--Anton



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com