Given that the key check values matched, I think you are correct that it is an encoding issue. I would be curious to see whether binary data can be encrypted on z/OS and decrypted correctly on distributed.
If that fails, I suspect that the transfer of the encrypted data from one to the other is the problem.
Original Message:
Sent: Thu February 29, 2024 12:40 AM
From: Eugéne van Wyk
Subject: AES/CBC/PKCS5Padding
Thank you for the guidance,
We did test with conversion of the input and output to/from EBCIDIC to ASCII with none of the combinations matching. But working towards adapting and making use of the REXX from UNIX where the translated data would be in the full process which will then eliminate any encoding mismatches. Hopefully it is just an encoding issue and not an issue with the key itself residing in CKDS or how it's used in the REXX.
------------------------------
Eugéne van Wyk
Original Message:
Sent: Wed February 28, 2024 09:41 AM
From: Eric Rossman
Subject: AES/CBC/PKCS5Padding
Someone just pointed out that if you encrypt printable text on z/OS, it would be EBCDIC, so it would still be EBCDIC (not ASCII) when decrypted on a distributed platform, which could cause an apparent mismatch.
------------------------------
Eric Rossman
Original Message:
Sent: Wed February 28, 2024 09:13 AM
From: Eugéne van Wyk
Subject: AES/CBC/PKCS5Padding
Tested with both hex zeros and a null on the z/OS environment.
On distributed environment it just makes use of the key and IV=0.
The data and key are provided by a third party.
On distributed the key is used with IV=0 and can successfully decrypt the provided data and encrypt the clear text provided data successfully.
On z/OS we now have the script working and doing tests before running on the full data and already there's a conflict in the resulting encrypt/decrypt data.
Still busy with the modification to get the full data file into the REXX script to test that as well.
------------------------------
Eugéne van Wyk
Original Message:
Sent: Wed February 28, 2024 08:25 AM
From: Eric Rossman
Subject: AES/CBC/PKCS5Padding
If the key check value matches but the decrypted data does not, that tells me that it's most likely the initialization vector that is causing the difference. Can you confirm what API you are using on the distributed environment and that it is using the same IV?
------------------------------
Eric Rossman
Original Message:
Sent: Wed February 28, 2024 08:09 AM
From: Eugéne van Wyk
Subject: AES/CBC/PKCS5Padding
Hi,
Thank you the script is working, but...
On z/OS the encrypt and decrypt works with confirmation that input/output is the same after the process.
For testing purposes I'm running the same encrypt/decrypt on a distributed machine.
The problem comes in that the correlating encrypted text from the REXX scripts when decrypted by the distributed environment does not correlate at all.
The same with the provided sample data.
Currently I'm specifying the key details as as follows:
aes_key_label = left('MY.CLEAR.KEY.V000001',64);
rule_array_count = '00000003'X;
rule_array = 'AES PKCS-PADKEYIDENT';
key_identifier_length = '00000040'X;
init_vector_length = '00000010'X;
init_vector = '00000000000000000000000000000000'X;
I've compared the Key check value in both environments and it matches.
Any idea where I'm going wrong or need to look further?
Regards,
Eugéne
------------------------------
Eugéne van Wyk
Original Message:
Sent: Tue February 27, 2024 11:25 AM
From: Eric Rossman
Subject: AES/CBC/PKCS5Padding
You mention CBC (AES/CBC/PKCS5Padding). The PKCS-PAD rule does PKCS#5 padding for CBC mode.
Here's a REXX example call for CSNBSYE doing AES/CBC/PKCS5Padding.
/*********************************************************************/
/* Setup for SYE call */
/*********************************************************************/
return_code = 'FFFFFFFF'X;
reason_code = 'FFFFFFFF'X;
exit_data_length = '00000000'X;
exit_data = '';
rule_array_count = '00000002'X;
rule_array = 'AES PKCS-PAD';
key_identifier_length = '00000010'X;
key_identifier = '0123456789ABCDEF0123456789ABCDEF'X;
key_parms_length = '00000000'X;
key_parms = '';
block_size = '00000010'X;
init_vector_length = '00000010'X;
init_vector = '0123456789ABCDEF0123456789ABCDEF'X;
chain_data_length = '00000020'X;
chain_data = '00000000000000000000000000000000'X||,
'00000000000000000000000000000000'X;
clear_text_length = '00000011'X;
clear_text = 'Sample clear text';
cipher_text_length = '00000020'X;
cipher_text = COPIES('00'X,32);
optional_data_length = '00000000'X;
optional_data = '';
/*********************************************************************/
/* Make SYE call */
/*********************************************************************/
ADDRESS LINKPGM 'CSNBSYE' ,
'return_code' 'reason_code' ,
'exit_data_length' 'exit_data' ,
'rule_array_count' 'rule_array' ,
'key_identifier_length' 'key_identifier' ,
'key_parms_length' 'key_parms' ,
'block_size' ,
'init_vector_length' 'init_vector' ,
'chain_data_length' 'chain_data' ,
'clear_text_length' 'clear_text' ,
'cipher_text_length' 'cipher_text' ,
'optional_data_length' 'optional_data' ;
------------------------------
Eric Rossman
Original Message:
Sent: Tue February 27, 2024 03:35 AM
From: Eugéne van Wyk
Subject: AES/CBC/PKCS5Padding
Hi,
Has anyone implemented a ICSF Callable Services use for AES/CBC/PKCS5Padding?
I've tried adapting a sample found for GCM but it seems I'm struggling to setup the correct combination of rule_array and various length values for the call to CSNBSYE/CSNBSYD.
Any guidance would be much appreciated.
Regards,
Eugéne
------------------------------
Eugéne van Wyk
------------------------------