RE: Field Encryption on OS400

Charlie Guardino gave a session at COMMON in Nashville (maybe repeated in Reno; wasn't there) on this very fact. Yeah, it's not a 1-to-1 replacement. Then there's the issue of securing the decryption routine - which is never foolproof.

Jerry C. Adams
IBM System i Programmer/Analyst
--
B&W Wholesale
office: 615-995-7024
email: jerry@xxxxxxxxxxxxxxx


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Tuesday, May 12, 2009 3:44 PM
To: Midrange Systems Technical Discussion
Subject: Re: Field Encryption on OS400

How do you really expect your third party products to do it? For example,
if you have social security number (SSN) in your file as one 9A column do
you really expect them to continue fitting it in there as a 9A column and
all your programs that currently access it will run happily? Because,
brother, that's not going to happen. It takes extra characters to encrypt
the data, and it will enlarge it. Let's use it now being 15A as an
example. So you're going to have to change all programs that currently
use it.

Workaround might be to rename the PF, create a SQL view over the PF and
name the SQL view the same as the old PF name and the view could use a UDF
to decrypt the data. Thus having the same record layout. But a view is
not very useful in RLA versus SQL access.

Do you expect the third party products to store it in a new table? And
then those programs that truly need it will have to chain out to that
table also? Not a bad idea, but all the programs that really need to
access the encrypted field will have to be modified.

How do you think that a purchased product is going to fix this for you?

Rob Berendt