Ah, I see.  The business folks are happy that whoever wrote
the previous bit has successfully 'encrypted' their data, and
your job is to make that bit perform.

A familiar refrain.  ;)

Jared

On Fri, 2003-10-24 at 06:34, Jamadagni, Rajendra wrote:
> Jared, I know, but this is a legacy code that is attached to a hardware ticker tape 
> that scrolls message that it received. The code I supplied has couple of other 
> operations removed (for obvious reasons) but these steps are required because the 
> hardware chip in the ticker box won't recognize it.
>  
> BTW, I have successfully used RC4 from your site in past to implement encryption.
>  
> HTH Some
> Raj
> 
> -----Original Message-----
> Sent: Thursday, October 23, 2003 7:06 PM
> To: [EMAIL PROTECTED]
> Cc: Jamadagni, Rajendra
> Importance: High
> 
> 
> 
> Raj, 
> 
> I'll try to be tactful here, but that isn't encryption. It only looks like 
> encryption, and is in fact very easy to break. 
> 
> Check out the article at 
> http://www.cybcon.com/~jkstill/util/encryption/encryption.html 
> 
> There are PL/SQL implementations of RC4 and Blowfish there. RC4 is a stream cipher 
> and Blowfish is a block cipher.  Either would suit your purpose. 
> 
> Blowfish is there courtesy of Craig Munday. 
> 
> RC4 is there courtesy of a leak at RSA, but it's in the public domain now, so that 
> doesn't matter anymore. 
> 
> Also check Pete Finnigans site:  http://www.petefinnigan.com/ 
> 
> HTH 
> 
> Jared 
> 
> 
> 
> 
> 
>       "Jamadagni, Rajendra" <[EMAIL PROTECTED]> 
> Sent by: [EMAIL PROTECTED] 
> 
> 
>  10/23/2003 02:54 PM 
>  Please respond to ORACLE-L 
> 
> 
>         
>         To:        Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> 
>         cc:         
>         Subject:        UTL_RAW and slowness
> 
> 
> 
> Hi all, 
> 
> I am experimenting with a block of pl/sql code (wrote myself) that uses utl_raw to 
> perform xor operation. (Note to Jared and Mladan, I can't use Perl on production 
> boxes, so don't even go there). 
> 
> 
> I take a message, encrypt 1 character send it out on a wire using utl_tcp. After 
> every 128 bytes, I flush the tcp connection. While this works fine and within our 
> acceptable range for smallish messages (up to 20-25K in size), it nearly kills 
> itself when working with larger messages (80k+). 
> 
> 
> Initially I could encrypt 128 characters (including conversion from/to utl_raw) in 
> about 50ms. Bt this increase progressively. When I reach about 98000 to 99000 range, 
> it takes about 16 seconds to encrypt 128 characters. 
> 
> 
> I have logged tar with Oracle, but does anyone know if one could do a block 
> encryption (can't use standard algorithms, this is custom) like encrypt 128 
> characters at a time instead of 1 ... 
> 
> 
> The skeleton code looks like this ... 
> 
> 
> msglen := LENGTH (msg_text); 
> nCharsSent := 0; 
> p('Encrypting data...'); 
> FOR i IN 1 .. msglen 
> LOOP 
>  ntcpchar := ASCII (SUBSTR (msg_text, i, 1)); 
>  r_chr    := utl_raw.cast_to_raw(CHR(ntcpchar)); 
>  nenctcpchar := TO_NUMBER(utl_raw.bit_xor(r_chr,r_key),'xxxx'); 
>  tcpmsglen := UTL_TCP.write_text (gv_tcp_conn, CHR(nenctcpchar), NULL); 
>   nCharsSent := nCharssent + 1; 
>  IF MOD(ncharssent,128) = 0 THEN 
>    p('Before Flush ...'); 
>    UTL_TCP.FLUSH (gv_tcp_conn); 
>    p('Connection Flushed at ' || ncharssent); 
>  END IF; 
>  --    
> END LOOP; -- FOR i IN 1 .. msglen 
> 
> 
> where p is a procedure that dumps supplied text to a trace file with a timestamp 
> that is up to 1 ms resolution. BTW this is a 9202 box. Also when it starts getting 
> slow, using "nmon" I can see that this process is hogging a CUP at 99-100%. Of 
> course this is a dev box, but my SA will not like this on a production box. 
> 
> 
> Any ideas? 
> Thanks in advance 
> Raj 
> -------------------------------------------------------------------------------- 
> Rajendra dot Jamadagni at nospamespn dot com 
> All Views expressed in this email are strictly personal. 
> QOTD: Any clod can have facts, having an opinion is an art ! 
> 
> 
> 
> 
> **************************************************************************************
> 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.
> **************************************************************************************5
>  
> 
> 
> 
> 
> 
> 
> **************************************************************************************
> 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.
> **************************************************************************************4


-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Jared Still
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (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).

Reply via email to