IBM Crypto Education Community

Hi all,

I was tasked to do AES 256-bit encryption using clear-text key via COBOL call to ICSF APIs, so I figured that CSNBSYE and CSNBSYD would be the correct APIs to used. My input records are fixed 43-byte long (not multiples of 16, the ideal block size for AES) so I figured I would use the chaining vectors to "link" the calls together.

According to the documentation, I would either:

1. use AES / CFB / INITIAL for each call, and move the first 16 bytes of OCV to the ICV for each call subsequent to the first; or

2. use AES / CFB / INITIAL for first call, and AES / CFB / CONTINUE for subsequent calls, and let the algorithm handle the chaining vector.

But either way, I'm not getting the correct result. For case 1, I would get garbage in the first 15-16 bytes in the decrypted records; for case 2, I would get RC=8 and Reason=2036. I spent quite some time on debugging with no clues until I ran into the following:

http://www-01.ibm.com/support/docview.wss?uid=isg1OA42606

I'm not sure if my installation has the version of ICSF including the above fix, and I would like to know how to find out.

My ICSF panel says HCR77A0 (dated September 2012), does it mean that it doesn't have the fix which was released mid-2013?

Thanks so much in advance!

Best reagards,

Alan

With the SYE verb, you should not need to make multiple calls to encrypt 43 bytes.  Just specify your algorithm (AES), your chaining mode (probably CBC), keyword ONLY to indicate you're giving it all the input data at once, a clear_text_length of 43, and a pointer to your buffer.  The verb will encrypt the whole thing in CBC mode in one call and return the output to you.

HI Todd,

Thanks for your reply! However, my 43-byte length example was only arbitrary; we are dealing with variable length records, and they are not necessarily in multiples of 8n bytes. Of course I could re-align them into multiples and apply paddings, but I thought CFB mode is used for chaining calls when you don't have multiples.

I am able to do similar in Java with cipher.init(), cipher.update() and cipher.doFinal() with varying input lengths each call, so I would think the z/OS implementation should be able to do something similar.

Regards,

Al

But isn't the same thing true for CFB mode?  The manual says "Input text may be any length", and I don't see anything saying you have to pass input data one block at a time.  I'd think you could just specify your total length in one call and ICSF and the crypto card would take care of the rest.  Perhaps someone closer to implementation/testing of the verbs can verify this.

Of course the problem you asked about is still a valid question - I'll see if I can get someone from the ICSF team involved to try and figure out why you can't get the chaining to work.

Hi Alan,

You can use CFB mode for any text length but only the FINAL block supports a partial block. The CSNBSYE documentation under "clear_text_length" states "For the processing rules that support partial blocks (or segments for CFB-LCFB), it is recommended that the final block (or segment) be the only one that is partial. Having a partial block in the middle is not supported operation as defined by the standards documents and may not be portable to other encryption systems."

Your application would need to calculate the pad length (data length modulo block size) and pad the data prior to calling ICSF for encryption. And the pad characters would appear in the decrypted output.

Dear Eysha,

Thank you some much for the pointer! Been banging my head against the wall past couple of days... XD

RTFM is the Golden Rule~!

Regards,

Al

LOL! No worries! :-D

If you have other questions, just let us know.