I started to send you an offline note to ask about /dev/random ... First, the way I understood it, was that the really old /dev/random drivers generated random numbers in software, and it was really slow.
Going back to the PCICC and PCIXCC cards, there was a RNG function on the card. I don't think customers installed a crypto card to do RNG, but if they had one for other reasons it certainly made sense to use the card and /dev/random was updated to use the card if it was installed and ICSF was active, and if so, ask ICSF for a random number. (ICSF must be active to send work to the cards.) If you needed more than a few random numbers, that was highly recommended. Then ICSF implemented the RNG Cache where it would, during initialization, start making RNG calls to the CEX card and build a cache of values that would be provided to applications when they executed the RNG. So you avoided the async operation in the application and RNG performance got significantly better. Note that ICSF implemented the RNG Cache in one version, and in the very next version, gave you an option RNGCACHE(NO) to disable it. The default is Yes. Now, with the z14, the RNG is available on the CPACF hardware, via an instruction. The ICSF SPG says in several places that specifying RNGCACHE will provide better performance for applications that use a lot of random numbers. And it makes sense that retrieving the random number from a cache is faster than generating it using an instruction. The question I wanted to ask you: Why doesn't /dev/random use the instruction directly to get it's random number? as opposed to going thru the overhead of using the API? To answer your specific question, on current technology, the CEX does not play a role in generating random numbers. More generally, your performance depends on: What hardware you are running on (both CEC and CEX card) What version of ICSF you are using, and how you have it configured Which /dev/random driver you are using Greg Boyd Mainframe Crypto www.mainframecrypto.com On Tue, 22 Jan 2019 14:16:10 -0600, Kirk Wolf <k...@wolf-associates.com> wrote: >Greg - >/dev/random use does require ICSF to be started, but is it affected >(improved) by the presence of a crypto card? That was not my >understanding, but I could be wrong. > >On Tue, Jan 22, 2019 at 7:27 AM Greg Boyd <gregb...@mainframecrypto.com> >wrote: > >> There may have been changes to Connect Direct since the last time I worked >> with it, but I suspect ICSF is required if you want to leverage the >> hardware technology, and specifically the CEX cards. As Kirk points out, >> if you want to use the random number generation on hardware then you need >> ICSF active. (And you probably do want the performance of RNG in >> hardware.) Similarly, for System SSL, if you want to use the Crypto >> Express cards for authentication (public/private key operations), then ICSF >> needs to be active. Enabling the cards and having ICSF active can make a >> big difference in throughput and capacity (CPU savings), but strictly >> speaking it's probably not required unless you configure the environment to >> use the crypto hardware. >> >> Greg Boyd >> Mainframe Crypto >> www.mainframecrypto.com >> >> >> On Fri, 18 Jan 2019 17:55:51 -0600, Steve beaver <st...@stevebeaver.com> >> wrote: >> >> >Also it’s required for Connect Direct >> > >> >Sent from my iPhone >> > >> >Sorry for the finger checks >> > >> >> On Jan 18, 2019, at 17:29, Kirk Wolf <k...@wolf-associates.com> wrote: >> >> >> >> ICSF is currently required if you want to use the Unix /dev/random and >> >> /dev/urandom devices. >> >> These might be required by Unix apps (or jobs/stcs that use z/OS Unix >> >> System services). >> >> >> >> For exampe: IBM OpenSSH server will not work without ICSF and >> /dev/random >> >> available. >> >> >> >> On Fri, Jan 18, 2019 at 5:24 PM Greg Boyd <gregb...@mainframecrypto.com >> > >> >> wrote: >> >> >> >>> ICSF is only required if you want to use the ICSF APIs, so it depends >> on >> >>> what, if anything in your shop might be using the APIs. System SSL >> (TLS) >> >>> will certainly leverage the APIs if you have Crypto Express cards >> available >> >>> and that might provide some CPU relief. The Guardium Database >> Encryption >> >>> Tool requires it if you want to encrypt IMS segments or DB2 tables at >> the >> >>> row level. >> >>> >> >>> Pervasive is getting a lot of attention and if you're going that >> route, I >> >>> would highly recommend that ICSF be active everywhere. You don't want >> one >> >>> system writing ciphertext to a file and another system thinking that >> the >> >>> file is cleartext. IBM is also recommending that ICSF be 'always up'. >> >>> They have made a number of changes to the component so that it will >> come up >> >>> earlier in the IPL and it should be one of the last tasks running. >> >>> >> >>> Given the growth in crypto workload, I take 'always up' to also mean >> >>> 'running everywhere'. There are simply more things that can leverage >> ICSF, >> >>> some optionally and some require it. >> >>> >> >>> I'm not sure why DFSMShsm would need ICSF active, unless they were >> using >> >>> the Encryption Facility for z/OS with the DFSMSdss feature. >> >>> >> >>> Greg Boyd >> >>> Mainframe Crypto >> >>> www.mainframecrypto.com >> >>> >> >>> >> >>> >> >>> On Fri, 18 Jan 2019 18:16:37 +0000, Mary Kay Tubello < >> mtube...@humana.com> >> >>> wrote: >> >>> >> >>>> Hello all, >> >>>> >> >>>> Does anyone know if z/os 2.3 requires ICSF to be installed on each >> LPAR? >> >>>> >> >>>> Thanks, >> >>>> Mary Kay >> >>>> >> >>>> Large Systems Engineering >> >>>> IT Infrastructure >> >>>> Humana >> >>>> 123 E. Main St. 40202 (CT6) >> >>>> 502-476-2772 >> >>>> mtube...@humana.com<mailto:mtube...@humana.com> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> ---------------------------------------------------------------------- >> >>>> 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 >> >>> >> >> >> >> ---------------------------------------------------------------------- >> >> 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 >> >> ---------------------------------------------------------------------- >> 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
