Defects in PCC instruction

[[e-mail] [hercules-390]]

Hi All


I just ran across various defects in the Perform Cryptographic Computation (PCC) instruction. After fixing them for the TK4- environment I refitted the patch to match the current spinhawk (Hercules 3.12) and hyperion levels. It can be downloaded at


https://polybox.ethz.ch/index.php/s/wjPdL0wXAmpG407 https://polybox.ethz.ch/index.php/s/wjPdL0wXAmpG407


As I went through the crypto folder I found a small patch applied to sha256.c in hyperion but not in spinhawk. As this one made sense to me (although not being involved in the PCC malfunction) I factored it into the spinhawk version of my patch.


Problem description:


CMACs generated using FCs 1-3, 9-11, 18-20 and 26-28 are always wrong. While FCs 1-3 and 9-11 consistently generate the same wrong CMACs from the same input, FCs 18-20 and 26-28 generate arbitrarily wrong CMACs from the same input. Either way: None of those functions ever create a correct CMAC.


The root cause is a logic error in the implementation of the last block subkey generation algorithm, and, in addition, for FCs 18-20 and 26-28, a parameter block length mismatch.


I fixed both, the faulty algorithm and the parameter block length mismatch, and verified that the CMACs found in the examples in Appendix D of the NIST-CSD Special Publication 800-38B are computed correctly. Additionally I created a lot of arbitrary CMACs using OpenSSL and verified that the results are matching those computed by PCC. Given that everything does match perfectly now, I'm confident that the patch solves the problem.


Cheers
JÃŒrgen

[Ivan Warren [e-mail] [hercules-390]]

Post by ***@id.ethz.ch [hercules-390]
Hi All
I just ran across various defects in the Perform Cryptographic
Computation (PCC) instruction. After fixing them for the TK4-
environment I refitted the patch to match the current spinhawk
(Hercules 3.12) and hyperion levels. It can be downloaded at
https://polybox.ethz.ch/index.php/s/wjPdL0wXAmpG407
As I went through the crypto folder I found a small patch applied to
sha256.c in hyperion but not in spinhawk. As this one made sense to me
(although not being involved in the PCC malfunction) I factored it
into the spinhawk version of my patch.
CMACs generated using FCs 1-3, 9-11, 18-20 and 26-28 are *always*
wrong. While FCs 1-3 and 9-11 consistently generate the same wrong
CMACs from the same input, FCs 18-20 and 26-28 generate arbitrarily
wrong CMACs from the same input. Either way: None of those functions
ever create a correct CMAC.
The root cause is a logic error in the implementation of the last
block subkey generation algorithm, and, in addition, for FCs 18-20 and
26-28, a parameter block length mismatch.
I fixed both, the faulty algorithm and the parameter block length
mismatch, and verified that the CMACs found in the examples in
Appendix D of the NIST-CSD Special Publication 800-38B are computed
correctly. Additionally I created a lot of arbitrary CMACs
using OpenSSL and verified that the results are matching those
computed by PCC. Given that everything does match perfectly now, I'm
confident that the patch solves the problem.
Cheers
JÃŒrgen

JÃŒrgen,

Great work ! my crypto knowledge is not deep enough to actually
understand the ins and outs of your findings and patches - but I would
recommend they be implemented ASAP based on the description. Some others
who may have worked on the crypto functions may be more able to validate
this. However, I would like to thank you on the work done.

--Ivan


[Non-text portions of this message have been removed]

[[e-mail] [hercules-390]]

change committed! cheers
e

[[e-mail] [hercules-390]]

Thanks, Enrico


Cheers
JÃŒrgen

[[e-mail] [hercules-390]]

I just sent a bug report to OpenSSL yesterday and perhaps this is the problem. I am running Hercules 3.11, Linux tri26 3.0.13-0.27-default #1 SMP Wed Feb 15 13:33:49 UTC 2012 (d73692b) s390x s390x s390x GNU/Linux. When I run the validation tests on OpenSSL 1.0.2g, I eventually get


Testing cipher AES-128-XTS(encrypt/decrypt)
Key
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
IV
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Ciphertext
0000 91 7c f6 9e bd 68 b2 ec 9b 9f e9 a3 ea dd a6 92
0010 cd 43 d2 f5 95 98 ed 85 8c 02 c2 65 2f bf 92 2e
Ciphertext mismatch
Got
0000 91 7c f6 9e bd 68 b2 ec 9b 9f e9 a3 ea dd a6 92
0010 89 36 96 08 51 3b fa 4f 4e 41 fd cf 81 18 01 b4
Expected
0000 91 7c f6 9e bd 68 b2 ec 9b 9f e9 a3 ea dd a6 92
0010 cd 43 d2 f5 95 98 ed 85 8c 02 c2 65 2f bf 92 2e
make[1]: *** [test_evp] Error 9
make[1]: Leaving directory `/usr4/tmp/openssl-1.0.2g/test'
make: *** [tests] Error 2


Is this caused by the bug that you found?
Paul

[[e-mail] [hercules-390]]

Hi Paul


thanks for bringing this up.

Post by ***@trifox.com [hercules-390]
Is this caused by the bug that you found?

No, It is yet another bug! It is hiding itself in both, the PCC and the KM instructions when function codes are 50, 52, 58 or 60. This is a totally different area of the code, than where I recently detected the CMAC last block computation bug.


With a bit of tweaking I can obtain exactly your results, while I'm not able to get the expected result.


I hope finding time over the weekend to investigate this...


Cheers
JÃŒrgen

---In hercules-***@yahoogroups.com, <***@...> wrote :


I just sent a bug report to OpenSSL yesterday and perhaps this is the problem. I am running Hercules 3.11, Linux tri26 3.0.13-0.27-default #1 SMP Wed Feb 15 13:33:49 UTC 2012 (d73692b) s390x s390x s390x GNU/Linux. When I run the validation tests on OpenSSL 1.0.2g, I eventually get


Testing cipher AES-128-XTS(encrypt/decrypt)
Key
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
IV
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Ciphertext
0000 91 7c f6 9e bd 68 b2 ec 9b 9f e9 a3 ea dd a6 92
0010 cd 43 d2 f5 95 98 ed 85 8c 02 c2 65 2f bf 92 2e
Ciphertext mismatch
Got
0000 91 7c f6 9e bd 68 b2 ec 9b 9f e9 a3 ea dd a6 92
0010 89 36 96 08 51 3b fa 4f 4e 41 fd cf 81 18 01 b4
Expected
0000 91 7c f6 9e bd 68 b2 ec 9b 9f e9 a3 ea dd a6 92
0010 cd 43 d2 f5 95 98 ed 85 8c 02 c2 65 2f bf 92 2e
make[1]: *** [test_evp] Error 9
make[1]: Leaving directory `/usr4/tmp/openssl-1.0.2g/test'
make: *** [tests] Error 2


Is this caused by the bug that you found?
Paul

[[e-mail] [hercules-390]]

Hi Paul




Just a quick status: The
GF(2128) multiplication algorithm implemented in Hercules' dyncrypt module delivers incorrect results. I'm not yet sure whether the algorithm is erroneous or whether it is used incorrectly. Currently I think the latter is the case, but I can't proof this for now. Anyway: The OpenSSL test case you showed below just encrypts a few blocks in sequence (as opposed to encrypting arbitrary blocks, which would be more typical for XTS mode, given it is in practice primarily used for disk encryption). For sequential encryption one can replace the Galois multiplication with a much easier LFSR scheme which yields the same result, but doesn't allow accessing arbitrary blocks. Just for testing I did this and, who wonders, I then get exactly the results OpenSSL expects in your test case. I then also (temporarily of course) replaced the direct access stuff in PCC with an LFSR loop, which should work up to the 264th block, but of course at a horrible performance.


Of course I don't want to distribute this test version of dyncrypt. I'm short on time during the coming week but I'll try to find out why this darn Galois multiplication isn't working correctly as soon as possible... so, stay tuned!


Cheers
JÃŒrgen

---In hercules-***@yahoogroups.com, <***@...> wrote :


Hi Paul


thanks for bringing this up.

Post by ***@trifox.com [hercules-390]
Is this caused by the bug that you found?

No, It is yet another bug! It is hiding itself in both, the PCC and the KM instructions when function codes are 50, 52, 58 or 60. This is a totally different area of the code, than where I recently detected the CMAC last block computation bug.


With a bit of tweaking I can obtain exactly your results, while I'm not able to get the expected result.


I hope finding time over the weekend to investigate this...


Cheers
JÃŒrgen

---In hercules-***@yahoogroups.com, <***@...> wrote :


I just sent a bug report to OpenSSL yesterday and perhaps this is the problem. I am running Hercules 3.11, Linux tri26 3.0.13-0.27-default #1 SMP Wed Feb 15 13:33:49 UTC 2012 (d73692b) s390x s390x s390x GNU/Linux. When I run the validation tests on OpenSSL 1.0.2g, I eventually get


Testing cipher AES-128-XTS(encrypt/decrypt)
Key
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
IV
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Ciphertext
0000 91 7c f6 9e bd 68 b2 ec 9b 9f e9 a3 ea dd a6 92
0010 cd 43 d2 f5 95 98 ed 85 8c 02 c2 65 2f bf 92 2e
Ciphertext mismatch
Got
0000 91 7c f6 9e bd 68 b2 ec 9b 9f e9 a3 ea dd a6 92
0010 89 36 96 08 51 3b fa 4f 4e 41 fd cf 81 18 01 b4
Expected
0000 91 7c f6 9e bd 68 b2 ec 9b 9f e9 a3 ea dd a6 92
0010 cd 43 d2 f5 95 98 ed 85 8c 02 c2 65 2f bf 92 2e
make[1]: *** [test_evp] Error 9
make[1]: Leaving directory `/usr4/tmp/openssl-1.0.2g/test'
make: *** [tests] Error 2


Is this caused by the bug that you found?
Paul

[[e-mail] [hercules-390]]

Hi JÃŒrgen,
Thank you very much for your time on this.
Regards,
Paul

[Truda [e-mail] [hercules-390]]

Hello,

after some digging in I have been able to produce correct results after
changing dyncrypt.so (in the Gaulois Function as indicated by JÃŒrgen) to

#define XMEMCPY memmove

I will do some more testing tonight to see if the error can be
reproduced and corrected consistently over different linux s390 installs
(Debian). This one i compiled on Fedora fc23 s390x:

4.4.6-301.fc23.s390x #1 SMP s390x s390x s390x GNU/Linux

with gcc:

gcc (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2)

Regards,
Gert

Post by ***@trifox.com [hercules-390]
Hi JÃŒrgen,
Thank you very much for your time on this.
Regards,
Paul

[[e-mail] [hercules-390]]

Hi Gert


Thanks for chiming in!


I'd wish the solution was as easy as you are describing below. However, it isn't:
Using memmove instead of memcpy only makes a difference if the source and target memory areas overlap, which they don't in the given case. I do get correct results without touching the #define, by only using the algorithm correctly (I reported this last week). This corresponds to the use of the algorithm in the KM instruction, i.e. sequential encryption/decryption of a series of 16-byte blocks. This is the use case Paul originally reported, so this can considered being fixed. Note that this usage of the algorithm only performs a multiplication by 2 in GF(2128), in which case it works correctly. The flaw I mention below comes to light only if one multiplies by different values than 2. There is a much more important use case in PCC: It computes the XTS tweak value for an arbitrary block of a series, identified by its sequential number between 1 and 2128. This tweak value can then be used as input to KM to directly encrypt/decrypt the block in question, as opposed to having to do the whole series sequentially until it reaches the block in question. This use case is the difficult one, because it has a logic error in the way it is implemented in PCC and it uses the Galois multiplication in an invalid way and the algorithm itself has a flaw I've not yet fully identified. Finally, there is an area I didn't investigate up to now: The GHASH function provided by the KIMD instruction uses the same algorithm. From a distance, it seems to use it correctly. However, if the algorithm has the flaw I'm currently suspecting, then the usage in KIMD might be exposed to it too, as it uses arbitrary multiplicands, i.e. not only 2.
I hope this puts a bit more clarity on the situation, and, particularly, helps avoid wasting your time chasing ghosts (I chased many of them during the past days, though).


Looking at it another way round: Of course I take it as a fact when you report having fixed the problem. But the sad thing here is that you can't deduct the cryptographic operations are working correctly just because you now have an OpenSSL that no longer reports a failing test: It might be that OpenSSL configuration decided not to use the cryptographic instructions at all, or to only use them in certain cases, or you just managed to hit situations where the bugs mentioned above are not triggered.


Should you in fact be able to show that using memmove instead of memcpy yields reproducibly different results, we'd of course need to find out why this is the case. My only assumption for now would be well hidden memory area overlays...


Cheers
JÃŒrgen

---In hercules-***@yahoogroups.com, <***@...> wrote :


Hello,

after some digging in I have been able to produce correct results after changing dyncrypt.so (in the Gaulois Function as indicated by JÃŒrgen) to

#define XMEMCPY memmove

I will do some more testing tonight to see if the error can be reproduced and corrected consistently over different linux s390 installs (Debian). This one i compiled on Fedora fc23 s390x:

4.4.6-301.fc23.s390x #1 SMP s390x s390x s390x GNU/Linux

with gcc:

gcc (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2)

Regards,
Gert

On 11/04/2016 19:31, ***@... mailto:***@... [hercules-390] wrote:

Hi JÃŒrgen,
Thank you very much for your time on this.
Regards,
Paul

[Truda [e-mail] [hercules-390]]

Hello JÃŒrgen,

as usual you are right. I was too quick and can not demonstrate the
causality of the #define change. In fact since I've compiled the latest
version of Hercules I have been unable to reproduce the problem with or
without the #define change.

Thank you for your explanation. It does indeed clarify the situation.

@Paul can you clarify how you got to the ciphertext mismatch result
because now I get correct results all the time.

Thanks for your input.

Regards,
Gert

Post by ***@id.ethz.ch [hercules-390]
Hi Gert
Thanks for chiming in!
I'd wish the solution was as easy as you are describing below.
* Using memmove instead of memcpy only makes a difference if the
source and target memory areas overlap, which they don't in the
given case.
* I do get correct results without touching the #define, by only
using the algorithm correctly (I reported this last week). This
corresponds to the use of the algorithm in the KM instruction,
i.e. sequential encryption/decryption of a series of 16-byte
blocks. This is the use case Paul originally reported, so this can
considered being fixed. Note that this usage of the algorithm
only performs a multiplication by 2 in GF(2^128 ), in which case
it works correctly. The flaw I mention below comes to light only
if one multiplies by different values than 2.
* There is a much more important use case in PCC: It computes the
XTS tweak value for an arbitrary block of a series, identified by
its sequential number between 1 and 2^128 . This tweak value can
then be used as input to KM to directly encrypt/decrypt the block
in question, as opposed to having to do the whole series
sequentially until it reaches the block in question. This use case
is the difficult one, because it has a logic error in the way it
is implemented in PCC *and* it uses the Galois multiplication in
an invalid way *and* the algorithm itself has a flaw I've not yet
fully identified.
* Finally, there is an area I didn't investigate up to now: The
GHASH function provided by the KIMD instruction uses the same
algorithm. From a distance, it seems to use it correctly. However,
if the algorithm has the flaw I'm currently suspecting, then the
usage in KIMD might be exposed to it too, as it uses arbitrary
multiplicands, i.e. not only 2.
I hope this puts a bit more clarity on the situation, and,
particularly, helps avoid wasting your time chasing ghosts (I
chased many of them during the past days, though).
Looking at it another way round: Of course I take it as a fact when
you report having fixed the problem. But the sad thing here is that
you can't deduct the cryptographic operations are working
correctly just because you now have an OpenSSL that no longer reports
a failing test: It might be that OpenSSL configuration decided not to
use the cryptographic instructions at all, or to only use them in
certain cases, or you just managed to hit situations where the bugs
mentioned above are not triggered.
Should you in fact be able to show that using memmove instead of
memcpy yields reproducibly different results, we'd of course need to
find out why this is the case. My only assumption for now would be
well hidden memory area overlays...
Cheers
JÃŒrgen
Hello,
after some digging in I have been able to produce correct results
after changing dyncrypt.so (in the Gaulois Function as indicated by
JÃŒrgen) to
#define XMEMCPY memmove
I will do some more testing tonight to see if the error can be
reproduced and corrected consistently over different linux s390
4.4.6-301.fc23.s390x #1 SMP s390x s390x s390x GNU/Linux
gcc (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2)
Regards,
Gert

Post by ***@trifox.com [hercules-390]
Hi JÃŒrgen,
Thank you very much for your time on this.
Regards,
Paul

[[e-mail] [hercules-390]]

Hi Truda,
I ran the openssl-1.0.2g tests after doing the build:


tar xf openssl-1.0.2.g.tar
cd openssl-1.0.2g
config
make depend
make
make test


I am running SLES 12 on Hercules 3.11.
Regards,
Paul

[[e-mail] [hercules-390]]

Hi Paul, Gert


just letting you know: Problem solved (hopefully).


I'll now do some plausibility checks to be as confident as possible that things on the XTS side do work now as expected. Paul's OpenSSL tests will then hopefully work cleanly too...


Additionally I'll go over the KIMD GHASH function to verify whether this one is working correctly or is broken too. If necessary it will get the same fix applied as KM/PCC now have for XTS.


Given my current time constraints these activities will probably take some additional two or three days. I'll publish a patch once I'm done with this (currently it's some 200 lines of code changed in dyncrypt.c, which I consider a major change, although a big part of it is the precomputed exp_table).


Cheers
JÃŒrgen



---In hercules-***@yahoogroups.com, <***@...> wrote :

Hi Gert


Thanks for chiming in!


I'd wish the solution was as easy as you are describing below. However, it isn't:
Using memmove instead of memcpy only makes a difference if the source and target memory areas overlap, which they don't in the given case. I do get correct results without touching the #define, by only using the algorithm correctly (I reported this last week). This corresponds to the use of the algorithm in the KM instruction, i.e. sequential encryption/decryption of a series of 16-byte blocks. This is the use case Paul originally reported, so this can considered being fixed. Note that this usage of the algorithm only performs a multiplication by 2 in GF(2128), in which case it works correctly. The flaw I mention below comes to light only if one multiplies by different values than 2. There is a much more important use case in PCC: It computes the XTS tweak value for an arbitrary block of a series, identified by its sequential number between 1 and 2128. This tweak value can then be used as input to KM to directly encrypt/decrypt the block in question, as opposed to having to do the whole series sequentially until it reaches the block in question. This use case is the difficult one, because it has a logic error in the way it is implemented in PCC and it uses the Galois multiplication in an invalid way and the algorithm itself has a flaw I've not yet fully identified. Finally, there is an area I didn't investigate up to now: The GHASH function provided by the KIMD instruction uses the same algorithm. From a distance, it seems to use it correctly. However, if the algorithm has the flaw I'm currently suspecting, then the usage in KIMD might be exposed to it too, as it uses arbitrary multiplicands, i.e. not only 2.
I hope this puts a bit more clarity on the situation, and, particularly, helps avoid wasting your time chasing ghosts (I chased many of them during the past days, though).


Looking at it another way round: Of course I take it as a fact when you report having fixed the problem. But the sad thing here is that you can't deduct the cryptographic operations are working correctly just because you now have an OpenSSL that no longer reports a failing test: It might be that OpenSSL configuration decided not to use the cryptographic instructions at all, or to only use them in certain cases, or you just managed to hit situations where the bugs mentioned above are not triggered.


Should you in fact be able to show that using memmove instead of memcpy yields reproducibly different results, we'd of course need to find out why this is the case. My only assumption for now would be well hidden memory area overlays...


Cheers
JÃŒrgen

---In hercules-***@yahoogroups.com, <***@...> wrote :


Hello,

after some digging in I have been able to produce correct results after changing dyncrypt.so (in the Gaulois Function as indicated by JÃŒrgen) to

#define XMEMCPY memmove

I will do some more testing tonight to see if the error can be reproduced and corrected consistently over different linux s390 installs (Debian). This one i compiled on Fedora fc23 s390x:

4.4.6-301.fc23.s390x #1 SMP s390x s390x s390x GNU/Linux

with gcc:

gcc (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2)

Regards,
Gert

On 11/04/2016 19:31, ***@... mailto:***@... [hercules-390] wrote:

Hi JÃŒrgen,
Thank you very much for your time on this.
Regards,
Paul

[[e-mail] [hercules-390]]

Hi Paul, Gert


Well, the below was once again too optimistic, it didn't stand my plausibility checks .


This forced me to dive in even deeper. In the meantime I know the "IEEE Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices (1619-2007)" by heart, in fact I can sing to its lyrics. This stuff really has the potential to drive me insane...


Most annoyingly, it turned out that one of my very first tests after Paul reported the problem targeted the correct algorithm, but I made a mistake implementing it, which led me to completely rule it out from then on. So it was necessary to go through the full theory, only to realize that I already was on the correct path in the very beginning . At least I can now say I'm sure doing it correctly as opposed to only assuming it in the first place .


Now I'll go back to dyncrypt, implement my findings and go again through my tests... this will still need a few days.


Cheers
JÃŒrgen

---In hercules-***@yahoogroups.com, <***@...> wrote :


Hi Paul, Gert


just letting you know: Problem solved (hopefully).


I'll now do some plausibility checks to be as confident as possible that things on the XTS side do work now as expected. Paul's OpenSSL tests will then hopefully work cleanly too...


Additionally I'll go over the KIMD GHASH function to verify whether this one is working correctly or is broken too. If necessary it will get the same fix applied as KM/PCC now have for XTS.


Given my current time constraints these activities will probably take some additional two or three days. I'll publish a patch once I'm done with this (currently it's some 200 lines of code changed in dyncrypt.c, which I consider a major change, although a big part of it is the precomputed exp_table).


Cheers
JÃŒrgen

[Gert Caers [e-mail] [hercules-390]]

blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px #715FFA solid !important; padding-left:1ex !important; background-color:white !important; } Hi,
Indeed a tough one it seems. Very impressive. From your part.
Furthermore I can report that:
Make test for openssl crashes hercules 3.07.
3.11 and 3.12 produce the error from Paul (ciphertext mismatch).
4.00 hyperion does not produce an error at all!This sounds very strange. Maybe I am doing something wrong?
Regards,Gert


Verzonden van Yahoo Mail voor iPhone


Op donderdag, april 21, 2016, 10:40 PM, ***@id.ethz.ch [hercules-390] <hercules-***@yahoogroups.com> schreef:

 


Hi Paul, Gert




Well, the below was once again too optimistic, it didn't stand my plausibility checks .




This forced me to dive in even deeper. In the meantime I know the "IEEE Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices (1619-2007)" by heart, in fact I can sing to its lyrics. This stuff really has the potential to drive me insane... 




Most annoyingly, it turned out that one of my very first tests after Paul reported the problem targeted the correct algorithm, but I made a mistake implementing it, which led me to completely rule it out from then on. So it was necessary to go through the full theory, only to realize that I already was on the correct path in the very beginning . At least I can now say I'm sure doing it correctly as opposed to only assuming it in the first place .




Now I'll go back to dyncrypt, implement my findings and go again through my tests... this will still need a few days.




Cheers

JÃŒrgen

---In hercules-***@yahoogroups.com, <***@...> wrote :



Hi Paul, Gert




just letting you know: Problem solved  (hopefully).




I'll now do some plausibility checks to be as confident as possible that things on the XTS side do work now as expected. Paul's OpenSSL tests will then hopefully work cleanly too...




Additionally I'll go over the KIMD GHASH function to verify whether this one is working correctly or is broken too. If necessary it will get the same fix applied as KM/PCC now have for XTS.




Given my current time constraints these activities will probably take some additional two or three days. I'll publish a patch once I'm done with this (currently it's some 200 lines of code changed in dyncrypt.c, which I consider a major change, although a big part of it is the precomputed exp_table).




Cheers

JÃŒrgen

[[e-mail] [hercules-390]]

Hi Gert


That's an interesting observation.


I currently don't know, under which conditions (if at all) OpenSSL uses the cryptographic instructions, as I never looked into this. If it behaves as a good citizen it issues the query function provided by each of the instructions during initialization and from then on uses the cryptographic instructions for the functions found to be available and its own code for those functions not being available. Clearly, one can assume that "its own code" will work correctly, or, at least, deliver the expected results when running the test suites. So, one reason for the behavior you are observing can be that OpenSSL doesn't use the defective instructions during your test run on Hyperion.


On the Spinhawk (Hercules 3.x) side of things the features activated in featxxx.h (xxx being the archmode) decide, which function codes will be reported available by the query functions, once dyncrypt is loaded.


On the Hyperion side in addition to the feature activation in featxxx.h there is the dynamic situation given by the archlvl command, with the initial defaults determined in archlvl.c. The dyncrypt module uses both: At compile time it honors the definitions given by featxxx.h and at run time it cross checks the settings given by archlvl.


So, it would be interesting to see the output of the following two commands when the system you are using for your tests is running on Hyperion:


archlvl (without arguments)
archlvl query all


In addition, it would be interesting to see the featxxx.h used for building the architecture shown by the first archlvl command.


Maybe we can draw some conclusions from this. On the other hand, the results from Paul's and your testings with my upcoming patch will probably bring more clarity. And, yes, if this still brings not the level of insight needed to understand what's going on, a close look into the OpenSSL source would also be indicated.



Cheers
JÃŒrgen

---In hercules-***@yahoogroups.com, <***@...> wrote :


Hi,

Indeed a tough one it seems. Very impressive. From your part.


Furthermore I can report that:


Make test for openssl crashes hercules 3.07.


3.11 and 3.12 produce the error from Paul (ciphertext mismatch).


4.00 hyperion does not produce an error at all!This sounds very strange. Maybe I am doing something wrong?


Regards,
Gert


Verzonden van Yahoo Mail voor iPhone https://yho.com/footer0

Op donderdag, april 21, 2016, 10:40 PM, ***@... [hercules-390] <hercules-***@yahoogroups.com> schreef:

Hi Paul, Gert


Well, the below was once again too optimistic, it didn't stand my plausibility checks .


This forced me to dive in even deeper. In the meantime I know the "IEEE Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices (1619-2007)" by heart, in fact I can sing to its lyrics. This stuff really has the potential to drive me insane...


Most annoyingly, it turned out that one of my very first tests after Paul reported the problem targeted the correct algorithm, but I made a mistake implementing it, which led me to completely rule it out from then on. So it was necessary to go through the full theory, only to realize that I already was on the correct path in the very beginning . At least I can now say I'm sure doing it correctly as opposed to only assuming it in the first place .


Now I'll go back to dyncrypt, implement my findings and go again through my tests... this will still need a few days.


Cheers
JÃŒrgen

---In hercules-***@yahoogroups.com, <***@...> wrote :


Hi Paul, Gert


just letting you know: Problem solved (hopefully).


I'll now do some plausibility checks to be as confident as possible that things on the XTS side do work now as expected. Paul's OpenSSL tests will then hopefully work cleanly too...


Additionally I'll go over the KIMD GHASH function to verify whether this one is working correctly or is broken too. If necessary it will get the same fix applied as KM/PCC now have for XTS.


Given my current time constraints these activities will probably take some additional two or three days. I'll publish a patch once I'm done with this (currently it's some 200 lines of code changed in dyncrypt.c, which I consider a major change, although a big part of it is the precomputed exp_table).


Cheers
JÃŒrgen

[Truda [e-mail] [hercules-390]]

Hello,

as I said previously I am not sure of the relevance of my tests as I
just played around a bit without logically building a test case. However
these are the settings of the commands as requested.

Maybe you just tell me what to test from scratch with which settings and
which hercules versions so the conclusions are correct.

Post by ***@id.ethz.ch [hercules-390]

Archlvl

HHC01603I archlvl
HHC02203I archmode : z/Arch

Post by ***@id.ethz.ch [hercules-390]

archlvl query all

HHC00890I Facility(HFP_MULT_ADD_SUB )
Enabled +
HHC00890I Facility(EXTENDED_IMMED ) Enabled
HHC00890I Facility(TRAN_FAC3 ) Enabled
HHC00890I Facility(HFP_UNNORM_EXT ) Enabled
HHC00890I Facility(ETF2_ENHANCEMENT ) Enabled
HHC00890I Facility(STORE_CLOCK_FAST ) Enabled
HHC00890I Facility(PARSING_ENHANCE ) Enabled
HHC00890I Facility(MVCOS ) Enabled
HHC00890I Facility(TOD_CLOCK_STEER ) Enabled
HHC00890I Facility(ETF3_ENHANCEMENT ) Enabled
HHC00890I Facility(EXTRACT_CPU_TIME ) Enabled
HHC00890I Facility(CSSF ) Enabled
HHC00890I Facility(CSSF2 ) Enabled
HHC00890I Facility(GEN_INST_EXTN ) Enabled
HHC00890I Facility(EXECUTE_EXTN ) Enabled
HHC00890I Facility(ENH_MONITOR ) Disabled
HHC00890I Facility(LOAD_PROG_PARAM ) Disabled
HHC00890I Facility(FPS_ENHANCEMENT ) Enabled
HHC00890I Facility(DECIMAL_FLOAT ) Enabled
HHC00890I Facility(DFP_HPERF ) Enabled
HHC00890I Facility(FAST_BCR_SERIAL ) Disabled
HHC00890I Facility(CMPSC_ENH ) Disabled
HHC00890I Facility(RES_REF_BITS_MUL ) Disabled
HHC00890I Facility(ACC_EX_FS_INDIC ) Disabled
HHC00890I Facility(MSA_EXTENSION_3 ) Disabled
HHC00890I Facility(MSA_EXTENSION_4 ) Disabled
HHC00890I Facility(MOVE_INVERSE ) Enabled
HHC00890I Facility(MSA_EXTENSION_1 ) Disabled
HHC00890I Facility(MSA_EXTENSION_2 ) Disabled
HHC00890I Facility(PROBSTATE_DIAGF08 ) Disabled
HHC00890I Facility(SIGP_SETARCH_S370 ) Disabled
HHC00890I Facility(HOST_RESOURCE_ACCESS) Disabled
HHC00890I Facility(QEBSM ) Disabled
HHC00890I Facility(QDIO_THININT ) Disabled
HHC00890I Facility(QDIO_TDD ) Disabled
HHC00890I Facility(SVS ) Disabled
HHC00890I Facility(LOGICAL_PARTITION ) Enabled
HHC00890I Facility(VIRTUAL_MACHINE ) Disabled
HHC00890I Facility(QDIO_ASSIST ) Disabled
HHC00890I Facility(INTERVAL_TIMER ) Enabled
HHC00890I Facility(DETECT_PGMINTLOOP ) Enabled

Post by ***@id.ethz.ch [hercules-390]
Hi Gert
That's an interesting observation.
I currently don't know, under which conditions (if at all) OpenSSL
uses the cryptographic instructions, as I never looked into this. If
it behaves as a good citizen it issues the query function provided by
each of the instructions during initialization and from then on uses
the cryptographic instructions for the functions found to be available
and its own code for those functions not being available. Clearly,
one can assume that "its own code" will work correctly, or, at least,
deliver the expected results when running the test suites. So, one
reason for the behavior you are observing can be that OpenSSL doesn't
use the defective instructions during your test run on Hyperion.
On the Spinhawk (Hercules 3.x) side of things the features activated
in featxxx.h (xxx being the archmode) decide, which function codes
will be reported available by the query functions, once dyncrypt is
loaded.
On the Hyperion side in addition to the feature activation in
featxxx.h there is the dynamic situation given by the archlvl command,
with the initial defaults determined in archlvl.c. The dyncrypt module
uses both: At compile time it honors the definitions given by
featxxx.h and at run time it cross checks the settings given by archlvl.
So, it would be interesting to see the output of the following two
commands when the system you are using for your tests is running on
archlvl (without arguments)
archlvl query all
In addition, it would be interesting to see the featxxx.h used for
building the architecture shown by the first archlvl command.
Maybe we can draw some conclusions from this. On the other hand, the
results from Paul's and your testings with my upcoming patch will
probably bring more clarity. And, yes, if this still brings not the
level of insight needed to understand what's going on, a close look
into the OpenSSL source would also be indicated.
Cheers
JÃŒrgen
Hi,
Indeed a tough one it seems. Very impressive. From your part.
Make test for openssl crashes hercules 3.07.
3.11 and 3.12 produce the error from Paul (ciphertext mismatch).
4.00 hyperion does not produce an error at all!This sounds very
strange. Maybe I am doing something wrong?
Regards,
Gert
Verzonden van Yahoo Mail voor iPhone <https://yho.com/footer0>
Hi Paul, Gert
Well, the below was once again too optimistic, it didn't stand
my plausibility checks .
This forced me to dive in even deeper. In the meantime I know
the "IEEE Standard for Cryptographic Protection of Data on
Block-Oriented Storage Devices (1619-2007)" by heart, in fact
I can sing to its lyrics. This stuff really has the potential
to drive me insane...
Most annoyingly, it turned out that one of my very first tests
after Paul reported the problem targeted the correct
algorithm, but I made a mistake implementing it, which led me
to completely rule it out from then on. So it was necessary to
go through the full theory, only to realize that I already was
on the correct path in the very beginning . At least I can
now say I'm sure doing it correctly as opposed to only
assuming it in the first place .
Now I'll go back to dyncrypt, implement my findings and go
again through my tests... this will still need a few days.
Cheers
JÃŒrgen
Hi Paul, Gert
just letting you know: Problem solved (hopefully).
I'll now do some plausibility checks to be as confident as
possible that things on the XTS side do work now as expected.
Paul's OpenSSL tests will then hopefully work cleanly too...
Additionally I'll go over the KIMD GHASH function to verify
whether this one is working correctly or is broken too. If
necessary it will get the same fix applied as KM/PCC now have
for XTS.
Given my current time constraints these activities will
probably take some additional two or three days. I'll publish
a patch once I'm done with this (currently it's some 200 lines
of code changed in dyncrypt.c, which I consider a major
change, although a big part of it is the precomputed exp_table).
Cheers
JÃŒrgen

[[e-mail] [hercules-390]]

Hi Gert


thanks for your reply! At the current stage I think it fully suffices to do exactly what you did: Run the standard tests that come with OpenSSL, i.e. it isn't yet necessary to build a dedicated test case (which doesn't mean that this might not become necessary when digging deeper).


However, the output of your archlvl commands below already gives a nice indication on the behavior of OpenSSL: One sees that the cryptographic instructions are disabled: They hide behind facilities MSA_EXTENSION_n (n being 1 to 4) and MSG_SECURITY. That means, in your Hyperion configuration OpenSSL has to use "its own code" instead of the instructions, which explains why you don't see any errors.


If you like, you could now investigate why the cryptographic instructions are disabled on your system. This would require you to verify that the following #defines are in your feat900.h:


#define FEATURE_MESSAGE_SECURITY_ASSIST
#define FEATURE_MESSAGE_SECURITY_ASSIST_EXTENSION_1
#define FEATURE_MESSAGE_SECURITY_ASSIST_EXTENSION_2
#define FEATURE_MESSAGE_SECURITY_ASSIST_EXTENSION_3
#define FEATURE_MESSAGE_SECURITY_ASSIST_EXTENSION_4


If they are not in feat900.h, put them in (double check they are not sitting inside some #ifdef sections that prevent them from getting executed) and rebuild Hercules.


Then ensure dyncrypt is loaded (issue an lsmod command to see all loaded modules), and, of course, ensure the above mentioned facilities are reported being enabled by archlvl query all. Once these conditions are met, I'd bet the OpenSSL tests will report the same errors you saw on Hercules 3.11/3.12 .

Cheers
JÃŒrgen

---In hercules-***@yahoogroups.com, <***@...> wrote :


Hello,

as I said previously I am not sure of the relevance of my tests as I just played around a bit without logically building a test case. However these are the settings of the commands as requested.

Maybe you just tell me what to test from scratch with which settings and which hercules versions so the conclusions are correct.

Archlvl

HHC01603I archlvl
HHC02203I archmode : z/Arch

archlvl query all

HHC00890I Facility(HFP_MULT_ADD_SUB ) Enabled +
HHC00890I Facility(EXTENDED_IMMED ) Enabled
HHC00890I Facility(TRAN_FAC3 ) Enabled
HHC00890I Facility(HFP_UNNORM_EXT ) Enabled
HHC00890I Facility(ETF2_ENHANCEMENT ) Enabled
HHC00890I Facility(STORE_CLOCK_FAST ) Enabled
HHC00890I Facility(PARSING_ENHANCE ) Enabled
HHC00890I Facility(MVCOS ) Enabled
HHC00890I Facility(TOD_CLOCK_STEER ) Enabled
HHC00890I Facility(ETF3_ENHANCEMENT ) Enabled
HHC00890I Facility(EXTRACT_CPU_TIME ) Enabled
HHC00890I Facility(CSSF ) Enabled
HHC00890I Facility(CSSF2 ) Enabled
HHC00890I Facility(GEN_INST_EXTN ) Enabled
HHC00890I Facility(EXECUTE_EXTN ) Enabled
HHC00890I Facility(ENH_MONITOR ) Disabled
HHC00890I Facility(LOAD_PROG_PARAM ) Disabled
HHC00890I Facility(FPS_ENHANCEMENT ) Enabled
HHC00890I Facility(DECIMAL_FLOAT ) Enabled
HHC00890I Facility(DFP_HPERF ) Enabled
HHC00890I Facility(FAST_BCR_SERIAL ) Disabled
HHC00890I Facility(CMPSC_ENH ) Disabled
HHC00890I Facility(RES_REF_BITS_MUL ) Disabled
HHC00890I Facility(ACC_EX_FS_INDIC ) Disabled
HHC00890I Facility(MSA_EXTENSION_3 ) Disabled
HHC00890I Facility(MSA_EXTENSION_4 ) Disabled
HHC00890I Facility(MOVE_INVERSE ) Enabled
HHC00890I Facility(MSA_EXTENSION_1 ) Disabled
HHC00890I Facility(MSA_EXTENSION_2 ) Disabled
HHC00890I Facility(PROBSTATE_DIAGF08 ) Disabled
HHC00890I Facility(SIGP_SETARCH_S370 ) Disabled
HHC00890I Facility(HOST_RESOURCE_ACCESS) Disabled
HHC00890I Facility(QEBSM ) Disabled
HHC00890I Facility(QDIO_THININT ) Disabled
HHC00890I Facility(QDIO_TDD ) Disabled
HHC00890I Facility(SVS ) Disabled
HHC00890I Facility(LOGICAL_PARTITION ) Enabled
HHC00890I Facility(VIRTUAL_MACHINE ) Disabled
HHC00890I Facility(QDIO_ASSIST ) Disabled
HHC00890I Facility(INTERVAL_TIMER ) Enabled
HHC00890I Facility(DETECT_PGMINTLOOP ) Enabled


On 2016-04-23 10:55, ***@... mailto:***@... [hercules-390] wrote:

Hi Gert


That's an interesting observation.


I currently don't know, under which conditions (if at all) OpenSSL uses the cryptographic instructions, as I never looked into this. If it behaves as a good citizen it issues the query function provided by each of the instructions during initialization and from then on uses the cryptographic instructions for the functions found to be available and its own code for those functions not being available. Clearly, one can assume that "its own code" will work correctly, or, at least, deliver the expected results when running the test suites. So, one reason for the behavior you are observing can be that OpenSSL doesn't use the defective instructions during your test run on Hyperion.


On the Spinhawk (Hercules 3.x) side of things the features activated in featxxx.h (xxx being the archmode) decide, which function codes will be reported available by the query functions, once dyncrypt is loaded.


On the Hyperion side in addition to the feature activation in featxxx.h there is the dynamic situation given by the archlvl command, with the initial defaults determined in archlvl.c. The dyncrypt module uses both: At compile time it honors the definitions given by featxxx.h and at run time it cross checks the settings given by archlvl.


So, it would be interesting to see the output of the following two commands when the system you are using for your tests is running on Hyperion:


archlvl (without arguments)
archlvl query all


In addition, it would be interesting to see the featxxx.h used for building the architecture shown by the first archlvl command.


Maybe we can draw some conclusions from this. On the other hand, the results from Paul's and your testings with my upcoming patch will probably bring more clarity. And, yes, if this still brings not the level of insight needed to understand what's going on, a close look into the OpenSSL source would also be indicated.



Cheers
JÃŒrgen

---In hercules-***@yahoogroups.com mailto:hercules-***@yahoogroups.com, <***@...> mailto:***@... wrote :


Hi,

Indeed a tough one it seems. Very impressive. From your part.


Furthermore I can report that:


Make test for openssl crashes hercules 3.07.


3.11 and 3.12 produce the error from Paul (ciphertext mismatch).


4.00 hyperion does not produce an error at all!This sounds very strange. Maybe I am doing something wrong?


Regards,
Gert


Verzonden van Yahoo Mail voor iPhone

Op donderdag, april 21, 2016, 10:40 PM, ***@... [hercules-390] <hercules-***@yahoogroups.com> mailto:hercules-***@yahoogroups.com schreef:
Hi Paul, Gert


Well, the below was once again too optimistic, it didn't stand my plausibility checks .


This forced me to dive in even deeper. In the meantime I know the "IEEE Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices (1619-2007)" by heart, in fact I can sing to its lyrics. This stuff really has the potential to drive me insane...


Most annoyingly, it turned out that one of my very first tests after Paul reported the problem targeted the correct algorithm, but I made a mistake implementing it, which led me to completely rule it out from then on. So it was necessary to go through the full theory, only to realize that I already was on the correct path in the very beginning . At least I can now say I'm sure doing it correctly as opposed to only assuming it in the first place .


Now I'll go back to dyncrypt, implement my findings and go again through my tests... this will still need a few days.


Cheers
JÃŒrgen

---In hercules-***@yahoogroups.com mailto:hercules-***@yahoogroups.com, <***@...> mailto:***@... wrote :


Hi Paul, Gert


just letting you know: Problem solved (hopefully).


I'll now do some plausibility checks to be as confident as possible that things on the XTS side do work now as expected. Paul's OpenSSL tests will then hopefully work cleanly too...


Additionally I'll go over the KIMD GHASH function to verify whether this one is working correctly or is broken too. If necessary it will get the same fix applied as KM/PCC now have for XTS.


Given my current time constraints these activities will probably take some additional two or three days. I'll publish a patch once I'm done with this (currently it's some 200 lines of code changed in dyncrypt.c, which I consider a major change, although a big part of it is the precomputed exp_table).


Cheers
JÃŒrgen

['John P. Hartmann' [e-mail] [hercules-390]]

Would it be more expedient to run a program that checks whether the
instruction program checks or executes (ignoring the result for now)?

Refer to tests/README for a description of the testing harness.

Post by ***@id.ethz.ch [hercules-390]
If you like, you could now investigate why the cryptographic
instructions are disabled on your system. This would require you to

[Truda [e-mail] [hercules-390]]

Hello,

Post by ***@id.ethz.ch [hercules-390]
Hi Gert
thanks for your reply! At the current stage I think it fully suffices
to do exactly what you did: Run the standard tests that come with
OpenSSL, i.e. it isn't yet necessary to build a dedicated test case
(which doesn't mean that this might not become necessary when digging
deeper).
However, the output of your archlvl commands below already gives a
nice indication on the behavior of OpenSSL: One sees that the
cryptographic instructions are disabled: They hide behind facilities
MSA_EXTENSION_n (n being 1 to 4) and MSG_SECURITY. That means, in your
Hyperion configuration OpenSSL has to use "its own code" instead of
the instructions, which explains why you don't see any errors.
If you like, you could now investigate why the cryptographic
instructions are disabled on your system. This would require you to
#define FEATURE_MESSAGE_SECURITY_ASSIST
#define FEATURE_MESSAGE_SECURITY_ASSIST_EXTENSION_1
#define FEATURE_MESSAGE_SECURITY_ASSIST_EXTENSION_2
#define FEATURE_MESSAGE_SECURITY_ASSIST_EXTENSION_3
#define FEATURE_MESSAGE_SECURITY_ASSIST_EXTENSION_4

These features are enabled in my feat900.h file but it turns out they
were not activated in the running system as I used an old Hercules
config file with Archlvl=ESAME

Changing this to z/Arch did enable them (checked with archlvl query all)
and sure enough like you predicted the errors were also present in Hyperion.

So for PADE i think we can conclude that for a workaround put ESAME as
architecture and the openssl test should pass also on 3.11 with SLES

I guess the difference between z/Arch and ESAME is explained here:

http://hercules-390.github.io/html/hercconf.html#ARCHLVL


Regards,
Gert

Post by ***@id.ethz.ch [hercules-390]
If they are not in feat900.h, put them in (double check they are not
sitting inside some #ifdef sections that prevent them from
getting executed) and rebuild Hercules.
Then ensure dyncrypt is loaded (issue an lsmod command to see all
loaded modules), and, of course, ensure the above mentioned facilities
are reported being enabled by archlvl query all. Once these conditions
are met, I'd bet the OpenSSL tests will report the same errors you saw
on Hercules 3.11/3.12 .
Cheers
JÃŒrgen
Hello,
as I said previously I am not sure of the relevance of my tests as I
just played around a bit without logically building a test case.
However these are the settings of the commands as requested.
Maybe you just tell me what to test from scratch with which settings
and which hercules versions so the conclusions are correct.

Post by ***@id.ethz.ch [hercules-390]

Archlvl

HHC01603I archlvl
HHC02203I archmode : z/Arch

Post by ***@id.ethz.ch [hercules-390]

archlvl query all

HHC00890I Facility(HFP_MULT_ADD_SUB )
Enabled +
HHC00890I Facility(EXTENDED_IMMED ) Enabled
HHC00890I Facility(TRAN_FAC3 ) Enabled
HHC00890I Facility(HFP_UNNORM_EXT ) Enabled
HHC00890I Facility(ETF2_ENHANCEMENT ) Enabled
HHC00890I Facility(STORE_CLOCK_FAST ) Enabled
HHC00890I Facility(PARSING_ENHANCE ) Enabled
HHC00890I Facility(MVCOS ) Enabled
HHC00890I Facility(TOD_CLOCK_STEER ) Enabled
HHC00890I Facility(ETF3_ENHANCEMENT ) Enabled
HHC00890I Facility(EXTRACT_CPU_TIME ) Enabled
HHC00890I Facility(CSSF ) Enabled
HHC00890I Facility(CSSF2 ) Enabled
HHC00890I Facility(GEN_INST_EXTN ) Enabled
HHC00890I Facility(EXECUTE_EXTN ) Enabled
HHC00890I Facility(ENH_MONITOR ) Disabled
HHC00890I Facility(LOAD_PROG_PARAM ) Disabled
HHC00890I Facility(FPS_ENHANCEMENT ) Enabled
HHC00890I Facility(DECIMAL_FLOAT ) Enabled
HHC00890I Facility(DFP_HPERF ) Enabled
HHC00890I Facility(FAST_BCR_SERIAL ) Disabled
HHC00890I Facility(CMPSC_ENH ) Disabled
HHC00890I Facility(RES_REF_BITS_MUL ) Disabled
HHC00890I Facility(ACC_EX_FS_INDIC ) Disabled
HHC00890I Facility(MSA_EXTENSION_3 ) Disabled
HHC00890I Facility(MSA_EXTENSION_4 ) Disabled
HHC00890I Facility(MOVE_INVERSE ) Enabled
HHC00890I Facility(MSA_EXTENSION_1 ) Disabled
HHC00890I Facility(MSA_EXTENSION_2 ) Disabled
HHC00890I Facility(PROBSTATE_DIAGF08 ) Disabled
HHC00890I Facility(SIGP_SETARCH_S370 ) Disabled
HHC00890I Facility(HOST_RESOURCE_ACCESS) Disabled
HHC00890I Facility(QEBSM ) Disabled
HHC00890I Facility(QDIO_THININT ) Disabled
HHC00890I Facility(QDIO_TDD ) Disabled
HHC00890I Facility(SVS ) Disabled
HHC00890I Facility(LOGICAL_PARTITION ) Enabled
HHC00890I Facility(VIRTUAL_MACHINE ) Disabled
HHC00890I Facility(QDIO_ASSIST ) Disabled
HHC00890I Facility(INTERVAL_TIMER ) Enabled
HHC00890I Facility(DETECT_PGMINTLOOP ) Enabled

Post by ***@id.ethz.ch [hercules-390]
Hi Gert
That's an interesting observation.
I currently don't know, under which conditions (if at all)
OpenSSL uses the cryptographic instructions, as I never looked
into this. If it behaves as a good citizen it issues the query
function provided by each of the instructions during
initialization and from then on uses the cryptographic
instructions for the functions found to be available and its own
code for those functions not being available. Clearly, one can
assume that "its own code" will work correctly, or, at least,
deliver the expected results when running the test suites. So,
one reason for the behavior you are observing can be that OpenSSL
doesn't use the defective instructions during your test run on
Hyperion.
On the Spinhawk (Hercules 3.x) side of things the features
activated in featxxx.h (xxx being the archmode) decide, which
function codes will be reported available by the query functions,
once dyncrypt is loaded.
On the Hyperion side in addition to the feature activation in
featxxx.h there is the dynamic situation given by the archlvl
command, with the initial defaults determined in archlvl.c. The
dyncrypt module uses both: At compile time it honors the
definitions given by featxxx.h and at run time it cross checks
the settings given by archlvl.
So, it would be interesting to see the output of the following
two commands when the system you are using for your tests is
archlvl (without arguments)
archlvl query all
In addition, it would be interesting to see the featxxx.h used
for building the architecture shown by the first archlvl command.
Maybe we can draw some conclusions from this. On the other hand,
the results from Paul's and your testings with my upcoming patch
will probably bring more clarity. And, yes, if this still brings
not the level of insight needed to understand what's going on, a
close look into the OpenSSL source would also be indicated.
Cheers
JÃŒrgen
Hi,
Indeed a tough one it seems. Very impressive. From your part.
Make test for openssl crashes hercules 3.07.
3.11 and 3.12 produce the error from Paul (ciphertext mismatch).
4.00 hyperion does not produce an error at all!This sounds very
strange. Maybe I am doing something wrong?
Regards,
Gert
Verzonden van Yahoo Mail voor iPhone <https://yho.com/footer0>
Hi Paul, Gert
Well, the below was once again too optimistic, it didn't
stand my plausibility checks .
This forced me to dive in even deeper. In the meantime I
know the "IEEE Standard for Cryptographic Protection of
Data on Block-Oriented Storage Devices (1619-2007)" by
heart, in fact I can sing to its lyrics. This stuff
really has the potential to drive me insane...
Most annoyingly, it turned out that one of my very first
tests after Paul reported the problem targeted the
correct algorithm, but I made a mistake implementing it,
which led me to completely rule it out from then on. So
it was necessary to go through the full theory, only to
realize that I already was on the correct path in the
very beginning . At least I can now say I'm sure doing it
correctly as opposed to only assuming it in the first place .
Now I'll go back to dyncrypt, implement my findings and
go again through my tests... this will still need a few days.
Cheers
JÃŒrgen
Hi Paul, Gert
just letting you know: Problem solved (hopefully).
I'll now do some plausibility checks to be as confident
as possible that things on the XTS side do work now as
expected. Paul's OpenSSL tests will then hopefully work
cleanly too...
Additionally I'll go over the KIMD GHASH function to
verify whether this one is working correctly or is broken
too. If necessary it will get the same fix applied as
KM/PCC now have for XTS.
Given my current time constraints these activities will
probably take some additional two or three days. I'll
publish a patch once I'm done with this (currently it's
some 200 lines of code changed in dyncrypt.c, which I
consider a major change, although a big part of it is the
precomputed exp_table).
Cheers
JÃŒrgen

[[e-mail] [hercules-390]]

Hi Gert


thanks for checking this!


So, as expected, this boils down to:
OpenSSL under S/390 Linux uses the z/Arch cryptographic instructions, if they are available. If they are not available, it reverts to its own internal software implementation of the functions provided by these instructions. The latter will for sure come with a performance penalty, which would be interesting to measure on occasion. Given that Hercules' ESAME level disables the z/Arch cryptographic instructions, this can be used to easily force OpenSSL to use its own internal software implementation of the functions provided by these instructions. This can be used as a workaround until the z/Arch cryptographic instructions are fixed such that they provide the results expected by OpenSSL's installation verification tests. One should expect a performance penalty when using this workaround.
I just managed to implement changes to the PCC and KM z/Arch cryptographic instructions that are supposed to fix the problem reported by OpenSSL. This time the changes passed my own test cases . I'll publish the respective patch shortly. Once tested satisfactorily this patch will make the workaround obsolete.


Cheers
JÃŒrgen

---In hercules-***@yahoogroups.com, <***@...> wrote :


Hello,



On 2016-04-23 11:54, ***@... mailto:***@... [hercules-390] wrote:

Hi Gert


thanks for your reply! At the current stage I think it fully suffices to do exactly what you did: Run the standard tests that come with OpenSSL, i.e. it isn't yet necessary to build a dedicated test case (which doesn't mean that this might not become necessary when digging deeper).


However, the output of your archlvl commands below already gives a nice indication on the behavior of OpenSSL: One sees that the cryptographic instructions are disabled: They hide behind facilities MSA_EXTENSION_n (n being 1 to 4) and MSG_SECURITY. That means, in your Hyperion configuration OpenSSL has to use "its own code" instead of the instructions, which explains why you don't see any errors.


If you like, you could now investigate why the cryptographic instructions are disabled on your system. This would require you to verify that the following #defines are in your feat900.h:


#define FEATURE_MESSAGE_SECURITY_ASSIST
#define FEATURE_MESSAGE_SECURITY_ASSIST_EXTENSION_1
#define FEATURE_MESSAGE_SECURITY_ASSIST_EXTENSION_2
#define FEATURE_MESSAGE_SECURITY_ASSIST_EXTENSION_3
#define FEATURE_MESSAGE_SECURITY_ASSIST_EXTENSION_4

These features are enabled in my feat900.h file but it turns out they were not activated in the running system as I used an old Hercules config file with Archlvl=ESAME

Changing this to z/Arch did enable them (checked with archlvl query all) and sure enough like you predicted the errors were also present in Hyperion.

So for PADE i think we can conclude that for a workaround put ESAME as architecture and the openssl test should pass also on 3.11 with SLES

I guess the difference between z/Arch and ESAME is explained here:

http://hercules-390.github.io/html/hercconf.html#ARCHLVL http://hercules-390.github.io/html/hercconf.html#ARCHLVL


Regards,
Gert

[Truda [e-mail] [hercules-390]]

Hello,

A quick test (with the OpenSSL builtin tests) to measure the performance
difference between z/Arch and ESAME (= Facility(MSA_EXTENSIONs) enabled
or disabled) reveals that

with MSA_EXTENSION facilities (z/arch) = 100
without MSA_EXTENSION facilities (ESAME) = 274

Just a quick test but still indicative I believe.

Regards,
Gert

Post by ***@id.ethz.ch [hercules-390]
Hi Gert
thanks for checking this!
* OpenSSL under S/390 Linux uses the z/Arch cryptographic
instructions, if they are available. If they are not available,
it reverts to its own internal software implementation of the
functions provided by these instructions. The latter will for sure
come with a performance penalty, which would be interesting to
measure on occasion.
* Given that Hercules' ESAME level disables the z/Arch cryptographic
instructions, this can be used to easily force OpenSSL to use its
own internal software implementation of the functions provided
by these instructions. This can be used as a workaround until the
z/Arch cryptographic instructions are fixed such that they provide
the results expected by OpenSSL's installation verification tests.
One should expect a performance penalty when using this workaround.
I just managed to implement changes to the PCC and KM z/Arch
cryptographic instructions that are supposed to fix the problem
reported by OpenSSL. This time the changes passed my own test cases .
I'll publish the respective patch shortly. Once tested satisfactorily
this patch will make the workaround obsolete.
Cheers
JÃŒrgen
Hello,

Post by ***@id.ethz.ch [hercules-390]
Hi Gert
thanks for your reply! At the current stage I think it fully
suffices to do exactly what you did: Run the standard tests that
come with OpenSSL, i.e. it isn't yet necessary to build a
dedicated test case (which doesn't mean that this might not
become necessary when digging deeper).
However, the output of your archlvl commands below already gives
a nice indication on the behavior of OpenSSL: One sees that the
cryptographic instructions are disabled: They hide
behind facilities MSA_EXTENSION_n (n being 1 to 4) and
MSG_SECURITY. That means, in your Hyperion configuration OpenSSL
has to use "its own code" instead of the instructions, which
explains why you don't see any errors.
If you like, you could now investigate why the cryptographic
instructions are disabled on your system. This would require you
#define FEATURE_MESSAGE_SECURITY_ASSIST
#define FEATURE_MESSAGE_SECURITY_ASSIST_EXTENSION_1
#define FEATURE_MESSAGE_SECURITY_ASSIST_EXTENSION_2
#define FEATURE_MESSAGE_SECURITY_ASSIST_EXTENSION_3
#define FEATURE_MESSAGE_SECURITY_ASSIST_EXTENSION_4

These features are enabled in my feat900.h file but it turns out
they were not activated in the running system as I used an old
Hercules config file with Archlvl=ESAME
Changing this to z/Arch did enable them (checked with archlvl
query all) and sure enough like you predicted the errors were also
present in Hyperion.
So for PADE i think we can conclude that for a workaround put
ESAME as architecture and the openssl test should pass also on
3.11 with SLES
http://hercules-390.github.io/html/hercconf.html#ARCHLVL
Regards,
Gert

[[e-mail] [hercules-390]]

Hi Gert


thanks for testing!


That means, doing the computations using regular (not the cryptographic ones) emulated z/Arch instructions on Hercules is roughly three times slower than having the computations done using native (x86) instructions on the host system. Or, the other way round, dyncrypt brings almost a factor 3 performance gain on that specific mix of cryptographic instructions.


It should be noted, that from an OpenSSL point of view, dyncrypt provides "hardware" support similar to specialized instructions like PCLMULQDQ on Intel processors. However, dyncrypt doesn't try to make use of those instructions on the host processor, it is a mere software implementation. Thus, the performance gain basically comes from eliminating the emulation overhead.


One could of course think about making dyncrypt use hardware support if available on the underlying host system. Doing this directly would require lots of checking at configure time and lots of conditional compilation depending on which host architecture is targeted. Or, one could simply interface to OpenSSL as a configuration option, requiring libssl and libcrypto to be available on the host. The latter probably isn't too difficult to do (modulo details), but might easily result in unintended deviations from the POP.


Anyway, given that up to now nobody realized the bugs in dyncrypt and nobody reported performance problems, I think it should suffice to just fix the bugs (which is hard enough ;-).


Cheers
JÃŒrgen


---In hercules-***@yahoogroups.com, <***@...> wrote :


Hello,

A quick test (with the OpenSSL builtin tests) to measure the performance difference between z/Arch and ESAME (= Facility(MSA_EXTENSIONs) enabled or disabled) reveals that

with MSA_EXTENSION facilities (z/arch) = 100
without MSA_EXTENSION facilities (ESAME) = 274

Just a quick test but still indicative I believe.

Regards,
Gert

On 2016-04-24 14:47, ***@... mailto:***@... [hercules-390] wrote:

Hi Gert


thanks for checking this!


So, as expected, this boils down to:
OpenSSL under S/390 Linux uses the z/Arch cryptographic instructions, if they are available. If they are not available, it reverts to its own internal software implementation of the functions provided by these instructions. The latter will for sure come with a performance penalty, which would be interesting to measure on occasion. Given that Hercules' ESAME level disables the z/Arch cryptographic instructions, this can be used to easily force OpenSSL to use its own internal software implementation of the functions provided by these instructions. This can be used as a workaround until the z/Arch cryptographic instructions are fixed such that they provide the results expected by OpenSSL's installation verification tests. One should expect a performance penalty when using this workaround.
I just managed to implement changes to the PCC and KM z/Arch cryptographic instructions that are supposed to fix the problem reported by OpenSSL. This time the changes passed my own test cases . I'll publish the respective patch shortly. Once tested satisfactorily this patch will make the workaround obsolete.


Cheers
JÃŒrgen

---In hercules-***@yahoogroups.com mailto:hercules-***@yahoogroups.com, <***@...> mailto:***@... wrote :


Hello,



On 2016-04-23 11:54, ***@... mailto:***@... [hercules-390] wrote:

Hi Gert


thanks for your reply! At the current stage I think it fully suffices to do exactly what you did: Run the standard tests that come with OpenSSL, i.e. it isn't yet necessary to build a dedicated test case (which doesn't mean that this might not become necessary when digging deeper).


However, the output of your archlvl commands below already gives a nice indication on the behavior of OpenSSL: One sees that the cryptographic instructions are disabled: They hide behind facilities MSA_EXTENSION_n (n being 1 to 4) and MSG_SECURITY. That means, in your Hyperion configuration OpenSSL has to use "its own code" instead of the instructions, which explains why you don't see any errors.


If you like, you could now investigate why the cryptographic instructions are disabled on your system. This would require you to verify that the following #defines are in your feat900.h:


#define FEATURE_MESSAGE_SECURITY_ASSIST
#define FEATURE_MESSAGE_SECURITY_ASSIST_EXTENSION_1
#define FEATURE_MESSAGE_SECURITY_ASSIST_EXTENSION_2
#define FEATURE_MESSAGE_SECURITY_ASSIST_EXTENSION_3
#define FEATURE_MESSAGE_SECURITY_ASSIST_EXTENSION_4

These features are enabled in my feat900.h file but it turns out they were not activated in the running system as I used an old Hercules config file with Archlvl=ESAME

Changing this to z/Arch did enable them (checked with archlvl query all) and sure enough like you predicted the errors were also present in Hyperion.

So for PADE i think we can conclude that for a workaround put ESAME as architecture and the openssl test should pass also on 3.11 with SLES

I guess the difference between z/Arch and ESAME is explained here:

http://hercules-390.github.io/html/hercconf.html#ARCHLVL http://hercules-390.github.io/html/hercconf.html#ARCHLVL


Regards,
Gert

[[e-mail] [hercules-390]]

Hi All


Finally, I think the problem originally reported by Paul is solved. The solution requires changes to the PCC and to the KM instructions, which is why I changed the subject of this thread. A tentative patch is now available for download at


https://polybox.ethz.ch/index.php/s/o2knBR1aHwVCcV3 https://polybox.ethz.ch/index.php/s/o2knBR1aHwVCcV3


As usual, the archive contains two versions of the patch, one matching dyncrypt.c as found in Spinhawk (at the Hercules 3.12 release level) and another matching the current Hyperion. Before applying this patch please make sure that my earlier patch to dyncrypt (see the first mail of this thread at https://groups.yahoo.com/neo/groups/hercules-390/conversations/messages/78887 https://groups.yahoo.com/neo/groups/hercules-390/conversations/messages/78887) is applied. Currently, Hyperion has it applied, but it isn't yet in Spinhawk.


Given that the patch is non trivial, I don't recommend as of yet to commit it to any of the repositories. Instead I'd appreciate it being tested by users of the cryptographic instructions (if there are any). In particular I'd be grateful for feedback from Paul and Gert concerning the behavior of the OpenSSL installation tests after applying the patch.


Problem description:


The XTS related functions (codes 50, 52, 58 and 60 of the KM and the PCC instructions) deliver invalid results. Results are stable, except for PCC function codes 58 and 60, which deliver arbitrary results. None of the functions ever delivers a correct result.


Root cause:


The arbitrary results from PCC function codes 58 and 60 are caused by memory overlay due to an invalid length (too short) of the parameter block. Fixing this overlay makes the results stable, but equally invalid as with the other function codes.
The invalid results come from a misinterpretation of the algorithm to use for the GF(2128) multiplication. All diagrams and descriptions in the POP suggest it is the same algorithm as used with function code 65 of the KIMD instruction. However, it is not: For the GCM situation in KIMD the specification found in NIST Special Publication 800-38D, dated November 2007, is relevant, while for the XTS situation in KM and PCC the specification found in IEEE standard 1619-2007 is relevant. In fact, both algorithms are the same (and thus the POP is correct). However, the bit order of the arguments isn't the same in both standards, which isn't exactly mentioned in the POP (one can find it in the prefix pages, once one knows what to search for).
Solution:


Fix the memory overlay in PCC and use the correct algorithm for the GF(2128) multiplication in KM and PCC.


Cheers
JÃŒrgen


---In hercules-***@yahoogroups.com, <***@...> wrote :


Hi Gert


thanks for checking this!


So, as expected, this boils down to:
OpenSSL under S/390 Linux uses the z/Arch cryptographic instructions, if they are available. If they are not available, it reverts to its own internal software implementation of the functions provided by these instructions. The latter will for sure come with a performance penalty, which would be interesting to measure on occasion. Given that Hercules' ESAME level disables the z/Arch cryptographic instructions, this can be used to easily force OpenSSL to use its own internal software implementation of the functions provided by these instructions. This can be used as a workaround until the z/Arch cryptographic instructions are fixed such that they provide the results expected by OpenSSL's installation verification tests. One should expect a performance penalty when using this workaround.
I just managed to implement changes to the PCC and KM z/Arch cryptographic instructions that are supposed to fix the problem reported by OpenSSL. This time the changes passed my own test cases . I'll publish the respective patch shortly. Once tested satisfactorily this patch will make the workaround obsolete.


Cheers
JÃŒrgen

[[e-mail] [hercules-390]]

JÃŒrgen ,
Works in 3.12! Openssl tests run all the way through. Thank you very much for your work. It is a bit ironic that I typically do not run the OpenSSL tests after building because I simply need the .so files for linking but decided to do so with Linux s390x. Again, great work and thank you very much.
Regards,
Paul

[[e-mail] [hercules-390]]

Hi Paul


thanks for your feedback! It's good to see the bug is most probably gone .


Cheers
JÃŒrgen



---In hercules-***@yahoogroups.com, <***@...> wrote :

JÃŒrgen ,
Works in 3.12! Openssl tests run all the way through. Thank you very much for your work. It is a bit ironic that I typically do not run the OpenSSL tests after building because I simply need the .so files for linking but decided to do so with Linux s390x. Again, great work and thank you very much.
Regards,
Paul

[[e-mail] [hercules-390]]

Hi All


From Paul's feedback (successful execution of the OpenSSL installation tests on z/Linux) I assume my below mentioned patches to the dyncrypt module fix the broken instructions. However, this is an indirect verification only, as it is not transparent, to what extent OpenSSL prefers using the cryptographic instructions over its own internal computations.


Thus, from my point of view, it is necessary to also do at least a minimal set of direct comparisons of the dyncrypt results with the results the cryptographic instructions produce on real iron. And, for once, I mean real iron: No virtualization, no z/PDT, no Hercules. Just real z/OS on real IBM iron.


I strongly assume there are members in this group who have access to a real z/OS system (at work, for example) and I would very much appreciate if volunteers helped me out by running a very simple test on their system:


The idea basically is, to run the test program I developed while debugging dyncrypt. This program executes each of the cryptographic instructions provided by the Message-Security-Assist with Extensions 1-4 at least once, such that in total each function code is also called at least once. The results are compared with those obtained using OpenSSL on Intel Linux, which I consider being a sufficiently independent path for this purpose.


Of course this is by far not a comprehensive testing. But if it delivers the same results on real iron as on Hercules this is a strong indication that the dyncrypt implementation now is algorithmically correct.


The program will produce absolutely no output, if everything runs smoothly and the results compare as expected. If a discrepancy is found, it is reported to SYSPRINT. So, in general one can say: If the program produces any output, something went wrong.


The program can be found at


https://polybox.ethz.ch/index.php/s/gmBgvNlxGx6RUza https://polybox.ethz.ch/index.php/s/gmBgvNlxGx6RUza


The ZIP archive contains the source, a sample JCL to run it, an XMITted load library containing the readily linked program and an assembly listing of the program. It is not necessary to assemble and link the program yourself, you can just use it from the provided loadlib. I personally guarantee the program will do no harm to your system .


As one of the cryptographic instructions (PCKMO) is privileged the program calls the modeset macro to enter supervisor state before testing this instruction, which also is the final test. So, while I'd of course like you to run the program from an authorized library, I'm fully aware that this will not be allowable in most production style environments. In this case, simply run the program unauthorized. It will then abend with the usual S047, but the results will be complete, except for the PCKMO test, of course, which on the other hand has no algorithmic component not already tested with the other instructions. So, in short, I don't mind if it abends, the run is still very valuable for me.


Thanks a lot in advance for any help!


Cheers
JÃŒrgen

---In hercules-***@yahoogroups.com, <***@...> wrote :


Hi All


Finally, I think the problem originally reported by Paul is solved. The solution requires changes to the PCC and to the KM instructions, which is why I changed the subject of this thread. A tentative patch is now available for download at


https://polybox.ethz.ch/index.php/s/o2knBR1aHwVCcV3 https://polybox.ethz.ch/index.php/s/o2knBR1aHwVCcV3


As usual, the archive contains two versions of the patch, one matching dyncrypt.c as found in Spinhawk (at the Hercules 3.12 release level) and another matching the current Hyperion. Before applying this patch please make sure that my earlier patch to dyncrypt (see the first mail of this thread at https://groups.yahoo.com/neo/groups/hercules-390/conversations/messages/78887 https://groups.yahoo.com/neo/groups/hercules-390/conversations/messages/78887) is applied. Currently, Hyperion has it applied, but it isn't yet in Spinhawk.


Given that the patch is non trivial, I don't recommend as of yet to commit it to any of the repositories. Instead I'd appreciate it being tested by users of the cryptographic instructions (if there are any). In particular I'd be grateful for feedback from Paul and Gert concerning the behavior of the OpenSSL installation tests after applying the patch.


Problem description:


The XTS related functions (codes 50, 52, 58 and 60 of the KM and the PCC instructions) deliver invalid results. Results are stable, except for PCC function codes 58 and 60, which deliver arbitrary results. None of the functions ever delivers a correct result.


Root cause:


The arbitrary results from PCC function codes 58 and 60 are caused by memory overlay due to an invalid length (too short) of the parameter block. Fixing this overlay makes the results stable, but equally invalid as with the other function codes.
The invalid results come from a misinterpretation of the algorithm to use for the GF(2128) multiplication. All diagrams and descriptions in the POP suggest it is the same algorithm as used with function code 65 of the KIMD instruction. However, it is not: For the GCM situation in KIMD the specification found in NIST Special Publication 800-38D, dated November 2007, is relevant, while for the XTS situation in KM and PCC the specification found in IEEE standard 1619-2007 is relevant. In fact, both algorithms are the same (and thus the POP is correct). However, the bit order of the arguments isn't the same in both standards, which isn't exactly mentioned in the POP (one can find it in the prefix pages, once one knows what to search for).
Solution:


Fix the memory overlay in PCC and use the correct algorithm for the GF(2128) multiplication in KM and PCC.


Cheers
JÃŒrgen


---In hercules-***@yahoogroups.com, <***@...> wrote :


Hi Gert


thanks for checking this!


So, as expected, this boils down to:
OpenSSL under S/390 Linux uses the z/Arch cryptographic instructions, if they are available. If they are not available, it reverts to its own internal software implementation of the functions provided by these instructions. The latter will for sure come with a performance penalty, which would be interesting to measure on occasion. Given that Hercules' ESAME level disables the z/Arch cryptographic instructions, this can be used to easily force OpenSSL to use its own internal software implementation of the functions provided by these instructions. This can be used as a workaround until the z/Arch cryptographic instructions are fixed such that they provide the results expected by OpenSSL's installation verification tests. One should expect a performance penalty when using this workaround.
I just managed to implement changes to the PCC and KM z/Arch cryptographic instructions that are supposed to fix the problem reported by OpenSSL. This time the changes passed my own test cases . I'll publish the respective patch shortly. Once tested satisfactorily this patch will make the workaround obsolete.


Cheers
JÃŒrgen

[[e-mail] [hercules-390]]

Hi All


Oh my! Eventually my first attempt of this post (from Wednesday) made it through... so, presumably, the second one (from Thursday) will also drop in in a few hours. Incredible . Sorry again for the bombardment...


Thanks a lot to all who already replied off list with test results. Everything looks good so far . Further results are still very welcome to get a broad picture...


Cheers
JÃŒrgen


---In hercules-***@yahoogroups.com, <***@...> wrote :


Hi All


From Paul's feedback (successful execution of the OpenSSL installation tests on z/Linux) I assume my below mentioned patches to the dyncrypt module fix the broken instructions. However, this is an indirect verification only, as it is not transparent, to what extent OpenSSL prefers using the cryptographic instructions over its own internal computations.


. . .

[[e-mail] [hercules-390]]

Hi All
First of all: Bear with me, if you are receiving this message twice, with slightly differing text. I already wrote it yesterday, using Yahoo Group’s Web GUI and, as so often before, it didn’t make it through to the group. Although I sometimes saw “lost” posts miraculously appearing even days after posting, I don’t want to wait much longer. Instead, I’m rewriting it now, but as I don’t have a copy of the first one, they will not be fully identical.
During the past few weeks I published a series of patches fixing various defects in z/Arch instructions emulated by Hercules, two of them concerning the cryptographic instructions provided by the dyncrypt module. All, except the final patch, were trivial in the sense that the defects they fix were easy to spot as coding errors and/or the results to be expected from the instructions in question were easy to verify.
The final patch, however, was not trivial at all, because in addition to coding errors it also had to fix errors in the algorithms used for the AES-XTS related functions of the PCC and the KM cryptographic instruction. The z/Arch POP (depending on the version one looks at) has misleading or at least ambiguous descriptions on the intended outcome of these instructions, such that it isn’t easy to determine, if my patch, above fixing the coding errors, also is algorithmically correct.
A strong indication of correctness is the fact that the installation tests of OpenSSL on z/Linux pass without errors, which they didn’t without the patch, as Paul reported. However, this indication is very indirect because it isn’t transparent, in which situations OpenSSL uses its own software implementation for the cryptographic computations, or the “hardware” implementation provided by the z/Arch cryptographic instructions.
In the course of debugging the cryptographic instructions I created a test program on MVS 3.8j, which executes the instructions and compares the results with those obtained using OpenSSL on Intel Linux for the same computations. The program executes each instruction at least once, using functions from different groups (AES & DES in their various modes, SHA, CMAC & GMAC hashes, etc.) such that in total each algorithm also gets used at least once.
Of course this is not a comprehensive test suite exercising each instruction/function combination possible, but I think it suffices to find potential implementation errors on Hercules, provided the OpenSSL results used for verification compare identical to the results of the same tests when run on real iron (if Hercules = OpenSSL & real iron z/Arch = OpenSSL, then Hercules = real iron z/Arch).
To make the long story short: Running the test program on real z/Arch systems will give a very strong indication whether the cryptographic instructions are now implemented correctly on Hercules or not, and particularly, whether or not I interpreted the ambiguities in the POP correctly.
Presumably, there are quite a few members in this group who are having access to a real z/Arch system (at work for example). I’d very much appreciate if some of you volunteered to run the test program on your systems. The most reliable results are to be expected for z/OS running first level (i.e. not under z/VM) on a z/Arch system, no older than ~2008, which has the Message-Security-Assist with Extensions 1-4 installed and active. For once, this time I really mean it: Original IBM z/OS on original IBM real iron z/Arch, i.e. no z/PDT, no Hercules (not that results from the latter wouldn’t be interesting and perhaps even surprising too, but they don’t help much with the validation attempt at hand here).
The program is very easy to run. Download the zip archive from
https://polybox.ethz.ch/index.php/s/gmBgvNlxGx6RUza https://polybox.ethz.ch/index.php/s/gmBgvNlxGx6RUza
It contains an XMITted load library (tstcrypt.load.xmi), containing the TSTCRYPT load module and a sample JCL (tstcrypt.jcl) to run it. Additionally it also contains the program’s source and assembly listing for informational purposes (except if you want to change the program, it isn’t necessary to assemble it).
To run the program, receive the load library using the TSO/E RECEIVE command, edit the JCL to reflect your installation’s requirements and submit it.
If at all possible, I’d appreciate if you ran the program from an authorized library, which allows testing of the privileged PCKMO instruction to succeed. However, if this isn’t possible or you don’t want to do this, running from an unauthorized library is fine for me too: The PCKMO test is the last one. It will abend with an S047 abend if not running authorized, but the results of the previous tests are all valid and valuable. I personally guarantee, however, that the program will not do any harm to your system when running authorized.
Except a few WTOs indicating which test is about to be run, no output is expected from successful tests. Tests not delivering the expected results will report this to SYSPRINT. Once done, please report your results here, simply by stating machine type and model, z/OS version used, and whether there was any output to SYSPRINT.
Thanks in advance for any help with this!
Cheers
JÃŒrgen

---In hercules-***@yahoogroups.com, <***@...> wrote :
Hi All
Finally, I think the problem originally reported by Paul is solved. The solution requires changes to the PCC and to the KM instructions, which is why I changed the subject of this thread. A tentative patch is now available for download at
https://polybox.ethz.ch/index.php/s/0dXgLYjrpUb9ulT https://polybox.ethz.ch/index.php/s/0dXgLYjrpUb9ulT
As usual, the archive contains two versions of the patch, one matching dyncrypt.c as found in Spinhawk (at the Hercules 3.12 release level) and another matching the current Hyperion. Before applying this patch please make sure that my earlier patch to dyncrypt (see the first mail of this thread at https://groups.yahoo.com/neo/groups/hercules-390/conversations/messages/78887 https://groups.yahoo.com/neo/groups/hercules-390/conversations/messages/78887) is applied. Currently, Hyperion has it applied, but it isn't yet in Spinhawk.
Given that the patch is non trivial, I don't recommend as of yet to commit it to any of the repositories. Instead I'd appreciate it being tested by users of the cryptographic instructions (if there are any). In particular I'd be grateful for feedback from Paul and Gert concerning the behavior of the OpenSSL installation tests after applying the patch.
Problem description:
The XTS related functions (codes 50, 52, 58 and 60 of the KM and the PCC instructions) deliver invalid results. Results are stable, except for PCC function codes 58 and 60, which deliver arbitrary results. None of the functions ever delivers a correct result.
Root cause:
The arbitrary results from PCC function codes 58 and 60 are caused by memory overlay due to an invalid length (too short) of the parameter block. Fixing this overlay makes the results stable, but equally invalid as with the other function codes.
The invalid results come from a misinterpretation of the algorithm to use for the GF(2128) multiplication. All diagrams and descriptions in the POP suggest it is the same algorithm as used with function code 65 of the KIMD instruction. However, it is not: For the GCM situation in KIMD the specification found in NIST Special Publication 800-38D, dated November 2007, is relevant, while for the XTS situation in KM and PCC the specification found in IEEE standard 1619-2007 is relevant. In fact, both algorithms are the same (and thus the POP is correct). However, the bit order of the arguments isn't the same in both standards, which isn't exactly mentioned in the POP (one can find it in the prefix pages, once one knows what to search for).
Solution:
Fix the memory overlay in PCC and use the correct algorithm for the GF(2128) multiplication in KM and PCC.
Cheers
JÃŒrgen
---In hercules-***@yahoogroups.com, <***@...> wrote :
Hi Gert
thanks for checking this!
So, as expected, this boils down to:
OpenSSL under S/390 Linux uses the z/Arch cryptographic instructions, if they are available. If they are not available, it reverts to its own internal software implementation of the functions provided by these instructions. The latter will for sure come with a performance penalty, which would be interesting to measure on occasion.
Given that Hercules' ESAME level disables the z/Arch cryptographic instructions, this can be used to easily force OpenSSL to use its own internal software implementation of the functions provided by these instructions. This can be used as a workaround until the z/Arch cryptographic instructions are fixed such that they provide the results expected by OpenSSL's installation verification tests. One should expect a performance penalty when using this workaround.
I just managed to implement changes to the PCC and KM z/Arch cryptographic instructions that are supposed to fix the problem reported by OpenSSL. This time the changes passed my own test cases . I'll publish the respective patch shortly. Once tested satisfactorily this patch will make the workaround obsolete.
Cheers
JÃŒrgen

[Tony Harminc [e-mail] [hercules-390]]

Post by ***@id.ethz.ch [hercules-390]
The invalid results come from a misinterpretation of the algorithm to use
for the GF(2128) multiplication. All diagrams and descriptions in the POP
suggest it is the same algorithm as used with function code 65 of the KIMD
instruction. However, it is not: For the GCM situation in KIMD the
specification found in NIST Special Publication 800-38D, dated November
2007, is relevant, while for the XTS situation in KM and PCC the
specification found in IEEE standard 1619-2007 is relevant. In fact, both
algorithms are the same (and thus the POP is correct). However, the bit
order of the arguments isn't the same in both standards, which isn't
exactly mentioned in the POP (one can find it in the prefix pages, once one
knows what to search for).

In my experience over many years, IBM takes comments (RCFs) to the POP very
seriously, and often responds with an explanation even when there is not
strictly speaking an error.

I encourage you to report this to them, if only to see what the response
is, given all the circumstances.

Tony H.

[[e-mail] [hercules-390]]

Hi Tony


Right you are and that's exactly what I intend to do, once I find a minute to document it comprehensively .


Cheers
JÃŒrgen



---In hercules-***@yahoogroups.com, <***@...> wrote :


On 5 May 2016 at 08:18, ***@... mailto:***@... wrote:
The invalid results come from a misinterpretation of the algorithm to use for the GF(2128) multiplication. All diagrams and descriptions in the POP suggest it is the same algorithm as used with function code 65 of the KIMD instruction. However, it is not: For the GCM situation in KIMD the specification found in NIST Special Publication 800-38D, dated November 2007, is relevant, while for the XTS situation in KM and PCC the specification found in IEEE standard 1619-2007 is relevant. In fact, both algorithms are the same (and thus the POP is correct). However, the bit order of the arguments isn't the same in both standards, which isn't exactly mentioned in the POP (one can find it in the prefix pages, once one knows what to search for).


In my experience over many years, IBM takes comments (RCFs) to the POP very seriously, and often responds with an explanation even when there is not strictly speaking an error.


I encourage you to report this to them, if only to see what the response is, given all the circumstances.


Tony H.

[[e-mail] [hercules-390]]

Hi All


thanks a lot to all who provided real iron results using the test program I proposed a few days ago!


I received results from the following systems:


2098-E10 z/OS, too old
2818-M05 z/OS
2827-H20 z/OS
2828-??? z/CMS
2828-H06 z/OS
2964-N30 z/OS


All tests delivered the expected results, except on the 2098-E10, which simply is too old to support Message-Security-Assist Extension 4.


From these results I conclude my dyncrypt patches are working correctly. They are now committed in Spinhawk (thanks, Roger!) and in Hyperion.


Cheers
JÃŒrgen

[Truda [e-mail] [hercules-390]]

Hello,

I'm getting some more weird results (see below). I propose you don't
draw any conclusions from my unlogical testing. I will try to do it a
bit more properly tonight and report back to you tomorrow morning.

For your information all my Hercules's (Herculeses?) are built with the
same settings option -O2 and -march=native
If this might influence the result please let me know what settings to
use with compile time.

compile of hercules is on debian with gcc 5.2.1 but I could also do it
on CentOS7 or Fedora 23 server if required (=if the version of gcc when
compiling hercules might influence the result).

-------------
FINDINGS:
-------------

in Debian
Linux s390xDB 3.16.0-4-s390x #1 SMP Debian 3.16.7-ckt20-1+deb8u4
(2016-02-29) s390x GNU/Linux

gcc (Debian 4.9.2-10) 4.9.2

Post by ***@id.ethz.ch [hercules-390]

---------------------------------------------------------------------------------------
Testing cipher AES-128-XTS(encrypt/decrypt)
Key
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
IV
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Ciphertext
0000 91 7c f6 9e bd 68 b2 ec 9b 9f e9 a3 ea dd a6 92
0010 cd 43 d2 f5 95 98 ed 85 8c 02 c2 65 2f bf 92 2e
Makefile:159: recipe for target 'test_evp' failed
make[1]: Leaving directory '/home/gert/source/openssl-1.0.2g/test'
Makefile:460: recipe for target 'tests' failed

----------------------------------------------------------------------------------


While under 4.0 Hyperion it results in correct results:

------------------------------------------------------------------------------------

Post by ***@id.ethz.ch [hercules-390]

Testing cipher AES-128-XTS(encrypt/decrypt)
Key
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
IV
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Ciphertext
0000 91 7c f6 9e bd 68 b2 ec 9b 9f e9 a3 ea dd a6 92
0010 cd 43 d2 f5 95 98 ed 85 8c 02 c2 65 2f bf 92 2e
Testing cipher AES-128-XTS(encrypt/decrypt)
Key

-------------------------------------------------------------------------------------------

Post by ***@id.ethz.ch [hercules-390]
Hi Gert
That's an interesting observation.
I currently don't know, under which conditions (if at all) OpenSSL
uses the cryptographic instructions, as I never looked into this. If
it behaves as a good citizen it issues the query function provided by
each of the instructions during initialization and from then on uses
the cryptographic instructions for the functions found to be available
and its own code for those functions not being available. Clearly,
one can assume that "its own code" will work correctly, or, at least,
deliver the expected results when running the test suites. So, one
reason for the behavior you are observing can be that OpenSSL doesn't
use the defective instructions during your test run on Hyperion.
On the Spinhawk (Hercules 3.x) side of things the features activated
in featxxx.h (xxx being the archmode) decide, which function codes
will be reported available by the query functions, once dyncrypt is
loaded.
On the Hyperion side in addition to the feature activation in
featxxx.h there is the dynamic situation given by the archlvl command,
with the initial defaults determined in archlvl.c. The dyncrypt module
uses both: At compile time it honors the definitions given by
featxxx.h and at run time it cross checks the settings given by archlvl.
So, it would be interesting to see the output of the following two
commands when the system you are using for your tests is running on
archlvl (without arguments)
archlvl query all
In addition, it would be interesting to see the featxxx.h used for
building the architecture shown by the first archlvl command.
Maybe we can draw some conclusions from this. On the other hand, the
results from Paul's and your testings with my upcoming patch will
probably bring more clarity. And, yes, if this still brings not the
level of insight needed to understand what's going on, a close look
into the OpenSSL source would also be indicated.
Cheers
JÃŒrgen
Hi,
Indeed a tough one it seems. Very impressive. From your part.
Make test for openssl crashes hercules 3.07.
3.11 and 3.12 produce the error from Paul (ciphertext mismatch).
4.00 hyperion does not produce an error at all!This sounds very
strange. Maybe I am doing something wrong?
Regards,
Gert
Verzonden van Yahoo Mail voor iPhone <https://yho.com/footer0>
Hi Paul, Gert
Well, the below was once again too optimistic, it didn't stand
my plausibility checks .
This forced me to dive in even deeper. In the meantime I know
the "IEEE Standard for Cryptographic Protection of Data on
Block-Oriented Storage Devices (1619-2007)" by heart, in fact
I can sing to its lyrics. This stuff really has the potential
to drive me insane...
Most annoyingly, it turned out that one of my very first tests
after Paul reported the problem targeted the correct
algorithm, but I made a mistake implementing it, which led me
to completely rule it out from then on. So it was necessary to
go through the full theory, only to realize that I already was
on the correct path in the very beginning . At least I can
now say I'm sure doing it correctly as opposed to only
assuming it in the first place .
Now I'll go back to dyncrypt, implement my findings and go
again through my tests... this will still need a few days.
Cheers
JÃŒrgen
Hi Paul, Gert
just letting you know: Problem solved (hopefully).
I'll now do some plausibility checks to be as confident as
possible that things on the XTS side do work now as expected.
Paul's OpenSSL tests will then hopefully work cleanly too...
Additionally I'll go over the KIMD GHASH function to verify
whether this one is working correctly or is broken too. If
necessary it will get the same fix applied as KM/PCC now have
for XTS.
Given my current time constraints these activities will
probably take some additional two or three days. I'll publish
a patch once I'm done with this (currently it's some 200 lines
of code changed in dyncrypt.c, which I consider a major
change, although a big part of it is the precomputed exp_table).
Cheers
JÃŒrgen

[Truda [e-mail] [hercules-390]]

Hello,

sorry crossposted. I will try your suggestions tonight but for now I
have to go out.

Post by Truda ***@yahoo.com [hercules-390]
Hello,
I'm getting some more weird results (see below). I propose you don't
draw any conclusions from my unlogical testing. I will try to do it a
bit more properly tonight and report back to you tomorrow morning.
For your information all my Hercules's (Herculeses?) are built with
the same settings option -O2 and -march=native
If this might influence the result please let me know what settings to
use with compile time.
compile of hercules is on debian with gcc 5.2.1 but I could also do it
on CentOS7 or Fedora 23 server if required (=if the version of gcc
when compiling hercules might influence the result).
-------------
-------------
in Debian
Linux s390xDB 3.16.0-4-s390x #1 SMP Debian 3.16.7-ckt20-1+deb8u4
(2016-02-29) s390x GNU/Linux
gcc (Debian 4.9.2-10) 4.9.2

Post by ***@id.ethz.ch [hercules-390]

---------------------------------------------------------------------------------------
Testing cipher AES-128-XTS(encrypt/decrypt)
Key
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
IV
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Ciphertext
0000 91 7c f6 9e bd 68 b2 ec 9b 9f e9 a3 ea dd a6 92
0010 cd 43 d2 f5 95 98 ed 85 8c 02 c2 65 2f bf 92 2e
Makefile:159: recipe for target 'test_evp' failed
make[1]: Leaving directory '/home/gert/source/openssl-1.0.2g/test'
Makefile:460: recipe for target 'tests' failed

----------------------------------------------------------------------------------
------------------------------------------------------------------------------------

Post by ***@id.ethz.ch [hercules-390]

Testing cipher AES-128-XTS(encrypt/decrypt)
Key
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
IV
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Ciphertext
0000 91 7c f6 9e bd 68 b2 ec 9b 9f e9 a3 ea dd a6 92
0010 cd 43 d2 f5 95 98 ed 85 8c 02 c2 65 2f bf 92 2e
Testing cipher AES-128-XTS(encrypt/decrypt)
Key

-------------------------------------------------------------------------------------------

Post by ***@id.ethz.ch [hercules-390]
Hi Gert
That's an interesting observation.
I currently don't know, under which conditions (if at all) OpenSSL
uses the cryptographic instructions, as I never looked into this. If
it behaves as a good citizen it issues the query function provided by
each of the instructions during initialization and from then on uses
the cryptographic instructions for the functions found to
be available and its own code for those functions not
being available. Clearly, one can assume that "its own code" will
work correctly, or, at least, deliver the expected results when
running the test suites. So, one reason for the behavior you are
observing can be that OpenSSL doesn't use the defective instructions
during your test run on Hyperion.
On the Spinhawk (Hercules 3.x) side of things the features activated
in featxxx.h (xxx being the archmode) decide, which function codes
will be reported available by the query functions, once dyncrypt is
loaded.
On the Hyperion side in addition to the feature activation in
featxxx.h there is the dynamic situation given by the archlvl
command, with the initial defaults determined in archlvl.c. The
dyncrypt module uses both: At compile time it honors the definitions
given by featxxx.h and at run time it cross checks the settings given
by archlvl.
So, it would be interesting to see the output of the following two
commands when the system you are using for your tests is running on
archlvl (without arguments)
archlvl query all
In addition, it would be interesting to see the featxxx.h used for
building the architecture shown by the first archlvl command.
Maybe we can draw some conclusions from this. On the other hand, the
results from Paul's and your testings with my upcoming patch will
probably bring more clarity. And, yes, if this still brings not the
level of insight needed to understand what's going on, a close look
into the OpenSSL source would also be indicated.
Cheers
JÃŒrgen
Hi,
Indeed a tough one it seems. Very impressive. From your part.
Make test for openssl crashes hercules 3.07.
3.11 and 3.12 produce the error from Paul (ciphertext mismatch).
4.00 hyperion does not produce an error at all!This sounds very
strange. Maybe I am doing something wrong?
Regards,
Gert
Verzonden van Yahoo Mail voor iPhone <https://yho.com/footer0>
Hi Paul, Gert
Well, the below was once again too optimistic, it didn't
stand my plausibility checks .
This forced me to dive in even deeper. In the meantime I know
the "IEEE Standard for Cryptographic Protection of Data on
Block-Oriented Storage Devices (1619-2007)" by heart, in fact
I can sing to its lyrics. This stuff really has the potential
to drive me insane...
Most annoyingly, it turned out that one of my very first
tests after Paul reported the problem targeted the correct
algorithm, but I made a mistake implementing it, which led me
to completely rule it out from then on. So it was necessary
to go through the full theory, only to realize that I already
was on the correct path in the very beginning . At least I
can now say I'm sure doing it correctly as opposed to only
assuming it in the first place .
Now I'll go back to dyncrypt, implement my findings and go
again through my tests... this will still need a few days.
Cheers
JÃŒrgen
Hi Paul, Gert
just letting you know: Problem solved (hopefully).
I'll now do some plausibility checks to be as confident as
possible that things on the XTS side do work now as expected.
Paul's OpenSSL tests will then hopefully work cleanly too...
Additionally I'll go over the KIMD GHASH function to verify
whether this one is working correctly or is broken too. If
necessary it will get the same fix applied as KM/PCC now have
for XTS.
Given my current time constraints these activities will
probably take some additional two or three days. I'll publish
a patch once I'm done with this (currently it's some 200
lines of code changed in dyncrypt.c, which I consider a major
change, although a big part of it is the precomputed exp_table).
Cheers
JÃŒrgen

['John P. Hartmann' [e-mail] [hercules-390]]

That will be fine. I particularly like -O2.

The cryptographic "instructions" are in the z/Architecture; no
underlying x86/amd64 hardware is required.

Post by Truda ***@yahoo.com [hercules-390]
-O2 and -march=native
If this might influence the result please let me know what settings to
use with compile time.

[Truda [e-mail] [hercules-390]]

Yes me too

It turns out often to be the fastest code and even more importantly no
segfaults!

That will be fine. I particularly like -O2.
The cryptographic "instructions" are in the z/Architecture; no
underlying x86/amd64 hardware is required.

Post by Truda ***@yahoo.com [hercules-390]
-O2 and -march=native
If this might influence the result please let me know what settings to
use with compile time.