>>Can anyone >>recommend another vendor's product to encrypt DB2 data - preferably at the >>column level rather than encrypting the whole row. >What's the chances of going to DB/2 V8?
I'd second Ed's suggestion. However, bear in mind that table-level encryption: (a) does not require any program changes; (b) may not impose any particular penalty compared to column-level, depending on your workload. I know it may feel like you're encrypting "too much," but if it's not affecting the system in any meaningful way then don't worry about it. Encryption is done in chunks, and, at least within certain ranges, it doesn't much matter whether you're encrypting, say, 5 bytes or 50. Unless (maybe) you have very long rows. If you're willing to violate (a) (maybe) then you can shuffle table layouts to craft a "crypto table." Regardless, I would advise taking maximum advantage of any hardware cryptographic support you have in your particular mainframe (probably CPACF). Newer mainframes have faster cryptographic hardware with more algorithms, so congratulations if you have a System z9. :-) So-called "clear key" encryption is generally preferable from a performance point of view. I respectfully disagree with the commenter that suggested an external box of some kind for this mission. Perhaps it works for them, but I'd have some hard questions to overcome. You're going to take a big I/O hit for every read/write (increasing latency and, ironically, mainframe processing), the data would flow unencrypted over the wire to/from the box anyway (and that doesn't seem to pass muster with the PCI auditors I've heard about), and you've just created a really tough DR and key recovery problem. Remember, lose the keys (or the box that handles them) and you've lost the data. ICSF is the best key steward, and we're talking enterprise data here. If I were to do something like that I'd want a z/OS fallback option for processing and for key management with ICSF. And I'd probably want production crypto not on a separate box (over a wire) but on an IFL (Linux) over a Hipersocket. And I'd want to test and measure that setup a lot to make sure it's worth the bother versus a simpler (and less labor intensive) approach. Labor costs money, too. - - - - - Timothy F. Sipples Consulting Enterprise Software Architect, z9/zSeries IBM Japan, Ltd. E-Mail: [EMAIL PROTECTED] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
