Nicely put.
> 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 ...
You nailed the description, but I recommend *not* calling it "secret
key" encryption because in asymmetric there is a /secret/ key. (Call it
the /private/ key. But some still call it the secret key.)
A better term might be "/single/ key encryption" because there is only
one key. It's like a house key: it both locks and unlocks. (Or like
coded notes in grade school, yep.)
Symmetric is more accurate, but not a term lay people use. (But we could
... uhh ... school them.) *:-)*
Also ... spot on about key distribution problems.
Some of us in VM land have started tinkering with a trust anchor.
Absolutely right about that "random secret key".
Better term there is /session/ key. All our current crypto combines
asymmetric (for trust) with symmetric (for speed): TLS/SSL (call it
PKI), SSH, PGP/GPG.
-- R; <><
On 1/25/24 16:28, Charles Mills wrote:
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 tolists...@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
