Re: i5/OS Encryption -- MIDRANGE-L

Just a question from one that has not looked into encryption at all,

What is the impact of queries run over files with encrypted data? If the
encrypted field is a part of the key to access the records in the file,
what's the impact there? The boss wants a simple list sorted by encrypted
field with specific other requirements. This happens a lot at here in the
office, and I was wondering how query or SQL access to those encrypted
fields is impacted.

Thanks!

Jim

On 6/10/07, R Bruce Hoffman <bruce.hoffman@xxxxxxxxxxxxxxxxx> wrote:

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/
>

--
"Suppose you were an idiot...
And suppose you were a member of Congress...
But I repeat myself."
- Mark Twain

===========================================================
R Bruce Hoffman

--
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.