|
You're right Eric...typo on my part..s/b CCSID(65535).
Thanks...
On Thu, Apr 24, 2008 at 10:21 AM, Michael Ryan <michaelrtr@xxxxxxxxx> wrote:
> Hi Carsten -
>
> It's working! I must have been using a copy of the file that wasn't
> VARLEN. So I've created a file with DDS fields that looks like this:
>
> A FLDA 1024 CCSID(65534)
> A VARLEN(32)
> ...
>
> Is this an efficient way to hold the encrypted information? Are 32
> byte fields long enough (I'm using TDES) to accommodate the following
> unencrypted lengths - 9, 16, 20, 6? 24 doesn't seem to work.
>
> My thought is to have a 'shadow' file that contains the encrypted
> fields, and to blank out the corresponding fields in the 'master'
> file. Another thought is to have one file with all encrypted fields,
> regardless of 'master' file, with appropriate key information in the
> encrypted file to pull out the associated fields. Any thoughts on
> this?
>
> I really appreciate the good code - thank you!
>
> - Michael
>
>
>
>
> On Thu, Apr 24, 2008 at 10:03 AM, Flensburg, Carsten
>
>
> <Flensburg@xxxxxxxxxx> wrote:
> > 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.
> >
> > --
> > 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.
> >
> >
>
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
