Re: Re Encryption

I have a similar requiremernt.
[Quoted] We are concerned that since we are now backing up the entire DB to a DLT, anyone that manages to get their hands on any backup tape with a unix box can restore the database files and quite easily extract sensitive data. As a result we need to encrypt certain columns using an externally generated [Quoted] key which can be re-read at each database startup. While this would be possible with triggers or procedures, we would like some sort of a third party product that integrates seamlessly with Oracle8i. Trusted Oracle could [Quoted] do some of this stuff, but looks like its now a dead product - last release was in the early 7's.
Anyone with any ideas speak up!!
Regards
Mark

[Quoted] Andrew Longworth <Andrew_Longworth_at_bigfoot.com> wrote in message news:38172681_at_isoit370.bbn.hp.com...
> Andrew,
>
> Hi. I've not had any experience of any commercial packages for doing the
> encryption, but I know they are a problem to implement.
>
> The problem is that you cannot index encrypted data. The reason for this
is
> that such things as wildcards in searches will not work. You can extract
> SMITH and SMITHS by searching for SMITH%, but if encrypted, SMITH may be
> 'QWERTY123' and SMITHS may be 'ASDFG789' - they are very different and
there
> is no relationship between the encrypted versions as there is for the
> uncrypted versions (i.e. they share the same five letters). So any kind of
> indexing scheme that is used will not be able to make use of these data
item
> relationships.
>
> Another problem is that somewhere you will need to provide functionality
to
> decrypt that data - so if the users can get at the encrypted data then it
is
> likely they can get at the decrypting tool as well. It is better to stop
the
> users getting at the data they are not supposed to see in the first place.
>
> If you just want to encrypt data as it is transferred from one system to
> another (over public or insecure lines) then this is probably not a
database
> issue - try taking a look at SQL*Net (some method of encrypting here rings
a
> bell - but I am not sure) or some other layer that sits in the networking
> protocols below the database.
>
> I am sorry this doesn't answer your question directly - but I hope it is
of
> some use.
>
> Regards,
>
> Jason Judge
>
> P.S. Please feel free to copy this to the newsgroup - I don't have access
to
> it from where I am today.
>
> > -----Original Message-----
> > From: ANDREW_LONGWORTH_at_HP-Germany-om21.om.hp.com
> > [SMTP:ANDREW_LONGWORTH_at_HP-Germany-om21.om.hp.com]
> > Sent: 27 October 1999 15:43
> > To: jason.judge_at_virgin.net
> > Subject: Re: URGENT : Encryption
> >
> > Cheers.
> > Is it possible you could give me some ideas on these methods or tell me
> > where I can find out about them, as I have never heard of these before.
> >
> > Jason Judge <jason.judge_at_virgin.net> wrote in message [Quoted]
> > <7v5dop$co4$1_at_nclient13-gui.server.virgin.net>...
> > > You could encrypt the data - but how do you get it back out again?
> > Enough
> > > must be left uncrypted to allow you to search for the information you
> > need.
> > >
> > > The best security is to hide the data in other ways - use roles,
grants,
> > > packages etc.
> > >
> > > Regards,
> > >
> > > Jason Judge
>
>
>
Received on Mon Nov 01 1999 - 12:39:59 CET