Failing tests for sikep434 and sikep751; testvector mismatch for sikep503 and sikep610

[mkannwischer]

Dear Hwajeong, Dear Mila, Dear Amir, Dear Reza,

Thank you very much for posting your new SIKE code and congratulations on the new speed records. We tried integrating your code into pqm4 and ran into some issues for which we would appreciate your help. Your code is currently at https://github.com/mupq/pqm4/tree/sike-m4

So you should be able to clone it using

git clone --recurse-submodules https://github.com/mupq/pqm4
cd pqm4 
git checkout --recurse-submodules sike-m4

For sikep434 and sikep751 the tests seem to never terminate:

./test.py sikep434
./test.py sikep751

For sikep503 and sikep610 the tests work, but the testvectors generated by the implementations don't seem to match the ones from the opt implementation submitted to NIST which was merged in https://github.com/mupq/mupq/pull/6. Should these implementations be compatible?

./testvectors.py sikep503
./testvectors.py sikep610

I've attached the testvectors for both parameter sets: 610_m4.txt 503_m4.txt 503_host.txt 610_host.txt

You can see that for sikep503 the reference implementation derives the shared secret 456040d3586c77edeb2e1dab07a8a1bc53c8e781f30fa235 whereas your's derives 768512236b97d10dd7080daaa190bf4d. Similiar for sikep610, the reference gives e6853252159c649a0017a5c0bd476fe7a0d12828232b963f and your's gives e0b62638baa5604ce21c3965e9eefc1c9502ba8e08e124b6

I'm unsure if this means that the opt implementation we have is outdated or with we screwed something up when integrating your code.

We would be very grateful for any insight you can provide. If we have any updates, we will let you know here.

Cheers, Ko and Matthias for pqm4 Team.

[mkannwischer]

I made one more observation: If I use the binaries you packaged in https://github.com/solowal/SIKE_M4/blob/master/SIKE_M4.tar.gz and flash crypto_kem_sikep434_m4_test.bin or crypto_kem_sikep751_m4_test.bin they do pass the tests. Once I run make clean && make, it breaks again.

[azarderakhsh]

Hi Matthias, I think there is a problem with your development environment. Have you corrected some GCC options? We run the code and it works fine in our board here.

We will check again to see what is going on.

Thanks Reza

On Wed, Apr 15, 2020 at 10:49 PM Matthias J. Kannwischer < notifications@github.com> wrote:

Dear Hwajeong, Dear Mila, Dear Amir, Dear Reza,

Thank you very much for posting your new SIKE code and congratulations on the new speed records. We tried integrating your code into pqm4 and ran into some issues for which we would appreciate your help. Your code is currently at https://github.com/mupq/pqm4/tree/sike-m4

So you should be able to clone it using

git clone --recurse-submodules https://github.com/mupq/pqm4 cd pqm4 git checkout --recurse-submodules sike-m4

For sikep434 and sikep751 the tests seem to never terminate:

./test.py sikep434 ./test.py sikep751

For sikep503 and sikep610 the tests work, but the testvectors generated by the implementations don't seem to match the ones from the opt implementation submitted to NIST https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/documents/round-2/submissions/SIKE-Round2.zip which was merged in mupq/mupq#6 https://github.com/mupq/mupq/pull/6. Should these implementations be compatible?

./testvectors.py sikep503 ./testvectors.py sikep610

I've attached the testvectors for both parameter sets: 610_m4.txt https://github.com/solowal/SIKE_M4/files/4484598/610_m4.txt 503_m4.txt https://github.com/solowal/SIKE_M4/files/4484600/503_m4.txt 503_host.txt https://github.com/solowal/SIKE_M4/files/4484601/503_host.txt 610_host.txt https://github.com/solowal/SIKE_M4/files/4484602/610_host.txt

You can see that for sikep503 the reference implementation derives the shared secret 456040d3586c77edeb2e1dab07a8a1bc53c8e781f30fa235 whereas your's derives 768512236b97d10dd7080daaa190bf4d. Similiar for sikep610, the reference gives e6853252159c649a0017a5c0bd476fe7a0d12828232b963f and your's gives e0b62638baa5604ce21c3965e9eefc1c9502ba8e08e124b6

I'm unsure if this means that the opt implementation we have is outdated or with we screwed something up when integrating your code.

We would be very grateful for any insight you can provide. If we have any updates, we will let you know here.

Cheers, Ko and Matthias for pqm4 Team.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/solowal/SIKE_M4/issues/3, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHXALMFA76KY7QONZOZQNZLRMZW35ANCNFSM4MJB452Q .

[Ko-]

Hi, I just wanted to mention that so far I've tried this with gcc 9.3.0, 8.3.0 and 5.4.1 on various machines, both in the current version of pqm4 and by directly taking the SIKE_M4.tar.gz package and using those files. The situation remains the same as what Matthias described. For sikep434, I traced the code from crypto_kem_keypair to EphemeralKeyGeneration_B to LADDER3PT to xDBLADD. There the code seems to hang in the first fp2sqr_mont, but if I add some print statements in there that don't really do anything, the code suddenly continues past that point until the first fp2mul_mont. I'm guessing now that maybe there's some implicit assumption somewhere on memory locations/offsets.

[Ko-]

This has been resolved over email. For pqm4 I've made the following changes to make everything work and match:

• Add __attribute__((naked)) to fpmul_mont and fpsqr_mont for sikep434 and sikep751.
• Change cshake256_simple back to shake256 for all parameter sets.
• Change CRYPTO_BYTES back to 24 for sikep503.