Hi,

Which build do you use? Could you explain when this error occurs in your case?

Hello,

Here is the output from VERSION:

DANI:/u/dani: >openssl version
OpenSSL 1.0.2k 26 Jan 2017

/share/doc/openssl/1.0.2k:

Tool: openssl
Version: 1.0.2k
Build Number: 004

The error is issued when I attempt to encrypt a file:

DANI:/u/dani: >openssl enc -aes-256-cfb -salt -pass pass:test -in /u/smpe/GIMZIP/package2.tar -out /u/smpe/GIMZIP/package2.tar.aes

or:

DANI:/u/dani: >openssl enc -des3 -salt -pass pass:test -in /u/smpe/GIMZIP/package2.tar -out /u/smpe/GIMZIP/package2.tar.des3

Hi,

Thanks for report. We will work on this problem.

*** Rocket internal tracking reference: USSP-843 ***

Ok, so currently there is no way to encrypt a file using this version of OPENSSL on z/OS ?

Note, this theory has not been tested yet on our end using openssl, however, we recently fixed a bug in our python port which occurred only when the default value for the random number generator seed was something other than the default. I suppose there is some chance this may be of help to you given the error message.

We are not able to reproduce this problem on our system. I use this keys without errors on our machines. So we need time to investigate this issue.
Which z/OS version do you use? Do you use bash (version) or sh?

Z/OS 1.10
I do this from OMVS

I think it’s likely that openSSL is using /dev/random to seed the PRNG, so it might be that:

• You are not currently authorized to use /dev/random. Here’s a link to the documentation for z/OS2.2; I don’t have a similar link for z/OS 1.10.
• z/OS 1.10 may not support /dev/random.

– Jerry

Is there as way to force OPENSSL not use /dev/random to seed the PRNG ?

Were you paying support, we might be able to help. However we need to prioritize our time on customers paying maintenance.

I am only going to become paying client if I can evaluate the product on
our z/OS system.
Currently the product does not work for us so no reason to become paying
client.

Thanks…Dani

I’m not sure we could even offer maintenance at the 1.10 level. From IBM Support Software lifecycle z/OS 1.10.x:

Lifecycle dates, announcement letters and other information
GA26-Sep-2008, 208-186 EOM 19-Oct-2009 EOS 30-Sep-2011, 910-169 Lifecycle policy Standard
Note: 5656-A01 Life Cycle Extension is Withdrawn from Marketing 8-26-13

We don’t internally have any systems running at the 1.10 level, so we would have no way of testing fixes.

We are going to upgrade soon to z/Os 2.2 and I’m sure you will support the
product at that level.
I am not asking for a fix but rather asking if there is away around using
/etc/random.

Near as I can tell, there is no way to avoid using /dev/random. OpenSSL has to be very careful WRT to generation of random seeds, and this is the most reliable approach on Unix systems, so the standard code provides no alternative. There are hacks available for other operating systems, but they need to be compiled in when the code is built, and are not necessarily secure.

Please keep in mind that z/OS 1.10 is ancient and unsupported by IBM. Why should Rocket support openssl running in z/OS 1.10?

Here z/OS 2.2, I’m unable to get an error using your openssl command. I have the same openssl you have.

Hi Jerry,
I did a test, stopping ICSF. openssl still worked, i.e. neither /dev/random nor /dev/urandom are used when running
openssl enc -aes-256-cfb -salt -pass pass:test -in /u/smpe/GIMZIP/package2.tar -out …