There is a bug in Hercules 3.12 and below as well as Hyperion. Here is the fix information from the Hercules-390 yahoo group posted yesterday: ************ 2.1 Defects in PCC and KM instructions -- Patch available for testing Tue Apr 26, 2016 1:33 pm (PDT) . Posted by: juergen.winkelmann 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 ************** If you need to get around this without doing the patch, change your Hercules configuration to use ARCHMODE ESAME instead of ARCHMODE Z/Arch. This disables the cryptography instruction emulation and uses software emulation (at a serious performance cost). Many thanks to Jürgen who has been pounding on this bug ever since I noticed it. Regards, Paul -----Original Message----- From: Andy Polyakov via RT [mailto:r...@openssl.org] Sent: Wednesday, April 27, 2016 8:04 AM To: p...@trifox.com Cc: openssl-dev@openssl.org Subject: Re: [openssl-dev] [openssl.org #4500] Testing cipher AES-128-XTS(encrypt/decrypt) failure > Hi Paul, It doesn't seem unlike that OP is not subscribed, so he won't see responses send to <openssl-dev> alone. To ensure delivery and or reply to <r...@openssl.org>. > I have not checked the code for the test, but I do get the expected > values with my little test program. But what is your host, Massimiliano? Is it also Hercules, and if so which version? As Paul indicated later, it might be Hercules bug, and it would be helpful if you can tell what's your version. One has to keep in mind that not all version implement XTS support... > Here's the dump (key and iv set to 0 > - block size is 32 bytes (i.e. 2 * 128bit units)): > > AES XTS Encrypt: > ---------------- > > Plaintext (32): > 0020 - <SPACES/NULS> > > Ciphertext 32: > 0000 - 91 7c f6 9e bd 68 b2 ec-9b 9f e9 a3 ea dd a6 92 > .|...h.......... > 0010 - cd 43 d2 f5 95 98 ed 85-8c 02 c2 65 2f bf 92 2e > .C.........e/... > > AES XTS Decrypt: > ---------------- > > Encrypted Data: > 0000 - 91 7c f6 9e bd 68 b2 ec-9b 9f e9 a3 ea dd a6 92 > .|...h.......... > 0010 - cd 43 d2 f5 95 98 ed 85-8c 02 c2 65 2f bf 92 2e > .C.........e/... > > Decrypt Offset: 0 > Original Start: 0 > Throw Away: 0 > > Clear Text 32: > 0020 - <SPACES/NULS> > > My guess is that the second part of the key is not all zeros - this > would cause you to get the first part of the message encrypted > correctly and the second part not having the good values... this is > just my guess, of course. > > Cheers, > Max -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4500 Please log in as guest with password guest if prompted -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4500 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
