Configuring and having available a crypto facility engine as an accelerator is primarily for use in the speeding up of the SSL initial negotiation, as that is using RSA public/private keys for handshake, which then results in a symmetric key for a cipher have both agreed upon. This handshaking is one of the more expensive (cpu wise) of SSL handling, and using the accelerator helps speed that up, especially as RSA key lengths get larger.
Note: My knowledge of this comes from my work on z/OS and studying of how the crypto engines in accelerator or co-processor mode work. Not sure if the usage on the Linux on Z builds operates the same way. Regards, Peter -----Original Message----- From: Linux on 390 Port <LINUX-390@VM.MARIST.EDU> On Behalf Of Rick Troth Sent: Friday, January 10, 2020 8:52 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Pervasive disk encryption questions CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. My understanding of the cards is that they're more of a trust anchor than an accelerator. What I mean is ... differentiate symmetric crypto from asymmetric crypto. Symmetric crypto (think AES) is handled by the main processor, right? (This is where Brian or Alan will chime in, and please do.) So why shuttle the work to a co-processor? Symmetric crypto is faster (much!) than asymmetric. Who uses AES as a master key? The concept of "master" should be asymmetric, not symmetric. Symmetric keys are the kind you create for a session and then discard. But ... this is pervasive ... okay ... keys ... and store them. Where? On the card? Okay, but still, doesn't mean the *processing* of symmetric gets done there. Last I knew (haven't read the PoOp for z15), the CPU didn't have asymmetric instructions (think RSA). Asymmetric crypto is slower (much!) than symmetric, so one could conceivably shuttle that work to a daughter card and get a win (or at least parity!). But there's another point: "trust" is all about asymmetric keys, where you have a PUBLIC half and a PRIVATE half to the pair. So the card can hold the private half (and prove itself against the public half, like for an SSL cert) or can hold the public half (and serve to confirm a third party, like a remote web site SSL cert). Not sure I'm splainin it well. Solly. But this could be old news. IBMers? What's new? -- R; <>< On 1/10/20 8:24 PM, marcy cortes wrote: > Cross posted to Linux-390 and IBMVM > > > First, my understand of virtualizing crypto is that if any of the > cards are defined as accelerators then CRYPTO APVIRT in the directory will > give linux > an accelerator. If you want linux to have a coprocessor, you’d have to > dedicate one. If you want a lot of servers to have coprocessors (more > than the HW cards to dedicate), you’d get rid of the accelerators and > make them all coprocessors. Is my understanding correct? > > And to do the AES master key load, it has generally been done from z/OS > here. It looks like for my z/vm only boxes TKE is required, but I could > use the CCA package to generate some for a test only scenario. > > If I do want to try that CCA key load on a non prod box, I’m thinking > I would have to dedicate all of the coprocessors to a Linux guest and > create them there. Then undedicate and then any guest with an APVIRT > would find valid master keys and would then be able to “zkey generate” > a secure key for use in each disk. > > Am I on the right track? > > Marcy > -- -- R; <>< ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit https://nam05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww2.marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-390&data=02%7C01%7Cpwoude%40HARRISTEETER.COM%7C1346250474f843a2aceb08d796398ae7%7C95fcefa54abb413594fc717122fd83d5%7C0%7C0%7C637143046209518057&sdata=YWO7eRzQPGxXKYWn7u%2BJrl35XCQtMhpbyyg4wgrBykQ%3D&reserved=0 ________________________________ CONFIDENTIALITY NOTICE: This e-mail message and all attachments may contain legally privileged and confidential information intended solely for the use of the addressee. If the reader of this message is not the intended recipient, any reading, dissemination, distribution, copying, or other use of this message or its attachments is prohibited. If you have received this communication in error, please notify the sender immediately by telephone at 704.844.3100 and delete this message and all copies and backups thereof. Thank you. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
