Re: Re Encryption

Can you encrypt the data as it is written to the DLT? Surely this is where the security risk is so this is where it should be solved?

JJ

MTeehan <MTeehan_at_DELETEME-wantree.com.au> wrote in message news:7vjvmh$vnt$1_at_centipede.wantree.com.au...
> I have a similar requiremernt.
> 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
> 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
> 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
>
> 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
> > > <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 - 23:02:49 CET