Thanks, Phil. -----Ursprüngliche Nachricht----- Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag von Phil Smith Gesendet: Montag, 9. Juli 2012 15:11 An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: Secure Encryption Keys vs Protected Keys
David Stokes wrote: >As I understand it CPACF is basically some hardware instructions you can >invoke from assembler code (I've been using AES128 and SHA1 for our >inter-system communication software for quite some time). CEXx is a subsystem >which can only be accessed via various APIs (ICSF). Although CPACF now >supports protected keys, this probably in practice requires use of ICSF and a >CEX3 facility. While one can no doubt load CPACF protected keys oneself it >makes little sense to me to use protected key without secure key and the >feature is more intended to improve the efficiency and security of the CEX >operations, I guess. Yes, Protected Key requires ICSF and a CEX. You need secure keys to be able to use protected key - that is, you have to have a secure key to wrap in order to get a protected key to use protected key. CPACF is a combination of silicon and millicode. >That said, the CPACF MSA functions are synchronous, and get executed like any >other hardware instructions (more or less). Although there is no doubt a >little bit of setup when the keys are clear text there's no great overhead. I >would not expect the size of blocks to be such a major consideration above a >sensible minimum size, as seems to be borne out by the white paper. The >operations are just for symmetric encryption and hash generation (and PRNG). Yes, it's synchronous, and (unsurprisingly) is a fairly expensive instruction. >CEX otoh is accessed via a queuing mechanism. It is asynchronous and suspends >the executing work unit until the crypto-operation is complete (along with >encrypting and decrypting keys etc). Obviously this is an enormous overhead >compared to MSA and the size of data would play a much more significant role. >Of course it also does a lot more like handling SSL protocols, asymmetric >encryption and protecting crypto-keys. Costs you more cash as well. >Interested to know if this is a reasonable summary (if this has all >been discussed in previous parts of the thread, then sorry) Yes. And yes. :) -- ...phsiii ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
