Message-Id: <22528.293309@fatcity.com> From: "Jamadagni, Rajendra" Date: Tue, 10 Sep 2002 11:10:40 -0400 Subject: RE: using obfuscation This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-708c0fe7-f1f4-498b-8be0-3872cd38fdc0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C258DC.39928BF0" ------_=_NextPart_001_01C258DC.39928BF0 Content-Type: text/plain; charset="iso-8859-1" Can you create a Function based index on that column? That could be of use ... Raj ______________________________________________________ Rajendra Jamadagni MIS, ESPN Inc. Rajendra dot Jamadagni at ESPN dot com Any opinion expressed here is personal and doesn't reflect that of ESPN Inc. QOTD: Any clod can have facts, but having an opinion is an art! -----Original Message----- From: Steiner, Randy [mailto:RASTEIN@NYCT.com] Sent: Tuesday, September 10, 2002 11:58 AM To: Multiple recipients of list ORACLE-L Subject: RE: using obfuscation Don, It seems like a real good idea, but what am I putting inside my call to the encrypt function in my Create View statement? Randy -----Original Message----- Sent: Tuesday, September 10, 2002 10:13 AM To: Multiple recipients of list ORACLE-L Subject: Re: using obfuscation << File: Card for Don Jerman >> What about... create view my_data as select de_encrypt(sensitive_data) as clear_sensitive_data where sensitive_data = encrypt('CLEAR TEXT') ? This lets you create an index on the sensitive data without decrypting it, and the function need only be called once on the clear text. Caveat: no idea if this should work :) "Steiner, Randy" wrote: > Hi all, > > I have downloaded the Metalink Notes on implementing dbms_obfuscation. I am > using multiple front ends on the database, so the way I plan to implement > the de-encryption is with a de-encrypt function in a view. > > Create View my_data > AS > Select de_encrypt(sensitive_data) AS sensitive_data > ,other_data > FROM original_table > ; > > If I select from the view with a where clause on other_data, the response > time is fine. If I select from the view with a where clause on > sensitive_data, I do a full table scan and which takes about 15 minutes. > The de-encrypt function is copied from a Metalink note, nothing fancy. > > Since I have various front ends, I can not de-encrypt the data in the front > end. The only way I can think of is with the function in a view, but the > response time is unacceptable. Does anyone have any thoughts on this? > > Thanks > Randy > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > -- > Author: Steiner, Randy > INET: RASTEIN@NYCT.com > > Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 > San Diego, California -- Public Internet access / Mailing Lists > -------------------------------------------------------------------- > To REMOVE yourself from this mailing list, send an E-Mail message > to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in > the message BODY, include a line containing: UNSUB ORACLE-L > (or the name of mailing list you want to be removed from). You may > also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Steiner, Randy INET: RASTEIN@NYCT.com Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). ------_=_NextPart_001_01C258DC.39928BF0 Content-Type: text/html; charset="iso-8859-1" RE: using obfuscation

Can you create a Function based index on that column? That could be of use ...

Raj
______________________________________________________
Rajendra Jamadagni              MIS, ESPN Inc.
Rajendra dot Jamadagni at ESPN dot com
Any opinion expressed here is personal and doesn't reflect that of ESPN Inc.
QOTD: Any clod can have facts, but having an opinion is an art!


-----Original Message-----
From: Steiner, Randy [mailto:RASTEIN@NYCT.com]
Sent: Tuesday, September 10, 2002 11:58 AM
To: Multiple recipients of list ORACLE-L
Subject: RE: using obfuscation


Don,

It seems like a real good idea, but what am I putting inside my call to the
encrypt function in my Create View statement?

Randy

 -----Original Message-----
Sent:   Tuesday, September 10, 2002 10:13 AM
To:     Multiple recipients of list ORACLE-L
Subject:        Re: using obfuscation

 << File: Card for Don Jerman >> What about...

create view my_data as select de_encrypt(sensitive_data) as
clear_sensitive_data where
sensitive_data = encrypt('CLEAR TEXT') ?

This lets you create an index on the sensitive data without decrypting it,
and
the function need only be called once on the clear text.

Caveat: no idea if this should work :)

"Steiner, Randy" wrote:

> Hi all,
>
> I have downloaded the Metalink Notes on implementing dbms_obfuscation. I
am
> using multiple front ends on the database, so the way I plan to implement
> the de-encryption is with a de-encrypt function in a view.
>
> Create View my_data
> AS
> Select de_encrypt(sensitive_data)  AS sensitive_data
> ,other_data
> FROM original_table
> ;
>
> If I select from the view with a where clause on other_data, the response
> time is fine. If I select from the view with a where clause on
> sensitive_data, I do a full table scan and which takes about 15 minutes.
> The de-encrypt function is copied from a Metalink note, nothing fancy.
>
> Since I have various front ends, I can not de-encrypt the data in the
front
> end.  The only way I can think of is with the function in a view, but the
> response time is unacceptable.  Does anyone have any thoughts on this?
>
> Thanks
> Randy
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Steiner, Randy
>   INET: RASTEIN@NYCT.com
>
> Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
> San Diego, California        -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from).  You may
> also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Steiner, Randy
  INET: RASTEIN@NYCT.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

------_=_NextPart_001_01C258DC.39928BF0-- ------=_NextPartTM-000-708c0fe7-f1f4-498b-8be0-3872cd38fdc0 Content-Type: text/plain; name="ESPN_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ESPN_Disclaimer.txt" *********************************************************************This e-mail message is confidential, intended only for the named recipient(s) above and may contain information that is privileged, attorney work product or exempt from disclosure under applicable law. If you have received this message in error, or are not the named recipient(s), please immediately notify corporate MIS at (860) 766-2000 and delete this e-mail message from your computer, Thank you.*********************************************************************1