Re: Can I store encrypted data in char data type?

In article <9mjvuq$m9v_at_dispatch.concentric.net>, "JerryK" says...
>
>Just so I understand. You are suggesting that I take the characters, lets
>say decimal 255, and convert to hex characters, "ff", and store "ff" as part
>of a VarChar2 string. Is that correct?
>

if you want to use a varchar2 (and not a raw -- a raw would in fact be more appropriate here) then yes -- that is what I am saying. You would double the length of the string and store it in "hex bytes" so decimal 255 would be stored as 'FF'.

>thanks,
>
>jerry
>
>"Thomas Kyte" <tkyte_at_us.oracle.com> wrote in message
>news:9merjs01goe_at_drn.newsguy.com...
>> In article <9mefan$4dr_at_dispatch.concentric.net>, "JerryK" says...
>> >
>> >Hi,
>> >
>> >I am storing an encrypted version of the user's password in a table. Can
>I
>> >store this is a character data type if the encrypted form contains
>> >non-printiable characters?
>> >
>> >All I can guarantee about the string is that each character will have an
>> >ASCII value from 0 to 255.
>> >
>> >jerry
>> >
>> >
>> >
>>
>> it'll be dangerous. If the client character set is not the same as the
>database
>> servers -- character set conversion will kick in (eg: a unix server with 7
>bit
>> ascii and a windows client with 8 bit WE8ISO -- your encrypted data will
>be that
>> much harder to "crack" as it will be changed)
>>
>> I would recommend if you want to use a varchar2 or char type - put the HEX
>> version of the data in there, not the raw bits and bytes.
>>
>> --
>> Thomas Kyte (tkyte@us.oracle.com) http://asktom.oracle.com/
>> Expert one on one Oracle, programming techniques and solutions for Oracle.
>> http://www.amazon.com/exec/obidos/ASIN/1861004826/
>> Opinions are mine and do not necessarily reflect those of Oracle Corp
>>
>
>

--
Thomas Kyte (tkyte@us.oracle.com)             http://asktom.oracle.com/ 
Expert one on one Oracle, programming techniques and solutions for Oracle.
http://www.amazon.com/exec/obidos/ASIN/1861004826/  
Opinions are mine and do not necessarily reflect those of Oracle Corp