Re: i5/OS Encryption

As a practical matter, I can't think of a column, offhand, that would qualify for encryption, that would not need to be expanded. SSN, devoid of punctuation, under 3DES would require 32 characters for encryption. In traditional i5/OS, DDS described files, very few people (if any) ever defined a 9 digit SSN as a 32 character varying for bit data field. Even if they stored it as character with punctuation, it's 11 characters. Even with the original RC2 encryption, 11 becomes 19, and then becomes 24. (8 byte boundaries are used after the "additional" space is allocated.)

So, I would consider the statement about not increasing the length of a field to be naive at best, and misleading.

The first step in using in place encryption, would most likely be to isolate yourself from physical changes in the database. As long as you are tied to the physical layout, recompiles are inevitable. This could mean changing away from native I/O to SQL, or careful reconstruction of your database, oriented towards turning off level checks followed by appending the encrypted fields and then altering the programs that need to access the encrypted data.

Encryption of the data in the database is not a quick add-on. It requires careful planning including, but not limited to, how to handle the encryption passwords.


Steve Martinson wrote:

More and more in my consulting travels, I come across "AS/400-iSeries-i5-System
i" (covering all my bases per a previous thread... ;-) shops that have i5/OS
data-at-rest encryption requirements. This is not an area of expertise for me or our
company, so I typically tell them to look at the cryptographic capabilities that are
native to the OS or, if they don't have in-house development support, tell them that they
can check out the various iSeries vendors for solutions.

My question to all of you bona fide programmers is: How much of an issue is it
(or would it be) for your shop to have to modify an existing DB2 table due to
column expansion required by an encryption enhancement?

IBM says "Depending on the encryption algorithm used to encrypt the data, the length
of an existing column might not have to be increased." You would probably limit the
number of encrypted DB columns to only the most sensitive fields (think PCI-DSS) and, by
doing so, also minimize the hit taken due to performance and sorting restrictions when
using encryption.

Would you seek out and try to incorporate the IBM algorithm that does not increase column size to save work and reduce the "pain" of reaching compliance? Or is it not that big of a deal when dealing with so few fields? Would column expansion matter when buying off-the-shelf? Best regards,
Steven W. Martinson, CISSP, CISM
Sheshunoff Management Services, LP.
Senior Consultant - Technology & Risk Management
2801 Via Fortuna, Suite 600 | Austin, TX 78746
Direct: 281.758.2429 | Mobile: 512.779.2630
e.Mail: smartinson@xxxxxxxxx


____________________________________________________________________________________
Looking for a deal? Find great prices on flights and hotels with Yahoo!
FareChase.
http://farechase.yahoo.com/