Skip site navigation (1) Skip section navigation (2)


From: Christopher Browne <cbbrowne(at)acm(dot)org>
To: pgsql-admin(at)postgresql(dot)org
Subject: Re: HIPAA
Date: 2004-03-08 23:51:56
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
Martha Stewart called it a Good Thing when listsubscriptions(at)oghma(dot)on(dot)ca (Gorshkov) wrote:
> On March 8, 2004 09:07, Andrew Sullivan wrote:
>> On Mon, Mar 08, 2004 at 12:07:23PM +0000, Silvana Di Martino wrote:
>> > This seems to give to this "db encryption" issue the status of
>> > "global relevance" that would deserve a more systematic
>> > approach. I mean: no homegrown solutions - rather have the
>> > community to develop a specific, standard extension of PostgreSQL
>> > and put it into the distro.
>> Just to throw another wrench into the works, you might want to
>> think about some of the observations on what data you _really_ need
>> that are in Peter Wayner's _Translucent Databases_ (Flyzone Press,
>> 2002.  ISBN 0-9675844-1-8).  Many of the techniques are not
>> particularly novel, but the discussion in the beginning about
>> deciding just which data you _really_ need is, I think, very
>> helpful.  There's a tendency to collect data just because one can,
>> and the new data protection laws are an attempt to find a techno
>> fix to the problem.  (I still like it that someone is spending some
>> time on improving the crypto stuff, though.)
>> A
> Many, many moons ago when I was young and stupid, I was in an
> intelligence trade in the Cdn Navy - COMINT/SIGINT.
> it never ceases to amaze me at how consistantly people underestimate
> the information that can be taken from a datum - especially when
> aggrigated with data from other sources.

I'd like to think you misspelled "aggravated" there :-)

The US situation of SSN numbers being widely used as personal
identifiers has been quite spectacularly disastrous for personal

My credit union finally "saw the light" a couple of years ago, and
decided to use their own randomly generated account IDs; I gather that
many (most?) US companies have been taking the same strategy with
employee and customer account numbers.

For different organizations to use different keys is not a total
panacea, but the lack of uniqueness has been pretty harmful.

Wayner's book is certainly pretty good on the subject; it may not be a
NIST/FIPS/ISO standard, but it certainly presents the security issues

What is pretty clear is that this kind of application requires that
there be a use of data encryption that is controlled _outside_ the
database layer.  

There may be attempts made to sell the notion that the Right Solution
requires using some particular product, such as Trusted Oracle; you
can expect that to be pressed by vendors that have products they want
to push.  Unfortunately, this may well worsen security, by putting
trust in a layer that cannot provide security.
let name="cbbrowne" and tld="" in name ^ "@" ^ tld;;
"I think we might have been better off with a slide rule."
-- Zaphod Beeblebrox

In response to

  • Re: HIPAA at 2004-03-08 22:25:34 from Gorshkov

pgsql-admin by date

Next:From: Michiel LangeDate: 2004-03-09 07:18:37
Subject: Re: Upgrading
Previous:From: Silvana Di MartinoDate: 2004-03-08 22:43:37
Subject: Re: Database Encryption (now required by law in Italy)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group