|
Hi Michael,
Great! If you don't change any of the current parameters and
settings, I'd expect the 32 bytes to be sufficient for future use
also. Both of the alternatives you mention regarding storing the
encrypted value would work, but regardless of which one you choose,
you'd want to consider adding a field to hold an individual salt
(initial chaining value) to be used in the encryption/decryption
process. You don't mention if you're already doing this, so I thought
I'd better remind you, anyway. Let me know if you need moreinformation.
Best regards,
Carsten
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Michael Ryan
Sent: 24. april 2008 16:22
To: Midrange Systems Technical Discussion
Subject: Re: Encrypted Data to File
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 thethis?
encrypted file to pull out the associated fields. Any thoughts on
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 cipherstring > 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 TechnicalDiscussion > > > 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 varyingfield;
> 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 totreating 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 filehaving > > > 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 datais >
> 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 thephysical >
> 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@xxxxxxxxxxxxTo > > 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 athttp://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-2024 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
