I'm trying to put this in my own words. I'm not an expert on Z crypto architecture, but I am sure someone will correct me if I am wrong.
The CPACF instructions are like the TRT instruction. You *could* do what TRT does with a loop using IC and compare and so forth, but the TRT instruction is much faster. It's a relatively slow instruction as instructions go, while still much faster than a loop. But it's a machine instruction. The CPU is busy and running up CPU time for the task the whole time that TRT takes. The same for CPACF instructions: faster than a loop, but still machine instructions that consume CPU time. The crypto cards are a little like a DASD drive. The control program can say "go do this" and then suspend the task in question and go do other things or go into a wait state. The task accrues no CPU time while the crypto card is doing its thing, much the way it accrues no CPU time while the DASD does its thing. Like DASD, when the crypto card completes its operation, it comes back to the control program and says "I'm done, here is your result." The task resumes executing, presumably using the results of the crypto operation. The function is overall faster than a loop, and way more economical in terms of CPU time. A little encryption background: Symmetric or "secret key" encryption is probably what you think of when you think of encryption. You encrypt and decrypt with the same secret key, just like when you passed coded notes in grade school. It is a part of almost everything where encryption is involved. It is slow as things go, but it is relatively fast compared to Asymmetric or "public key" encryption. The big problem with symmetric encryption is "how do you deliver that secret key to the other end of the line?" For DASD encryption, that is not an issue, because both "ends of the line" are right there on your machine. But for communication situations, where the other end is far away and there is no secure path (until you have the encryption set up) and thus no way to deliver that secret key to the other end, other than a guy on a plane with a briefcase padlocked to his wrist. Asymmetric encryption is like magic! You use one key for encryption and a different key for decryption. (The two keys have a complex mathematical relationship to each other, and even computing that relationship takes a lot of time.) So you can encode something with the other end's completely public public key, and only that other end, that has the corresponding private key, can decrypt it! Magic! Problem solved. Except that asymmetric encryption is really, really, really slow. Specialized hardware makes it faster, but it is still really, really slow. So how is it usable then in the real world? The answer is that you never encrypt "real data" with asymmetric encryption. You make up a random secret key, deliver it to the other end using public key (rather than a guy with a briefcase) and then use that random secret key for symmetric encryption of the real data. So symmetric encryption is used for everything, and asymmetric encryption is used in addition for things where the other end is remote. (That combo is often something called SSL or TLS, and they also make extensive use of our other old friends, digital certificates.) CM On Thu, 25 Jan 2024 13:01:17 -0600, Alan Altmark <[email protected]> wrote: >On Wed, 24 Jan 2024 20:15:18 +0400, Peter <[email protected]> wrote: >>Still I am trying to understand encryption and decryption load goes to >>general CP In case if you don't have CPACF or ICSF ? > >There's no such thing as "don't have CPACF". All machines have it. It's >on-chip and part of the instruction set. > >The only variable is whether or not the no-charge hardware cryptographic >feature 3863 is enabled (in countries where it is offered). It controls the >amount of function in CPACF and whether or not you can use the crypto cards. >Let's assume you have the feature enabled. > >As Eric has replied, CPACF is focused on symmetric (shared key) cryptographic >operations. That's because symmetric operations can be done quickly, and far >more efficiently than doing it in software. But CPACF is not an offload >operation. All of the cycles are on the processor. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
