Just some things you might want to consider while researching your cryptographic requirements:
I don't have any performance info or answers your questions on CPACF instruction synchronicity, but you may want to check out this IBM webpage comparing CPACF and CEX2(C) co-processor performance. It's linux-oriented, but could be useful nonetheless (watch the line-wrap): http://www.ibm.com/developerworks/linux/linux390/perf/tuning_res_securit y_crypto.html I also wanted to point out to you that using just the basic CPACF instructions (KM, KMAES, KMC, KMCAES, KIMD, KLMD, KMAC) will also require you to use CLEAR KEYS in your programs that encrypt or decrypt. The basic CPACF instructions do not support encrypted keys. IBM's ICSF product (which *requires* a crypto co-processor) supports encrypted keys and all sorts of other good security practices, using a special KSDS to store encrypted keys with a user-selected "label". Then programs use the "label" to tell ICSF subroutines what key to use, so there aren't any key values floating around in program source or application files. You can find some IBM sample code to use the basic CPACF instructions by going to the IBM Techdocs site and using CPACF as your search argument: http://www-03.ibm.com/support/techdocs/atsmastr.nsf/Web/TechDocs Also, AFAIK, CONNECT:Direct does *not* require a crypto coprocessor, it is quite happy to use just the basic crypto instructions. I don't know what tn3270 crypto needs, though. HTH Peter > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Patrick O'Keefe > Sent: Friday, April 25, 2008 1:02 PM > To: [email protected] > Subject: CPACF performance info? > > This may be slightly off-topic for IBM-Main but I'm going to ask > here anyway. Has anyone seen performamce stats for CPACF > (crypto assist) on a z9? I've found quite a bit on the perfomance of > crypto coprocessors, but very little on CPACF. > > We are soon going to get heavily into encryption for both Tn3270 > and data transfers (using CONNECT:Direct). Since these are typically > long connections, most of the crypto work is going symmetric key > algorithms handled (if we pick the right ciphersuites) by CPACF. We > are worried by the CPACF instructions being handled synchronously - > a CP doing a CPACF function is not available for "normal" processing. > > I assume there must be a perfomance advantage to the invoking > program to have the encryption cycles burned by the engine in its > CPACF capacity (executing the encryption algorithm in millicode, I > assume) rather than coded in regular z9 instructions. I'm less sure > of this being an advantage for overall throughput. Can a CPACF > "instruction" be interrupted so that the CP can be used for other > work, or is the CP tied up for the duration of the instruction? If > the latter, an LPAR with very few engines assigned to it could be > really negatively impacted by CPACF. > > Does anybody have information on this? Anacdotal info (like "We > haven't seen a problem") is fine, but our management would like > to see something more definite. 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
