To complement, clarify and organize in few points:
1. We have symmetric and asymmetric crypto. And some other
crypto-related functions (SHA, RNG). However it worth to know, the
asymmetric crypto is approx. 1000 times slower than symmetric crypto
(with the same crypto-strength). That's why we use asymmetric crypto
only when symmetric cannot be used. The example is SSL/TLS - we start
with asymmetric just for handshake process and quickly switch to symmetric.
2. They key is ...key. I mean private key and symmetric key should be
kept in secret. That's why we have *secure key* and clear key
cryptography. The last one means authorized (and educated) user can find
it in memory. Secure key cannot be found, because it reside in clear
form only in HSM - special tamper-protected crypto hardware. Read:
CryptoExpress card. Note, there is also something between - protected
key cryptography. In this case user cannot read the key, but this
flavour is has no high FIPS certification.
3. You may want to use CryptoExpress for two reasons: asymmetric crypto
offload (performance) and for symmetric crypto operations with secure
key (security, compliance).
4. Note, large number of small-block symmetric operations on
CryptoExpress mean much worse performance than CPACF, due to I/O.
CryptoExpress is peripheral device.
However the larger block and the stronger algorithm, the better
performance from CryptoExpress.
5. CPACF does not offer any asymmetric operations, so there is no
comparison to CryptoExpress. Instead it can be pure software
implementation, which means even worse. It is worth to note: CPACF,
CryptoExpress and just software (as any other application code). CPACF
is the fastest, but CryptoExpress offers more functions. So it is better
to use CPACF whenever possible (compliance, etc.), then CryptoExpress
then software. Note, the software can be offloaded to zIIP.
6. CPACF functions can be called as ICSF services, but some of them can
be invoked directly from assembler code.
7. CryptoExpress is paid feature, it is a card, like FICON or OSA. CPACF
is "for free" (read included in the price). However due to export
limitations it is enabled (FC 3863) or not. Usually yes. And the 3863 is
prereq for CryptoExpress.
8. AFAIK few CPACF crypto services (SHA?) are available even without FC
3863.
My €0.02
--
Radoslaw Skorupka
Lodz, Poland
W dniu 25.01.2024 o 22:28, Charles Mills pisze:
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 <alan_altm...@us.ibm.com>
wrote:
On Wed, 24 Jan 2024 20:15:18 +0400, Peter <dbajava...@gmail.com> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN