Re: Encryption and decryption - processor or TCPIP
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!
Re: Encryption and decryption - processor or TCPIP
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 wrote: On Wed, 24 Jan 2024 20:15:18 +0400, Peter 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
Re: Encryption and decryption - processor or TCPIP
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 wrote: >On Wed, 24 Jan 2024 20:15:18 +0400, Peter 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
Re: Encryption and decryption - processor or TCPIP
On Wed, 24 Jan 2024 20:15:18 +0400, Peter 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 asymmetric cryptography, CPACF offers some help, but the real acceleration comes with the crypto cards. It's very visible when you start up a subsystem that clients are trying to connect to. E.g. telnet server, CICS, db2. Hundreds or thousands of clients may all be trying to connect at the same time. Those TLS handshakes are significantly accelerated by offloading the asymmetric cryptography to the crypto cards where it runs in parallel to whatever is happening on the CP. Alan Altmark IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Encryption and decryption - processor or TCPIP
You are correct. It's on the same piece of silicon NOW. My original point is still good. I don't understand why there is a focus on a minor detail of the physical layout of the chip. Correcting my original statement. "The CPACF is a PIECE OF THE CP that runs in lockstep with the CP that invokes it. So, it is does cost general CP but much less than implementing it in millicode." Eric Rossman -Original Message- From: IBM Mainframe Discussion List On Behalf Of Martin Packer Sent: Thursday, January 25, 2024 10:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Encryption and decryption - processor or TCPIP If I'm interpreting the z16 materials right it's within the core's area. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Encryption and decryption - processor or TCPIP
If I’m interpreting the z16 materials right it’s within the core’s area. From: IBM Mainframe Discussion List on behalf of Eric D Rossman Date: Thursday, 25 January 2024 at 15:07 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Encryption and decryption - processor or TCPIP > Actually, every processor core includes its own CPACF coprocessor section. > In other words, CPACF is "on core." It's a fine distinction. My background is in HW so I describe it as separate from the "CP" proper, even though it is on the same chip. Eric Rossman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless otherwise stated above: IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Encryption and decryption - processor or TCPIP
> Actually, every processor core includes its own CPACF coprocessor section. > In other words, CPACF is "on core." It's a fine distinction. My background is in HW so I describe it as separate from the "CP" proper, even though it is on the same chip. Eric Rossman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Encryption and decryption - processor or TCPIP
Hi, there is another possibilty for a delay in TLS session setup: When you connect in clear to a TN3270 server and then have told your client to use STARTTLS. This may be a fast initial solution in case when your firewall cerberos :-) cannot rapidly a new port, i.e. 992. Best /PS -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Encryption and decryption - processor or TCPIP
Eric Rossman wrote: >The CPACF is a physically separate chip that runs in lockstep >with the CP that invokes it. So, it is does cost general CP but >much less than implementing it in millicode. Actually, every processor core includes its own CPACF coprocessor section. In other words, CPACF is “on core.” That includes CPs (general purpose processor cores), IFLs, zIIPs, and all the other main processor core types.(*) You can see a design illustration of this arrangement in IBM Redbook SG24-8951 (“IBM z16 Technical Guide”) in Figure 3-13. If your processor core is configured for SMT2 (typical with zIIPs and IFLs) then the CPACF section will also operate in SMT2 mode. Said another way, every processor core thread has its own CPACF section thread. Really the only thing you need to worry about in terms of having CPACF available is to make sure that Feature Code 3863 is installed on your system. FC 3863 is a zero additional charge feature. It’s available in almost every country and territory, but apparently there are one or a couple odd places with peculiar import regulations. Those few places may still allow FC 3863 but may require some sort of permit or other legal paperwork. Ordinarily your IBM representative or IBM business partner will add FC 3863 to your machine order reflexively in the countries/territories where there’s no local regulatory issue. But that’s something to double check. If you don’t have FC 3863 installed then CPACF still partially works, but it only provides hashing and random number functions. FC 3863 enables the full range of CPACF algorithms/instructions including encrypt/decrypt. (*) I think those other processor types also use CPACF instructions from time to time, if available. For example, the Coupling Facility Control Code (CFCC) likely uses CPACF instructions (if FC 3863 is present) when you configure encryption-related functions to strengthen a CF’s security posture. — Timothy Sipples Senior Architect Digital Assets, Industry Solutions, and Cybersecurity IBM Z/LinuxONE, Asia-Pacific sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Encryption and decryption - processor or TCPIP
Timothy, You forgot to mention the other alternative for using CPACF facilities - direct application-level HLASM coding. I did that once a long while ago, in the era before protected clear keys, for encryption of a single field in a huge business record, security provided by "hiding" the encryption key value (I know, not very secure at all, but it was a short-term urgent business necessity). Long since replaced of course by more modern and far more secure methods, but the CPACF hardware facility is there to use (assuming it is turned on) should one have the need, and with protected clear keys it can even be somewhat secure. Of course, it's probably only curious old dinosaurs like me who would even think of "roll your own" for an encryption need when these days there is so much infrastructure available to do the work for you. Peter From: IBM Mainframe Discussion List On Behalf Of Timothy Sipples Sent: Wednesday, January 24, 2024 5:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP >So Timothy (and probably just for me), I've seen a couple >of sites without crypto HSM cards not bother to run ICSF. >Can I assume in that case there's pretty-much no way any >encryption processing could be using CPACF? ICSF supports many, many cryptography-dependent features in z/OS. Even many business applications that just need a simple API to get a random number rely on ICSF. ICSF is "darn important." But the way you phrased your question I'd answer no. It's technically possible to exploit CPACF even from within z/OS but without calling ICSF. One simple example that comes to mind is via the z/OS Container Extensions (zCX). You could have a running container image in zCX that's using CPACF instructions - via an OpenSSL library, for example. (OpenSSL on this architecture knows how to exploit CPACF instructions and has for many years.) However, the container image has no direct access to ICSF. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Encryption and decryption - processor or TCPIP
Thanks Timothy, and thanks to others who helped with my side questions. On 1/24/2024 2:20 AM, Timothy Sipples wrote: So Timothy (and probably just for me), I've seen a couple of sites without crypto HSM cards not bother to run ICSF. Can I assume in that case there's pretty-much no way any encryption processing could be using CPACF? ICSF supports many, many cryptography-dependent features in z/OS. Even many business applications that just need a simple API to get a random number rely on ICSF. ICSF is “darn important.” But the way you phrased your question I’d answer no. It’s technically possible to exploit CPACF even from within z/OS but without calling ICSF. One simple example that comes to mind is via the z/OS Container Extensions (zCX). You could have a running container image in zCX that’s using CPACF instructions — via an OpenSSL library, for example. (OpenSSL on this architecture knows how to exploit CPACF instructions and has for many years.) However, the container image has no direct access to ICSF. — Timothy Sipples Senior Architect Digital Assets, Industry Solutions, and Cybersecurity IBM Z/LinuxONE, Asia-Pacific sipp...@sg.ibm.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
Re: Encryption and decryption - processor or TCPIP
> > Peter wrote: > > > Still I am trying to understand encryption and decryption > > > load goes to general CP Incase if you don't have CPACF or > > > ICSF ? > Phil Smith III wrote: > > Even with CPACF and ICSF, some/most of the encryption load > > is on the CPU. > > They aren't magic. CPACF is faster, but it's still > > fundamentally executing Z instructions in the millicode. Tony H wrote: > Really? Surely there is on-chip crypto hardware that the > millicode invokes to do much of the work? I can't imagine it's > just like the millicode implementation of the sort > instructions or something. You are correct. The CPACF is a physically separate chip that runs in lockstep with the CP that invokes it. So, it is does cost general CP but much less than implementing it in millicode. > But I think the OP deserves a simple answer: YES. If there's > no crypto hardware then ICSF will do it all using ordinary > zArch instructions. If there is no crypto hardware (no CPACF), ICSF won't start. > In the early days there was (is?) even an ability to plug your > own crypto provider software into the back end of ICSF, with > interface documentation "by request only". I've been in ICSF for over 25 years. I've never heard of this. Eric Rossman ICSF architect -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Encryption and decryption - processor or TCPIP
You will need at least a CPACF to initialise ICSF. Lennie -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tony Harminc Sent: 24 January 2024 18:55 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP On Wed, 24 Jan 2024 at 12:38, Phil Smith III wrote: > Peter wrote: > >Still I am trying to understand encryption and decryption load goes > >to general CP Incase if you don't have CPACF or ICSF ? > > Even with CPACF and ICSF, some/most of the encryption load is on the CPU. > They aren't magic. CPACF is faster, but it's still fundamentally > executing Z instructions in the millicode. > Really? Surely there is on-chip crypto hardware that the millicode invokes to do much of the work? I can't imagine it's just like the millicode implementation of the sort instructions or something. But I think the OP deserves a simple answer: YES. If there's no crypto hardware then ICSF will do it all using ordinary zArch instructions. Probably there are a few things it can't do, like true random number generation, but generally you don't need any crypto hardware at all. In the early days there was (is?) even an ability to plug your own crypto provider software into the back end of ICSF, with interface documentation "by request only". Tony H. -- 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
Re: Encryption and decryption - processor or TCPIP
On Wed, 24 Jan 2024 at 12:38, Phil Smith III wrote: > Peter wrote: > >Still I am trying to understand encryption and decryption load goes to > >general CP Incase if you don't have CPACF or ICSF ? > > Even with CPACF and ICSF, some/most of the encryption load is on the CPU. > They aren't magic. CPACF is faster, but it's still fundamentally executing > Z instructions in the millicode. > Really? Surely there is on-chip crypto hardware that the millicode invokes to do much of the work? I can't imagine it's just like the millicode implementation of the sort instructions or something. But I think the OP deserves a simple answer: YES. If there's no crypto hardware then ICSF will do it all using ordinary zArch instructions. Probably there are a few things it can't do, like true random number generation, but generally you don't need any crypto hardware at all. In the early days there was (is?) even an ability to plug your own crypto provider software into the back end of ICSF, with interface documentation "by request only". Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Encryption and decryption - processor or TCPIP
Peter wrote: >Still I am trying to understand encryption and decryption load goes to >general CP Incase if you don't have CPACF or ICSF ? Even with CPACF and ICSF, some/most of the encryption load is on the CPU. They aren't magic. CPACF is faster, but it's still fundamentally executing Z instructions in the millicode. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Encryption and decryption - processor or TCPIP
I think there might be some confusion as to terminology. CPACF is a hardware engine built into the CEC. Crypto Express cards are hardware engines purchased to be plugged into the box. ICSF can use CPACF (which still counts against general CP but is much more efficient than software crypto), Crypto Express, or our own software implementation (for things not implemented in HW or when HW support is not available). ICSF generally prefers Crypto Express for RSA and CPACF for AES, DES, ECC, hashing. Eric Rossman From: Peter Sent: Wednesday, January 24, 2024 11:15 AM To: IBM Mainframe Discussion List ; Eric D Rossman Subject: [EXTERNAL] Re: Encryption and decryption - processor or TCPIP Eric Still I am trying to understand encryption and decryption load goes to general CP Incase if you don't have CPACF or ICSF ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Encryption and decryption - processor or TCPIP
Eric Still I am trying to understand encryption and decryption load goes to general CP Incase if you don't have CPACF or ICSF ? On Wed, Jan 24, 2024, 6:44 PM Eric D Rossman wrote: > Responding to a bunch of questions/comments in one reply. > > Tom Brennan: > > I thought I heard that you can start ICSF without a crypto > > card and it will use CPACF for some of the heavier encryption > > processing (maybe like generating prime numbers) and save > > individual tasks some CP time. > > ICSF will use CPACF for RNG, hashing (SHA-1, 2, 3), DES, AES, and ECC > operations. It will also use it for ECC key pair generation if you use PKCS > #11 interfaces. > > Lennie Dymoke-Bradshaw: > > ... ICSF without a Crypto Express card. ... However, this only > > supports clear keys in the CKDS. The CKDS ... is different in > > some way and cannot be converted to a secure key CKDS. > > True. There is an unsupported way to convert from clear key only > CKDS to secure key (and clear key) CKDS but it's not for the > faint of heart (since you are messing directly with your KDS). > > Lennie Dymoke-Bradshaw: > > I don't know if there is a way of using the PKDS or TKDS in > > this configuration. > > PKDS, no. TKDS, yes. The TKDS existed before EP11 existed. > > Lennie Dymoke-Bradshaw: > > I have been told it is possible to run Data set encryption > > with CPACF only and a clear key CKDS > > This is possible, but less secure since the keys are not protected by a > master key. > > Timothy Sipples: > > ICSF supports many, many cryptography-dependent features in > > z/OS. Even many business applications that just need a simple > > API to get a random number rely on ICSF. ICSF is > > “darn important.” > > Thank you! I might be biased but I think everyone should have ICSF. > > Timothy Sipples: > > And if persistent TLS connections are an option then they’d > > dramatically reduce the number of network roundtrips, > > eliminating a lot of network latency. > > Agreed. Also, System SSL session caching is also quite helpful. > > Eric Rossman > > > -- > 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
Re: Encryption and decryption - processor or TCPIP
Peter wrote: >After implementing ATTLS there is some delay in our CICS transaction but I >was suspecting if sn absence of crypto processor can overload the general >processor to cause this delay ? Define "some delay". Adding AT-TLS means that a TLS handshake is being added to the communication. That isn't instantaneous, and means some additional network back-and-forth. I'd strongly suspect that it's more just network latency added by that than the cost of the encryption itself. As for CPACF, this tiny Rexx program will tell you if it's enabled. It does require that CSF (ICSF) be running/have run since IPL. It tests a bit CSF sets after *it* verifies the existence of CPACF by trying the instructions. /* REXX */ if bitand(storage(d2x(x2d(c2x(storage(d2x(x2d(c2x(, storage(d2x(x2d(c2x(storage(10,4)))+x2d(C8)),4)))+, x2d(B8)), 4)))+x2d(11A)), 1), '08'x) <> '00'x then say 'CPACF is enabled' else say 'CPACF is not enabled' /* tests CCVT_KMC_AES256 (x'08', "KMC AES 256 key enabled") on flag CCVT_KMC_EXPORT3 (offset 11A) in CSFCCVT, pointed to by CVTABEND (offset x'B8') into CVT (X'10' in page 0) */ If by some chance CPACF is NOT enabled, it's a free feature on all current IBM hardware, so get it turned on! Do make sure that anything you enable AT-TLS for both can handle TLS at the other end AND is not already doing TLS. We've had several incidents where people turned on AT-TLS "because it's good" and our product was already doing TLS. The double encryption does not work out well--specifically, it results in strange connection failures because "inner" level of negotiation works, but then instead of seeing a request, it sees another TLS negotiation start, which it doesn't understand since it's not looking for one. It doesn't sound like this is your issue--if it were, you'd be having failures, not delays!--but it's important to understand and I'll keep repeating it because it seems to be a common error. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Encryption and decryption - processor or TCPIP
Responding to a bunch of questions/comments in one reply. Tom Brennan: > I thought I heard that you can start ICSF without a crypto > card and it will use CPACF for some of the heavier encryption > processing (maybe like generating prime numbers) and save > individual tasks some CP time. ICSF will use CPACF for RNG, hashing (SHA-1, 2, 3), DES, AES, and ECC operations. It will also use it for ECC key pair generation if you use PKCS #11 interfaces. Lennie Dymoke-Bradshaw: > ... ICSF without a Crypto Express card. ... However, this only > supports clear keys in the CKDS. The CKDS ... is different in > some way and cannot be converted to a secure key CKDS. True. There is an unsupported way to convert from clear key only CKDS to secure key (and clear key) CKDS but it's not for the faint of heart (since you are messing directly with your KDS). Lennie Dymoke-Bradshaw: > I don't know if there is a way of using the PKDS or TKDS in > this configuration. PKDS, no. TKDS, yes. The TKDS existed before EP11 existed. Lennie Dymoke-Bradshaw: > I have been told it is possible to run Data set encryption > with CPACF only and a clear key CKDS This is possible, but less secure since the keys are not protected by a master key. Timothy Sipples: > ICSF supports many, many cryptography-dependent features in > z/OS. Even many business applications that just need a simple > API to get a random number rely on ICSF. ICSF is > “darn important.” Thank you! I might be biased but I think everyone should have ICSF. Timothy Sipples: > And if persistent TLS connections are an option then they’d > dramatically reduce the number of network roundtrips, > eliminating a lot of network latency. Agreed. Also, System SSL session caching is also quite helpful. Eric Rossman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Encryption and decryption - processor or TCPIP
No need to apologise; You made me snigger. “Fix it with finance” is what I often use. Caveat vendor? Cheers, Martin From: IBM Mainframe Discussion List on behalf of Lennie Dymoke-Bradshaw <032fff1be9b4-dmarc-requ...@listserv.ua.edu> Date: Wednesday, 24 January 2024 at 13:19 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Encryption and decryption - processor or TCPIP Sorry MaRtin. L -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lennie Dymoke-Bradshaw Sent: 24 January 2024 13:09 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP Matin said " Easily managed by provisioning enough zIIP." As one of my old manager's used to say, "you can solve anything with a pot of gold". -Original Message- From: IBM Mainframe Discussion List On Behalf Of Martin Packer Sent: 24 January 2024 12:51 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP Thanks. Then if I see zIIP for TCP/IP I should tentatively conclude it's this. The interesting bit would be if this zIIP usage were large - and pre-empting Db2 Engine. Easily managed by provisioning enough zIIP. Cheers, Martin From: IBM Mainframe Discussion List on behalf of Lennie Dymoke-Bradshaw <032fff1be9b4-dmarc-requ...@listserv.ua.edu> Date: Wednesday, 24 January 2024 at 11:58 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Encryption and decryption - processor or TCPIP Martin, As Timothy has pointed out, it is for IPSEC processing that a zIIP is used, not AT/TLS. I think you are correct that this would show against the TCP/IP address space. But I think you should confirm that with others. (e.g. Chris Meyer) Lennie -Original Message- From: IBM Mainframe Discussion List On Behalf Of Martin Packer Sent: 24 January 2024 10:10 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP In the back of my mind I also think that the crypto processing for TCP/IP could be performed on a zIIP processor (which could be using its CPACF, of course). Lennie, or anybody who knows, which address space would show zIIP CPU time under those circumstances? I'm assuming TCP/IP address space(s) - which generally are in SYSSTC and so above eg Db2 Engine. (At this point I'm interested in detecting / sizing such goings on - probably with SMF 30.) Thanks, Martin From: IBM Mainframe Discussion List on behalf of Lennie Dymoke-Bradshaw <032fff1be9b4-dmarc-requ...@listserv.ua.edu> Date: Wednesday, 24 January 2024 at 09:53 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Encryption and decryption - processor or TCPIP Tom, It is possible to initialise ICSF without a Crypto Express card. I have done it. Changes were made to ICSF in support of that initialisation many years ago. It does require the CPACF. However, this only supports clear keys in the CKDS. The CKDS formatting is different in some way and cannot be converted to a secure key CKDS. I don't know if there is a way of using the PKDS or TKDS in this configuration. I have been told it is possible to run Data set encryption with CPACF only and a clear key CKDS, but I have not tried this. My understanding is that System SSL libraries use code that works out what facilities are available and uses the "best" option. CPACF on the later machines has some support for asymmetric keys so that could potentially help with handshakes. Earlier machines with CPACF could only do symmetric key processing. In the back of my mind I also think that the crypto processing for TCP/IP could be performed on a zIIP processor (which could be using its CPACF, of course). Lennie Dymoke-Bradshaw https: //rsclweb.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: 24 January 2024 08:49 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP Woah... right now I'm only about 1000 miles from Timothy so I get to see his responses in real time and not California time :) So Timothy (and probably just for me), I've seen a couple of sites without crypto HSM cards not bother to run ICSF. Can I assume in that case there's pretty-much no way any encryption processing could be using CPACF? On 1/24/2024 12:29 AM, Timothy Sipples wrote: > Peter wrote: >> I have a general question here. When you don't have crypto processor, >> So when a ATTLS traffic is enabled does the encryption and decryption >> handled by Started task TCPIP or the general processor? > > I've seen some of the follow-up messages, and it seems like you're > trying to troubleshoot a performance/throughput-related issue. Or at least you'd like to understand what changed, why you may be observing an elongation in your transaction times from CICS's perspective. > > "Crypto processor" could refer to the CP Assist for Cryptographic Functions (C
Re: Encryption and decryption - processor or TCPIP
Sorry MaRtin. L -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lennie Dymoke-Bradshaw Sent: 24 January 2024 13:09 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP Matin said " Easily managed by provisioning enough zIIP." As one of my old manager's used to say, "you can solve anything with a pot of gold". -Original Message- From: IBM Mainframe Discussion List On Behalf Of Martin Packer Sent: 24 January 2024 12:51 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP Thanks. Then if I see zIIP for TCP/IP I should tentatively conclude it's this. The interesting bit would be if this zIIP usage were large - and pre-empting Db2 Engine. Easily managed by provisioning enough zIIP. Cheers, Martin From: IBM Mainframe Discussion List on behalf of Lennie Dymoke-Bradshaw <032fff1be9b4-dmarc-requ...@listserv.ua.edu> Date: Wednesday, 24 January 2024 at 11:58 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Encryption and decryption - processor or TCPIP Martin, As Timothy has pointed out, it is for IPSEC processing that a zIIP is used, not AT/TLS. I think you are correct that this would show against the TCP/IP address space. But I think you should confirm that with others. (e.g. Chris Meyer) Lennie -Original Message- From: IBM Mainframe Discussion List On Behalf Of Martin Packer Sent: 24 January 2024 10:10 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP In the back of my mind I also think that the crypto processing for TCP/IP could be performed on a zIIP processor (which could be using its CPACF, of course). Lennie, or anybody who knows, which address space would show zIIP CPU time under those circumstances? I'm assuming TCP/IP address space(s) - which generally are in SYSSTC and so above eg Db2 Engine. (At this point I'm interested in detecting / sizing such goings on - probably with SMF 30.) Thanks, Martin From: IBM Mainframe Discussion List on behalf of Lennie Dymoke-Bradshaw <032fff1be9b4-dmarc-requ...@listserv.ua.edu> Date: Wednesday, 24 January 2024 at 09:53 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Encryption and decryption - processor or TCPIP Tom, It is possible to initialise ICSF without a Crypto Express card. I have done it. Changes were made to ICSF in support of that initialisation many years ago. It does require the CPACF. However, this only supports clear keys in the CKDS. The CKDS formatting is different in some way and cannot be converted to a secure key CKDS. I don't know if there is a way of using the PKDS or TKDS in this configuration. I have been told it is possible to run Data set encryption with CPACF only and a clear key CKDS, but I have not tried this. My understanding is that System SSL libraries use code that works out what facilities are available and uses the "best" option. CPACF on the later machines has some support for asymmetric keys so that could potentially help with handshakes. Earlier machines with CPACF could only do symmetric key processing. In the back of my mind I also think that the crypto processing for TCP/IP could be performed on a zIIP processor (which could be using its CPACF, of course). Lennie Dymoke-Bradshaw https: //rsclweb.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: 24 January 2024 08:49 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP Woah... right now I'm only about 1000 miles from Timothy so I get to see his responses in real time and not California time :) So Timothy (and probably just for me), I've seen a couple of sites without crypto HSM cards not bother to run ICSF. Can I assume in that case there's pretty-much no way any encryption processing could be using CPACF? On 1/24/2024 12:29 AM, Timothy Sipples wrote: > Peter wrote: >> I have a general question here. When you don't have crypto processor, >> So when a ATTLS traffic is enabled does the encryption and decryption >> handled by Started task TCPIP or the general processor? > > I've seen some of the follow-up messages, and it seems like you're > trying to troubleshoot a performance/throughput-related issue. Or at least you'd like to understand what changed, why you may be observing an elongation in your transaction times from CICS's perspective. > > "Crypto processor" could refer to the CP Assist for Cryptographic Functions (CPACF) or to the IBM Crypto Express hardware security modules (HSMs). CPACF is an integral part of every main processor that's on every modern IBM Z and all IBM LinuxONE machine models. You need to have Feature Code 3863 installed to enable CPACF's full set of cryptographic algorithms. So just make sure that feature code is installed on all your machines. CPACF is an integral part of your mai
Re: Encryption and decryption - processor or TCPIP
Matin said " Easily managed by provisioning enough zIIP." As one of my old manager's used to say, "you can solve anything with a pot of gold". -Original Message- From: IBM Mainframe Discussion List On Behalf Of Martin Packer Sent: 24 January 2024 12:51 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP Thanks. Then if I see zIIP for TCP/IP I should tentatively conclude it's this. The interesting bit would be if this zIIP usage were large - and pre-empting Db2 Engine. Easily managed by provisioning enough zIIP. Cheers, Martin From: IBM Mainframe Discussion List on behalf of Lennie Dymoke-Bradshaw <032fff1be9b4-dmarc-requ...@listserv.ua.edu> Date: Wednesday, 24 January 2024 at 11:58 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Encryption and decryption - processor or TCPIP Martin, As Timothy has pointed out, it is for IPSEC processing that a zIIP is used, not AT/TLS. I think you are correct that this would show against the TCP/IP address space. But I think you should confirm that with others. (e.g. Chris Meyer) Lennie -Original Message- From: IBM Mainframe Discussion List On Behalf Of Martin Packer Sent: 24 January 2024 10:10 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP In the back of my mind I also think that the crypto processing for TCP/IP could be performed on a zIIP processor (which could be using its CPACF, of course). Lennie, or anybody who knows, which address space would show zIIP CPU time under those circumstances? I'm assuming TCP/IP address space(s) - which generally are in SYSSTC and so above eg Db2 Engine. (At this point I'm interested in detecting / sizing such goings on - probably with SMF 30.) Thanks, Martin From: IBM Mainframe Discussion List on behalf of Lennie Dymoke-Bradshaw <032fff1be9b4-dmarc-requ...@listserv.ua.edu> Date: Wednesday, 24 January 2024 at 09:53 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Encryption and decryption - processor or TCPIP Tom, It is possible to initialise ICSF without a Crypto Express card. I have done it. Changes were made to ICSF in support of that initialisation many years ago. It does require the CPACF. However, this only supports clear keys in the CKDS. The CKDS formatting is different in some way and cannot be converted to a secure key CKDS. I don't know if there is a way of using the PKDS or TKDS in this configuration. I have been told it is possible to run Data set encryption with CPACF only and a clear key CKDS, but I have not tried this. My understanding is that System SSL libraries use code that works out what facilities are available and uses the "best" option. CPACF on the later machines has some support for asymmetric keys so that could potentially help with handshakes. Earlier machines with CPACF could only do symmetric key processing. In the back of my mind I also think that the crypto processing for TCP/IP could be performed on a zIIP processor (which could be using its CPACF, of course). Lennie Dymoke-Bradshaw https: //rsclweb.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: 24 January 2024 08:49 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP Woah... right now I'm only about 1000 miles from Timothy so I get to see his responses in real time and not California time :) So Timothy (and probably just for me), I've seen a couple of sites without crypto HSM cards not bother to run ICSF. Can I assume in that case there's pretty-much no way any encryption processing could be using CPACF? On 1/24/2024 12:29 AM, Timothy Sipples wrote: > Peter wrote: >> I have a general question here. When you don't have crypto processor, >> So when a ATTLS traffic is enabled does the encryption and decryption >> handled by Started task TCPIP or the general processor? > > I've seen some of the follow-up messages, and it seems like you're > trying to troubleshoot a performance/throughput-related issue. Or at least you'd like to understand what changed, why you may be observing an elongation in your transaction times from CICS's perspective. > > "Crypto processor" could refer to the CP Assist for Cryptographic Functions (CPACF) or to the IBM Crypto Express hardware security modules (HSMs). CPACF is an integral part of every main processor that's on every modern IBM Z and all IBM LinuxONE machine models. You need to have Feature Code 3863 installed to enable CPACF's full set of cryptographic algorithms. So just make sure that feature code is installed on all your machines. CPACF is an integral part of your main processors that supports additional instructions that accelerate lots of cryptographic operations. > > IBM Crypto Express HSMs are optional (but strongly recommended!) > features that are installed as cards in your IBM Z or
Re: Encryption and decryption - processor or TCPIP
Thanks. Then if I see zIIP for TCP/IP I should tentatively conclude it’s this. The interesting bit would be if this zIIP usage were large – and pre-empting Db2 Engine. Easily managed by provisioning enough zIIP. Cheers, Martin From: IBM Mainframe Discussion List on behalf of Lennie Dymoke-Bradshaw <032fff1be9b4-dmarc-requ...@listserv.ua.edu> Date: Wednesday, 24 January 2024 at 11:58 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Encryption and decryption - processor or TCPIP Martin, As Timothy has pointed out, it is for IPSEC processing that a zIIP is used, not AT/TLS. I think you are correct that this would show against the TCP/IP address space. But I think you should confirm that with others. (e.g. Chris Meyer) Lennie -Original Message- From: IBM Mainframe Discussion List On Behalf Of Martin Packer Sent: 24 January 2024 10:10 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP In the back of my mind I also think that the crypto processing for TCP/IP could be performed on a zIIP processor (which could be using its CPACF, of course). Lennie, or anybody who knows, which address space would show zIIP CPU time under those circumstances? I'm assuming TCP/IP address space(s) - which generally are in SYSSTC and so above eg Db2 Engine. (At this point I'm interested in detecting / sizing such goings on - probably with SMF 30.) Thanks, Martin From: IBM Mainframe Discussion List on behalf of Lennie Dymoke-Bradshaw <032fff1be9b4-dmarc-requ...@listserv.ua.edu> Date: Wednesday, 24 January 2024 at 09:53 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Encryption and decryption - processor or TCPIP Tom, It is possible to initialise ICSF without a Crypto Express card. I have done it. Changes were made to ICSF in support of that initialisation many years ago. It does require the CPACF. However, this only supports clear keys in the CKDS. The CKDS formatting is different in some way and cannot be converted to a secure key CKDS. I don't know if there is a way of using the PKDS or TKDS in this configuration. I have been told it is possible to run Data set encryption with CPACF only and a clear key CKDS, but I have not tried this. My understanding is that System SSL libraries use code that works out what facilities are available and uses the "best" option. CPACF on the later machines has some support for asymmetric keys so that could potentially help with handshakes. Earlier machines with CPACF could only do symmetric key processing. In the back of my mind I also think that the crypto processing for TCP/IP could be performed on a zIIP processor (which could be using its CPACF, of course). Lennie Dymoke-Bradshaw https: //rsclweb.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: 24 January 2024 08:49 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP Woah... right now I'm only about 1000 miles from Timothy so I get to see his responses in real time and not California time :) So Timothy (and probably just for me), I've seen a couple of sites without crypto HSM cards not bother to run ICSF. Can I assume in that case there's pretty-much no way any encryption processing could be using CPACF? On 1/24/2024 12:29 AM, Timothy Sipples wrote: > Peter wrote: >> I have a general question here. When you don't have crypto processor, >> So when a ATTLS traffic is enabled does the encryption and decryption >> handled by Started task TCPIP or the general processor? > > I've seen some of the follow-up messages, and it seems like you're > trying to troubleshoot a performance/throughput-related issue. Or at least you'd like to understand what changed, why you may be observing an elongation in your transaction times from CICS's perspective. > > "Crypto processor" could refer to the CP Assist for Cryptographic Functions (CPACF) or to the IBM Crypto Express hardware security modules (HSMs). CPACF is an integral part of every main processor that's on every modern IBM Z and all IBM LinuxONE machine models. You need to have Feature Code 3863 installed to enable CPACF's full set of cryptographic algorithms. So just make sure that feature code is installed on all your machines. CPACF is an integral part of your main processors that supports additional instructions that accelerate lots of cryptographic operations. > > IBM Crypto Express HSMs are optional (but strongly recommended!) > features that are installed as cards in your IBM Z or IBM LinuxONE > server's PCI slots. In recent models there are two variants of the IBM > Crypto Express cards: "single port" and "dual port." Dual port means > that there are two physical HSMs per card. It's simply a higher > density card that allows you to support more HSM domains and modes > within a smaller physical space, analogous
Re: Encryption and decryption - processor or TCPIP
Martin, As Timothy has pointed out, it is for IPSEC processing that a zIIP is used, not AT/TLS. I think you are correct that this would show against the TCP/IP address space. But I think you should confirm that with others. (e.g. Chris Meyer) Lennie -Original Message- From: IBM Mainframe Discussion List On Behalf Of Martin Packer Sent: 24 January 2024 10:10 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP In the back of my mind I also think that the crypto processing for TCP/IP could be performed on a zIIP processor (which could be using its CPACF, of course). Lennie, or anybody who knows, which address space would show zIIP CPU time under those circumstances? I'm assuming TCP/IP address space(s) - which generally are in SYSSTC and so above eg Db2 Engine. (At this point I'm interested in detecting / sizing such goings on - probably with SMF 30.) Thanks, Martin From: IBM Mainframe Discussion List on behalf of Lennie Dymoke-Bradshaw <032fff1be9b4-dmarc-requ...@listserv.ua.edu> Date: Wednesday, 24 January 2024 at 09:53 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Encryption and decryption - processor or TCPIP Tom, It is possible to initialise ICSF without a Crypto Express card. I have done it. Changes were made to ICSF in support of that initialisation many years ago. It does require the CPACF. However, this only supports clear keys in the CKDS. The CKDS formatting is different in some way and cannot be converted to a secure key CKDS. I don't know if there is a way of using the PKDS or TKDS in this configuration. I have been told it is possible to run Data set encryption with CPACF only and a clear key CKDS, but I have not tried this. My understanding is that System SSL libraries use code that works out what facilities are available and uses the "best" option. CPACF on the later machines has some support for asymmetric keys so that could potentially help with handshakes. Earlier machines with CPACF could only do symmetric key processing. In the back of my mind I also think that the crypto processing for TCP/IP could be performed on a zIIP processor (which could be using its CPACF, of course). Lennie Dymoke-Bradshaw https: //rsclweb.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: 24 January 2024 08:49 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP Woah... right now I'm only about 1000 miles from Timothy so I get to see his responses in real time and not California time :) So Timothy (and probably just for me), I've seen a couple of sites without crypto HSM cards not bother to run ICSF. Can I assume in that case there's pretty-much no way any encryption processing could be using CPACF? On 1/24/2024 12:29 AM, Timothy Sipples wrote: > Peter wrote: >> I have a general question here. When you don't have crypto processor, >> So when a ATTLS traffic is enabled does the encryption and decryption >> handled by Started task TCPIP or the general processor? > > I've seen some of the follow-up messages, and it seems like you're > trying to troubleshoot a performance/throughput-related issue. Or at least you'd like to understand what changed, why you may be observing an elongation in your transaction times from CICS's perspective. > > "Crypto processor" could refer to the CP Assist for Cryptographic Functions (CPACF) or to the IBM Crypto Express hardware security modules (HSMs). CPACF is an integral part of every main processor that's on every modern IBM Z and all IBM LinuxONE machine models. You need to have Feature Code 3863 installed to enable CPACF's full set of cryptographic algorithms. So just make sure that feature code is installed on all your machines. CPACF is an integral part of your main processors that supports additional instructions that accelerate lots of cryptographic operations. > > IBM Crypto Express HSMs are optional (but strongly recommended!) > features that are installed as cards in your IBM Z or IBM LinuxONE > server's PCI slots. In recent models there are two variants of the IBM > Crypto Express cards: "single port" and "dual port." Dual port means > that there are two physical HSMs per card. It's simply a higher > density card that allows you to support more HSM domains and modes > within a smaller physical space, analogous to the difference between a > fully populated processor drawer and a partially populated one. > Whether you get the single port or dual port variant (or some of > both), their role is to protect secrets, especially private encryption > keys. They have their own onboard processors to execute cryptographic > operations, and you need them to move beyond "clear key" cryptography. > Clear key cryptography means your private encryption keys inhabit main > me
Re: Encryption and decryption - processor or TCPIP
Lennie Dymoke-Bradshaw wrote: >In the back of my mind I also think that the crypto processing for TCP/IP >could be performed on a zIIP processor (which could be using its CPACF, of >course). IPSec/IKEv2 can exploit zIIPs (and CPACF). https://www.ibm.com/docs/en/zos/3.1.0?topic=iv-additional-ipsec-assist-using-system-z-integrated-information-processor-ziip-ip-security But I think we’re drifting a bit. z/OS AT-TLS performs quite well if it’s configured correctly. And if persistent TLS connections are an option then they’d dramatically reduce the number of network roundtrips, eliminating a lot of network latency. — Timothy Sipples Senior Architect Digital Assets, Industry Solutions, and Cybersecurity IBM Z/LinuxONE, Asia-Pacific sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Encryption and decryption - processor or TCPIP
>So Timothy (and probably just for me), I've seen a couple >of sites without crypto HSM cards not bother to run ICSF. >Can I assume in that case there's pretty-much no way any >encryption processing could be using CPACF? ICSF supports many, many cryptography-dependent features in z/OS. Even many business applications that just need a simple API to get a random number rely on ICSF. ICSF is “darn important.” But the way you phrased your question I’d answer no. It’s technically possible to exploit CPACF even from within z/OS but without calling ICSF. One simple example that comes to mind is via the z/OS Container Extensions (zCX). You could have a running container image in zCX that’s using CPACF instructions — via an OpenSSL library, for example. (OpenSSL on this architecture knows how to exploit CPACF instructions and has for many years.) However, the container image has no direct access to ICSF. — Timothy Sipples Senior Architect Digital Assets, Industry Solutions, and Cybersecurity IBM Z/LinuxONE, Asia-Pacific sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Encryption and decryption - processor or TCPIP
In the back of my mind I also think that the crypto processing for TCP/IP could be performed on a zIIP processor (which could be using its CPACF, of course). Lennie, or anybody who knows, which address space would show zIIP CPU time under those circumstances? I’m assuming TCP/IP address space(s) – which generally are in SYSSTC and so above eg Db2 Engine. (At this point I’m interested in detecting / sizing such goings on – probably with SMF 30.) Thanks, Martin From: IBM Mainframe Discussion List on behalf of Lennie Dymoke-Bradshaw <032fff1be9b4-dmarc-requ...@listserv.ua.edu> Date: Wednesday, 24 January 2024 at 09:53 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Encryption and decryption - processor or TCPIP Tom, It is possible to initialise ICSF without a Crypto Express card. I have done it. Changes were made to ICSF in support of that initialisation many years ago. It does require the CPACF. However, this only supports clear keys in the CKDS. The CKDS formatting is different in some way and cannot be converted to a secure key CKDS. I don't know if there is a way of using the PKDS or TKDS in this configuration. I have been told it is possible to run Data set encryption with CPACF only and a clear key CKDS, but I have not tried this. My understanding is that System SSL libraries use code that works out what facilities are available and uses the "best" option. CPACF on the later machines has some support for asymmetric keys so that could potentially help with handshakes. Earlier machines with CPACF could only do symmetric key processing. In the back of my mind I also think that the crypto processing for TCP/IP could be performed on a zIIP processor (which could be using its CPACF, of course). Lennie Dymoke-Bradshaw https: //rsclweb.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: 24 January 2024 08:49 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP Woah... right now I'm only about 1000 miles from Timothy so I get to see his responses in real time and not California time :) So Timothy (and probably just for me), I've seen a couple of sites without crypto HSM cards not bother to run ICSF. Can I assume in that case there's pretty-much no way any encryption processing could be using CPACF? On 1/24/2024 12:29 AM, Timothy Sipples wrote: > Peter wrote: >> I have a general question here. When you don't have crypto processor, >> So when a ATTLS traffic is enabled does the encryption and decryption >> handled by Started task TCPIP or the general processor? > > I've seen some of the follow-up messages, and it seems like you're trying to troubleshoot a performance/throughput-related issue. Or at least you'd like to understand what changed, why you may be observing an elongation in your transaction times from CICS's perspective. > > "Crypto processor" could refer to the CP Assist for Cryptographic Functions (CPACF) or to the IBM Crypto Express hardware security modules (HSMs). CPACF is an integral part of every main processor that's on every modern IBM Z and all IBM LinuxONE machine models. You need to have Feature Code 3863 installed to enable CPACF's full set of cryptographic algorithms. So just make sure that feature code is installed on all your machines. CPACF is an integral part of your main processors that supports additional instructions that accelerate lots of cryptographic operations. > > IBM Crypto Express HSMs are optional (but strongly recommended!) > features that are installed as cards in your IBM Z or IBM LinuxONE > server's PCI slots. In recent models there are two variants of the IBM > Crypto Express cards: "single port" and "dual port." Dual port means > that there are two physical HSMs per card. It's simply a higher > density card that allows you to support more HSM domains and modes > within a smaller physical space, analogous to the difference between a > fully populated processor drawer and a partially populated one. > Whether you get the single port or dual port variant (or some of > both), their role is to protect secrets, especially private encryption > keys. They have their own onboard processors to execute cryptographic > operations, and you need them to move beyond "clear key" cryptography. > Clear key cryptography means your private encryption keys inhabit main > memory, the same memory that the operating system, middleware, and > applications inhabit. Conceivably that memory could be accessed - via > a dump that hasn't been redacted, for example - to obtain the private > keys. The vast majority of non-IBM Z/LinuxONE systems that support TLS > are operating with clear key, but "we can do better." And we do: > Crypto Express facilitates protected key and secure key operations. > Get them, use them, lo
Re: Encryption and decryption - processor or TCPIP
Tom, It is possible to initialise ICSF without a Crypto Express card. I have done it. Changes were made to ICSF in support of that initialisation many years ago. It does require the CPACF. However, this only supports clear keys in the CKDS. The CKDS formatting is different in some way and cannot be converted to a secure key CKDS. I don't know if there is a way of using the PKDS or TKDS in this configuration. I have been told it is possible to run Data set encryption with CPACF only and a clear key CKDS, but I have not tried this. My understanding is that System SSL libraries use code that works out what facilities are available and uses the "best" option. CPACF on the later machines has some support for asymmetric keys so that could potentially help with handshakes. Earlier machines with CPACF could only do symmetric key processing. In the back of my mind I also think that the crypto processing for TCP/IP could be performed on a zIIP processor (which could be using its CPACF, of course). Lennie Dymoke-Bradshaw https: //rsclweb.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: 24 January 2024 08:49 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Encryption and decryption - processor or TCPIP Woah... right now I'm only about 1000 miles from Timothy so I get to see his responses in real time and not California time :) So Timothy (and probably just for me), I've seen a couple of sites without crypto HSM cards not bother to run ICSF. Can I assume in that case there's pretty-much no way any encryption processing could be using CPACF? On 1/24/2024 12:29 AM, Timothy Sipples wrote: > Peter wrote: >> I have a general question here. When you don't have crypto processor, >> So when a ATTLS traffic is enabled does the encryption and decryption >> handled by Started task TCPIP or the general processor? > > I've seen some of the follow-up messages, and it seems like you're trying to troubleshoot a performance/throughput-related issue. Or at least you'd like to understand what changed, why you may be observing an elongation in your transaction times from CICS's perspective. > > "Crypto processor" could refer to the CP Assist for Cryptographic Functions (CPACF) or to the IBM Crypto Express hardware security modules (HSMs). CPACF is an integral part of every main processor that's on every modern IBM Z and all IBM LinuxONE machine models. You need to have Feature Code 3863 installed to enable CPACF's full set of cryptographic algorithms. So just make sure that feature code is installed on all your machines. CPACF is an integral part of your main processors that supports additional instructions that accelerate lots of cryptographic operations. > > IBM Crypto Express HSMs are optional (but strongly recommended!) > features that are installed as cards in your IBM Z or IBM LinuxONE > server's PCI slots. In recent models there are two variants of the IBM > Crypto Express cards: "single port" and "dual port." Dual port means > that there are two physical HSMs per card. It's simply a higher > density card that allows you to support more HSM domains and modes > within a smaller physical space, analogous to the difference between a > fully populated processor drawer and a partially populated one. > Whether you get the single port or dual port variant (or some of > both), their role is to protect secrets, especially private encryption > keys. They have their own onboard processors to execute cryptographic > operations, and you need them to move beyond "clear key" cryptography. > Clear key cryptography means your private encryption keys inhabit main > memory, the same memory that the operating system, middleware, and > applications inhabit. Conceivably that memory could be accessed - via > a dump that hasn't been redacted, for example - to obtain the private > keys. The vast majority of non-IBM Z/LinuxONE systems that support TLS > are operating with clear key, but "we can do better." And we do: > Crypto Express facilitates protected key and secure key operations. > Get them, use them, love them. :-) > > But let's leave that HSM point aside for the moment and just focus on z/OS AT-TLS and what you may be observing. If you're actually seeing longer transaction times - if you've got reasonable evidence this one change (changing an unencrypted connection to a TLS encrypted connection) made the difference - then there are likely one or two basic reasons why. One likely reason is that you're not getting a good match between z/OS AT-TLS and CPACF. That is, z/OS AT-TLS (and specifically the z/OS System SSL component that AT-TLS uses) isn't exploiting CPACF as much as it could. For example, AT-TLS and the other party to the network connection may have mutually negotiated a cipher suite that's less than idea
Re: Encryption and decryption - processor or TCPIP
Woah... right now I'm only about 1000 miles from Timothy so I get to see his responses in real time and not California time :) So Timothy (and probably just for me), I've seen a couple of sites without crypto HSM cards not bother to run ICSF. Can I assume in that case there's pretty-much no way any encryption processing could be using CPACF? On 1/24/2024 12:29 AM, Timothy Sipples wrote: Peter wrote: I have a general question here. When you don't have crypto processor, So when a ATTLS traffic is enabled does the encryption and decryption handled by Started task TCPIP or the general processor? I’ve seen some of the follow-up messages, and it seems like you’re trying to troubleshoot a performance/throughput-related issue. Or at least you’d like to understand what changed, why you may be observing an elongation in your transaction times from CICS’s perspective. “Crypto processor” could refer to the CP Assist for Cryptographic Functions (CPACF) or to the IBM Crypto Express hardware security modules (HSMs). CPACF is an integral part of every main processor that’s on every modern IBM Z and all IBM LinuxONE machine models. You need to have Feature Code 3863 installed to enable CPACF’s full set of cryptographic algorithms. So just make sure that feature code is installed on all your machines. CPACF is an integral part of your main processors that supports additional instructions that accelerate lots of cryptographic operations. IBM Crypto Express HSMs are optional (but strongly recommended!) features that are installed as cards in your IBM Z or IBM LinuxONE server’s PCI slots. In recent models there are two variants of the IBM Crypto Express cards: “single port” and “dual port.” Dual port means that there are two physical HSMs per card. It’s simply a higher density card that allows you to support more HSM domains and modes within a smaller physical space, analogous to the difference between a fully populated processor drawer and a partially populated one. Whether you get the single port or dual port variant (or some of both), their role is to protect secrets, especially private encryption keys. They have their own onboard processors to execute cryptographic operations, and you need them to move beyond “clear key” cryptography. Clear key cryptography means your private encryption keys inhabit main memory, the same memory that the operating system, middleware, and applications inhabit. Conceivably that memory could be accessed — via a dump that hasn’t been redacted, for example — to obtain the private keys. The vast majority of non-IBM Z/LinuxONE systems that support TLS are operating with clear key, but “we can do better.” And we do: Crypto Express facilitates protected key and secure key operations. Get them, use them, love them. :-) But let’s leave that HSM point aside for the moment and just focus on z/OS AT-TLS and what you may be observing. If you’re actually seeing longer transaction times — if you’ve got reasonable evidence this one change (changing an unencrypted connection to a TLS encrypted connection) made the difference — then there are likely one or two basic reasons why. One likely reason is that you’re not getting a good match between z/OS AT-TLS and CPACF. That is, z/OS AT-TLS (and specifically the z/OS System SSL component that AT-TLS uses) isn’t exploiting CPACF as much as it could. For example, AT-TLS and the other party to the network connection may have mutually negotiated a cipher suite that’s less than ideal for CPACF exploitation. Generally you should “encourage” (or even require) one of the AES GCM cipher suites, and you can do that by configuring AT-TLS to prefer certain cipher suites and outright reject several. And of course you should use only TLS 1.2 or higher, with weak cipher suites disabled. So... check your cipher suite(s). Next, do you have the appropriate software levels that can exploit CPACF well on your machine? ICSF and System SSL are quite important, so check those levels especially. Do you see newer releases (or PTFs) with better CPACF exploitation? Get them on if you can. There are some tools and traces you can use to figure out how much CPACF exploitation you’re getting. Finally, you could be observing the natural effects of non-persistent TLS connections. When you establish a new TLS connection there’s an initial handshake, a negotiation that takes place to establish the secure connection before the two systems exchange real data. If you’re comparing non-persistent TLS connections to unencrypted connections then you should see double the number of network roundtrips: one set of roundtrips to establish the TLS connection, then the real data-bearing roundtrips over the TLS connection. And these extra hops may be OK! It may be just the “cost of doing business” when you turn on TLS to secure your network connections. Non-persistent TLS connections are not much of a direct processor utilization concern if
Re: Encryption and decryption - processor or TCPIP
My case was before AT-TLS, when I believe it was up to each application to handle the encryption themselves, so we saw a big spike and delay in the SSHD task each time someone logged on. That timing contributed to my theory about the prime number generation or similar initial encryption processing. There was no spike in TCPIP which I believe had no part in the encryption processing prior to AT-TLS. After AT-TLS? I don't have experience. On 1/23/2024 10:49 PM, Peter wrote: Ok so TCPIP as a started task when it does encryption and decryption so it directly overloads the General CP ? On Wed, Jan 24, 2024, 9:59 AM Tom Brennan wrote: Even though you don't have a crypto processor, do you have CPACF on the box? Most machines I've seen do, because it's a no-charge feature. I don't know for sure, but I thought I heard that you can start ICSF without a crypto card and it will use CPACF for some of the heavier encryption processing (maybe like generating prime numbers) and save individual tasks some CP time. That's just my old theory though, from back in 2015 when I saw a situation similar to what you describe. But it was a client machine where I didn't have the ability to try things out. I'd sure like to hear more from someone more experienced in this area. On 1/23/2024 9:10 PM, Peter wrote: After implementing ATTLS there is some delay in our CICS transaction but I was suspecting if sn absence of crypto processor can overload the general processor to cause this delay ? On Wed, Jan 24, 2024, 9:01 AM Phil Smith III wrote: Peter wrote: I have a general question here. When you don't have crypto processor, So when a ATTLS traffic is enabled does the encryption and decryption handled by Started task TCPIP or the general processor? The TCPIP started task is just code and runs on the general processor, so your question doesn't make much sense. AT-TLS is managed by the Policy Agent started task, and it appears that the actual encryption takes place in the TCPIP started task, but that's a conclusion-I've never wondered. Why do you ask? What problem are you trying to solve? We'd like to know more! -- 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
Re: Encryption and decryption - processor or TCPIP
It would be worth looking at the RMF report on the crypto processing and seeing if they are running hot. Does the PAGENT address space a lot of CPU - is it delayed? The code may execute on your CICS TCB - executing cross memory (via PC) in the TCPIP address space(s).I don't recall seeing anything about tuning the number of threads in TCPIP for crypto work. There are some counts for crypto activity in the SMF 30 records. Colin On Wed, 24 Jan 2024 at 05:10, Peter wrote: > After implementing ATTLS there is some delay in our CICS transaction but I > was suspecting if sn absence of crypto processor can overload the general > processor to cause this delay ? > > On Wed, Jan 24, 2024, 9:01 AM Phil Smith III wrote: > > > Peter wrote: > > >I have a general question here. When you don't have crypto processor, So > > >when a ATTLS traffic is enabled does the encryption and decryption > handled > > >by Started task TCPIP or the general processor? > > > > The TCPIP started task is just code and runs on the general processor, so > > your question doesn't make much sense. AT-TLS is managed > > by the Policy Agent started task, and it appears that the actual > > encryption takes place in the TCPIP started task, but that's a > > conclusion-I've never wondered. > > > > Why do you ask? What problem are you trying to solve? We'd like to know > > more! > > > > > > -- > > 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
Re: Encryption and decryption - processor or TCPIP
Peter wrote: >I have a general question here. When you don't have crypto processor, So >when a ATTLS traffic is enabled does the encryption and decryption handled >by Started task TCPIP or the general processor? I’ve seen some of the follow-up messages, and it seems like you’re trying to troubleshoot a performance/throughput-related issue. Or at least you’d like to understand what changed, why you may be observing an elongation in your transaction times from CICS’s perspective. “Crypto processor” could refer to the CP Assist for Cryptographic Functions (CPACF) or to the IBM Crypto Express hardware security modules (HSMs). CPACF is an integral part of every main processor that’s on every modern IBM Z and all IBM LinuxONE machine models. You need to have Feature Code 3863 installed to enable CPACF’s full set of cryptographic algorithms. So just make sure that feature code is installed on all your machines. CPACF is an integral part of your main processors that supports additional instructions that accelerate lots of cryptographic operations. IBM Crypto Express HSMs are optional (but strongly recommended!) features that are installed as cards in your IBM Z or IBM LinuxONE server’s PCI slots. In recent models there are two variants of the IBM Crypto Express cards: “single port” and “dual port.” Dual port means that there are two physical HSMs per card. It’s simply a higher density card that allows you to support more HSM domains and modes within a smaller physical space, analogous to the difference between a fully populated processor drawer and a partially populated one. Whether you get the single port or dual port variant (or some of both), their role is to protect secrets, especially private encryption keys. They have their own onboard processors to execute cryptographic operations, and you need them to move beyond “clear key” cryptography. Clear key cryptography means your private encryption keys inhabit main memory, the same memory that the operating system, middleware, and applications inhabit. Conceivably that memory could be accessed — via a dump that hasn’t been redacted, for example — to obtain the private keys. The vast majority of non-IBM Z/LinuxONE systems that support TLS are operating with clear key, but “we can do better.” And we do: Crypto Express facilitates protected key and secure key operations. Get them, use them, love them. :-) But let’s leave that HSM point aside for the moment and just focus on z/OS AT-TLS and what you may be observing. If you’re actually seeing longer transaction times — if you’ve got reasonable evidence this one change (changing an unencrypted connection to a TLS encrypted connection) made the difference — then there are likely one or two basic reasons why. One likely reason is that you’re not getting a good match between z/OS AT-TLS and CPACF. That is, z/OS AT-TLS (and specifically the z/OS System SSL component that AT-TLS uses) isn’t exploiting CPACF as much as it could. For example, AT-TLS and the other party to the network connection may have mutually negotiated a cipher suite that’s less than ideal for CPACF exploitation. Generally you should “encourage” (or even require) one of the AES GCM cipher suites, and you can do that by configuring AT-TLS to prefer certain cipher suites and outright reject several. And of course you should use only TLS 1.2 or higher, with weak cipher suites disabled. So... check your cipher suite(s). Next, do you have the appropriate software levels that can exploit CPACF well on your machine? ICSF and System SSL are quite important, so check those levels especially. Do you see newer releases (or PTFs) with better CPACF exploitation? Get them on if you can. There are some tools and traces you can use to figure out how much CPACF exploitation you’re getting. Finally, you could be observing the natural effects of non-persistent TLS connections. When you establish a new TLS connection there’s an initial handshake, a negotiation that takes place to establish the secure connection before the two systems exchange real data. If you’re comparing non-persistent TLS connections to unencrypted connections then you should see double the number of network roundtrips: one set of roundtrips to establish the TLS connection, then the real data-bearing roundtrips over the TLS connection. And these extra hops may be OK! It may be just the “cost of doing business” when you turn on TLS to secure your network connections. Non-persistent TLS connections are not much of a direct processor utilization concern if you’ve got CPACF instructions exploited well, but it may be a latency concern. Greater latency, in turn, could have some secondary processor utilization effects. If you’re concerned about the extra network roundtrips that TLS handshaking requires then you can check whether you can establish persistent connections instead. And a persistent connection could be TLS, IPSec/IKEv2, or a SSH
Re: Encryption and decryption - processor or TCPIP
Ok so TCPIP as a started task when it does encryption and decryption so it directly overloads the General CP ? On Wed, Jan 24, 2024, 9:59 AM Tom Brennan wrote: > Even though you don't have a crypto processor, do you have CPACF on the > box? Most machines I've seen do, because it's a no-charge feature. I > don't know for sure, but I thought I heard that you can start ICSF > without a crypto card and it will use CPACF for some of the heavier > encryption processing (maybe like generating prime numbers) and save > individual tasks some CP time. > > That's just my old theory though, from back in 2015 when I saw a > situation similar to what you describe. But it was a client machine > where I didn't have the ability to try things out. I'd sure like to > hear more from someone more experienced in this area. > > On 1/23/2024 9:10 PM, Peter wrote: > > After implementing ATTLS there is some delay in our CICS transaction but > I > > was suspecting if sn absence of crypto processor can overload the general > > processor to cause this delay ? > > > > On Wed, Jan 24, 2024, 9:01 AM Phil Smith III wrote: > > > >> Peter wrote: > >>> I have a general question here. When you don't have crypto processor, > So > >>> when a ATTLS traffic is enabled does the encryption and decryption > handled > >>> by Started task TCPIP or the general processor? > >> > >> The TCPIP started task is just code and runs on the general processor, > so > >> your question doesn't make much sense. AT-TLS is managed > >> by the Policy Agent started task, and it appears that the actual > >> encryption takes place in the TCPIP started task, but that's a > >> conclusion-I've never wondered. > >> > >> Why do you ask? What problem are you trying to solve? We'd like to know > >> more! > >> > >> > >> -- > >> 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
Re: Encryption and decryption - processor or TCPIP
Even though you don't have a crypto processor, do you have CPACF on the box? Most machines I've seen do, because it's a no-charge feature. I don't know for sure, but I thought I heard that you can start ICSF without a crypto card and it will use CPACF for some of the heavier encryption processing (maybe like generating prime numbers) and save individual tasks some CP time. That's just my old theory though, from back in 2015 when I saw a situation similar to what you describe. But it was a client machine where I didn't have the ability to try things out. I'd sure like to hear more from someone more experienced in this area. On 1/23/2024 9:10 PM, Peter wrote: After implementing ATTLS there is some delay in our CICS transaction but I was suspecting if sn absence of crypto processor can overload the general processor to cause this delay ? On Wed, Jan 24, 2024, 9:01 AM Phil Smith III wrote: Peter wrote: I have a general question here. When you don't have crypto processor, So when a ATTLS traffic is enabled does the encryption and decryption handled by Started task TCPIP or the general processor? The TCPIP started task is just code and runs on the general processor, so your question doesn't make much sense. AT-TLS is managed by the Policy Agent started task, and it appears that the actual encryption takes place in the TCPIP started task, but that's a conclusion-I've never wondered. Why do you ask? What problem are you trying to solve? We'd like to know more! -- 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
Re: Encryption and decryption - processor or TCPIP
After implementing ATTLS there is some delay in our CICS transaction but I was suspecting if sn absence of crypto processor can overload the general processor to cause this delay ? On Wed, Jan 24, 2024, 9:01 AM Phil Smith III wrote: > Peter wrote: > >I have a general question here. When you don't have crypto processor, So > >when a ATTLS traffic is enabled does the encryption and decryption handled > >by Started task TCPIP or the general processor? > > The TCPIP started task is just code and runs on the general processor, so > your question doesn't make much sense. AT-TLS is managed > by the Policy Agent started task, and it appears that the actual > encryption takes place in the TCPIP started task, but that's a > conclusion-I've never wondered. > > Why do you ask? What problem are you trying to solve? We'd like to know > more! > > > -- > 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
Re: Encryption and decryption - processor or TCPIP
Peter wrote: >I have a general question here. When you don't have crypto processor, So >when a ATTLS traffic is enabled does the encryption and decryption handled >by Started task TCPIP or the general processor? The TCPIP started task is just code and runs on the general processor, so your question doesn't make much sense. AT-TLS is managed by the Policy Agent started task, and it appears that the actual encryption takes place in the TCPIP started task, but that's a conclusion-I've never wondered. Why do you ask? What problem are you trying to solve? We'd like to know more! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Encryption and decryption - processor or TCPIP
Hello I have a general question here. When you don't have crypto processor, So when a ATTLS traffic is enabled does the encryption and decryption handled by Started task TCPIP or the general processor? Regards Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
