> -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Rob Schramm > Sent: Tuesday, November 15, 2011 10:53 PM > To: [email protected] > Subject: Re: Data encrypt > > Peter, > > No, I am not talking about that... > > The issue is that CPACF clear key is tremendously faster than Secure > Key. Secure key is the process where the DEK or Operational Key is > encrypted under the Master Key but the process is 2 - 3 millisecond > for TDES to encrypt or decrypt a card number. Protected key is a > pretty cool way to merge the security of Secure Key and the > performance of Clear key.
Very interesting stuff, thank you for those links. I was not aware of this z10 capability at the time I did the performance testing I mentioned earlier. I notice that the performance benchmarks that IBM reports measure CPACF performance in 10**6 bytes per second, while the crypto express card performance is measured in 10**3 bytes per second. Very interesting to have that performance difference confirmed. Unfortunately, it appears that using the "protected key" path does require a customer to create an APF-authorized program to generate the "wrapped" key, introducing yet another item requiring auditing and protection. However, the gain in the level of key protection may well be worth that administrative cost. As usual, YMMV. It would be a boon to the community if someone (I can not do this myself) would enter a marketing request to IBM to make this "protected key" process part of the existing callable subroutine provided by ICSF to retrieve a clear key (CSNBKRR), rather than requiring customers to create APF-authorized code. One of the passed parameters to CSNBKRR could specify that the labeled clear key is to be protected before the value from the key store is returned. The protected key could then be passed directly to the "clear key" subroutines (CSNSYBE/D) with a parameter telling them that the passed key value is a protected value. It would also help if IBM were requested to dramatically reduce the CPU overhead of using ICSF subroutines in the first place. The abysmal performance of ICSF callable subroutines almost makes it a requirement for customers to "roll their own" methods when it comes to encryption, which is not an ideal solution. Thanks again for the updated info and links. Peter -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- 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
