Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> Re: Protecting the encryption key from the DBA
Frank van Bortel schrieb:
> You only failed to show the correct blocks: in your encrypted
> part, you show the blocks from CC14BC0 onward, while the
> unencrypted part starts at CC14BB0.
>
I'm not aware of possibility to dump single bytes from datablock ( in terms of oracle tools ;-), so i dumped *one* block. It was the *same* block in both , encrypted and not encrypted case. You can easily see it , as i posted the full content of datablock that contained one row in my test table.
Encrypted:
Dump of memory from 0x0CC12C00 to 0x0CC14C00
Decrypted:
Dump of memory from 0x0CC12C00 to 0x0CC14C00
Do you see any difference ?
The offsets CC14BB0 till CC14BBF contain part of my unencrypted value (
'Maxi' ). In encrypted part those offsets are not shown explicitly
because they are zeroed.
CC12C80 00000000 00000000 00000000 00000000 [................] Repeat 499 times
0xCC12C80 + ( 499 * 16 ) = 0xCC14BB0,
that means the line starting with offset 0xCC14BB0 is the same as line
starting with offset 0xCC12C80.
Can you now point me , where i failed to show the correct blocks ? On another side , i am wondering , why you got a match ( i could assume an accident if that were such short and very common string as mine, but you had in your example relativ long sentences...) I'll try to reproduce your situation. Maybe in your case however the blocks were not yet written to file - you did not provide much details to your tests. Nethertheless , i think , to have a look on the blockdump is more precise than to grep a whole datafile.
Additionally , i would like to know one thing more ;-) Could you access the encrypted table after wallet was closed or have i misunderstood it ? I got an ORA-28365 in that case... I mean the table can be accessed, if encrypted columns are excluded from select list, but not for select *
Best regards
Maxim Received on Thu Jul 21 2005 - 12:22:50 CDT