RE: Encrypted Data to File

["Flensburg, Carsten" <Flensburg@xxxxxxxxxx>]

Hi Michael,

Depending on the encryption algorithm and mode as well as the chosen
encryption block length, the 16 bytes credit card number might end up as
a 24 or 32 bytes cipher string. Given that you're using my service
program you're receiving a varying length cipher string value from the
encryption procedure, and if you assign that value directly to the file
VARLEN field and vice/versa to the decryption procedure, the correct
length actually should be preserved. Yet, as you point out, something
has to be different, because if you feed the cipher string directly back
everything works. Have you tried checking out the string lengths and
cipher strings in the debugger? If you want you can also send me your
code and I'll have a look.

Best regards,
Carsten
  

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Michael Ryan
Sent: 24. april 2008 15:30
To: Midrange Systems Technical Discussion
Subject: Re: Encrypted Data to File

Hi Carsten -

Thanks for the feedback. Your service program works quite well - thanks!

I'm trying this:

Encrypt:
Take a piece of encrypted data, say a 16 credit card number; Encrypt it
into a 1024 varying field; Store the 1024 byte varying field into a
physical file with the VARLEN field level keyword, or into an SQL table
as a VARCHAR;
Decryp:
Access the appropriate record in the database; Take the VARLEN or
VARCHAR field from the file/table; Decrypt into a 1024 varying field;
Extract the 16 bytes (known length based on the application).

Does this make sense?

Thanks!


On Thu, Apr 24, 2008 at 8:43 AM, Flensburg, Carsten
<Flensburg@xxxxxxxxxx> wrote:
> Hello Michael,
>
>  You'd want to tag the physical file field with a CCSID(65535) 
> keyword,  to avoid possible conversion issues relating to treating the

> data as  text - as opposed to the binary value a cipher string
represents.
>  Judged by your description of the problem another more immediate 
> concern  would be how you preserve the actual length of the cipher 
> string. You  have to feed back the exact same string length to the 
> decryption process  as you received initially from the encryption 
> process. So if you receive  a cipher string with a length of 192 
> bytes, store that value in a fixed  field in your physical file having

> a length of f.x. 512 bytes, you'll  need some way to ensury that 
> you're only passing the actual 192 bytes  cipher string back to the 
> decryption process. Simply running a %Trim()  against the file field 
> is not a recommended method of obtaining the  cipher string length, as

> there's a possibility that the encryption  process returns the value
x'40' as the two rightmost nibbles.
>  Best regards,
>  Carsten
>
>
>
>  -----Original Message-----
>  From: midrange-l-bounces@xxxxxxxxxxxx  
> [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Michael Ryan
>  Sent: 24. april 2008 14:09
>  To: Midrange Systems Technical Discussion
>  Subject: Encrypted Data to File
>
>  I've implemented Carsten Flensberg's service program to encrypt and  
> decrypt data using the Cryptographic APIs. Works well. However, I'm  
> having a problem writing to/reading from a physical file containing 
> the  encrypted data. I encrypt some data into a 1024A varying field, 
> put the  varying length field into a (smaller) fixed length field in 
> the  database, and then in a later process, read the encrypted data 
> and  attempt to decrypt it. I get a value back of blanks from the 
> decryption,  though I can see (in debug) that the encrypted data is 
> there. If I don't  move the encrypted data into the physical file 
> field, I'm able to  encrypt and decrypt. So it must be the physical 
> file move that's causing  the problem. Has anyone encountered this?
>  What's the fix?
>
>  Thanks!
>  --
>  This is the Midrange Systems Technical Discussion (MIDRANGE-L) 
> mailing  list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To 
> subscribe,  unsubscribe, or change list options,
>  visit: http://lists.midrange.com/mailman/listinfo/midrange-l
>  or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take

> a  moment to review the archives at
http://archive.midrange.com/midrange-l.
>  --
>  This is the Midrange Systems Technical Discussion (MIDRANGE-L) 
> mailing list  To post a message email: MIDRANGE-L@xxxxxxxxxxxx  To 
> subscribe, unsubscribe, or change list options,
>  visit: http://lists.midrange.com/mailman/listinfo/midrange-l
>  or email: MIDRANGE-L-request@xxxxxxxxxxxx  Before posting, please 
> take a moment to review the archives  at 
> http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.