if possible - otherwise document why not.

Edits; Markdown fix.

In the process of trying to get the standard benchmarks to work according to the readme. At this point I am at the "Running tests and benchmarks" part of the readme.
Linuxmint 17.3 (Rosa) with GCC/G++ 5.5 has the following output when calling make:

make -C crypto_kem/frodo640-cshake/opt libpqm4.a
make[1]: Entering directory '/home/nevy/Research/pqm4/crypto_kem/frodo640-cshake/opt'
arm-none-eabi-gcc -I/home/nevy/Research/pqm4/common -Wall -Wextra -O3 -mthumb -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -c -o frodo640.o frodo640.c
In file included from frodo640.c:30:0:
kem.c: In function 'crypto_kem_dec':
kem.c:129:5: error: 'for' loop initial declarations are only allowed in C99 mode
     for (int i = 0; i < PARAMS_N*PARAMS_NBAR; i++) BBp[i] = BBp[i] & ((1 << PARAMS_LOGQ)-1);
     ^
kem.c:129:5: note: use option -std=c99 or -std=gnu99 to compile your code
In file included from frodo640.c:32:0:
frodo_macrify.c: In function 'frodo_add':
frodo_macrify.c:222:5: error: 'for' loop initial declarations are only allowed in C99 mode
     for (int i = 0; i < (PARAMS_NBAR*PARAMS_NBAR); i++) {
     ^
frodo_macrify.c: In function 'frodo_sub':
frodo_macrify.c:233:5: error: 'for' loop initial declarations are only allowed in C99 mode
     for (int i = 0; i < (PARAMS_NBAR*PARAMS_NBAR); i++) {
     ^
make[1]: *** [frodo640.o] Error 1
make[1]: Leaving directory '/home/nevy/Research/pqm4/crypto_kem/frodo640-cshake/opt'
make: *** [crypto_kem/frodo640-cshake/opt] Error 2

Which is supposedly remedied by:
make CFLAGS="-std=gnu99"
Which results in:

...
newhope_asm.S:734: Error: attempt to use an ARM instruction on a Thumb-only processor -- 'pop {r0-r12,pc}'
make[1]: *** [newhope_asm.o] Error 1
rm kem.o cpapke.o
make[1]: Leaving directory '/home/nevy/Research/pqm4/crypto_kem/newhope1024cca/m4'
make: *** [crypto_kem/newhope1024cca/m4] Error 2

On the first run.

Then we run make again, and then make CFLAGS="-std=gnu99" again to get

...
make[1]: Leaving directory '/home/nevy/Research/pqm4/crypto_sign/sphincs-shake256-128s/ref'
make -C crypto_sign/sphincs-shake256-128s/ref libpqhost.a
make[1]: Entering directory '/home/nevy/Research/pqm4/crypto_sign/sphincs-shake256-128s/ref'
gcc -I/home/nevy/Research/pqm4/common -Wall -Wextra -O3 -c -o hash_shake256_host.o hash_shake256.c
gcc -I/home/nevy/Research/pqm4/common -Wall -Wextra -O3 -c -o hash_address_host.o hash_address.c
gcc -I/home/nevy/Research/pqm4/common -Wall -Wextra -O3 -c -o wots_host.o wots.c
gcc -I/home/nevy/Research/pqm4/common -Wall -Wextra -O3 -c -o utils_host.o utils.c
gcc -I/home/nevy/Research/pqm4/common -Wall -Wextra -O3 -c -o fors_host.o fors.c
gcc -I/home/nevy/Research/pqm4/common -Wall -Wextra -O3 -c -o sign_host.o sign.c
gcc-ar rcs libpqhost.a hash_shake256_host.o hash_address_host.o wots_host.o utils_host.o fors_host.o sign_host.o
make[1]: Leaving directory '/home/nevy/Research/pqm4/crypto_sign/sphincs-shake256-128s/ref'
mkdir -p obj 
arm-none-eabi-gcc -std=gnu99 -o obj/stm32f4_wrapper.o -c common/stm32f4_wrapper.c
In file included from common/stm32f4_wrapper.c:1:0:
common/stm32wrapper.h:4:34: fatal error: libopencm3/stm32/rcc.h: No such file or directory
 #include <libopencm3/stm32/rcc.h>
                                  ^
compilation terminated.
make: *** [obj/stm32f4_wrapper.o] Error 1

After which a regular make results in:

...
arm-none-eabi-gcc -O3 -Wall -Wextra -Wimplicit-function-declaration -Wredundant-decls -Wmissing-prototypes -Wstrict-prototypes -Wundef -Wshadow -I./libopencm3/include -fno-common -mthumb -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -std=gnu99 -MD -DSTM32F4 -std=gnu99 -o obj/stm32f4_wrapper.o -c common/stm32f4_wrapper.c
In file included from ./libopencm3/include/libopencm3/cm3/nvic.h:133:0,
                 from common/stm32wrapper.h:7,
                 from common/stm32f4_wrapper.c:1:
./libopencm3/include/libopencm3/dispatch/nvic.h:14:39: fatal error: libopencm3/stm32/f4/nvic.h: No such file or directory
 # include <libopencm3/stm32/f4/nvic.h>
                                       ^
compilation terminated.
make: *** [obj/stm32f4_wrapper.o] Error 1

At which point alternating both method does not change anything anymore.

Calling make clean will revert the situation to the way it was at the beginning of this message.

Note that I originally updated from GCC 4.8 (Which showed similar behaviour) to GCC 5.5 because I read that gnu11 is the new default for GCC 5.5, which would make messing with the CFLAG unessecary. Sadly, GCC 5.5 did not deliver what I thought it would.

It looks like some libraries need the "-std=gnu99" flag but somehow either something else gets misconfigured because of it, or it was misconfigured from the start. Can someone help me debug this? I am not an expert when it comes to Makefiles, so it might as well be I just forgot something.

if possible - otherwise document why not.

Round5 should meet your inclusion requirements -- having a version at Category 3 and being in the NIST competition (NIST has approved the merger of Round2 and Hila5 teams).

Code at https://github.com/round5/r5nd_tiny should be easy enough to incorporate to your testing framework. I actually used your implementations in benchmarking (thanks!) so APIs are equivalent. I simply had a different vendor board (with different flashing and serial comms mechanisms) so can't integrate it directly.

Please see the paper "Shorter Messages and Faster Post-Quantum Encryption with Round5 on Cortex M" at https://round5.org/doc/r5m4text.pdf for more information. It should pop up in IACR ePrint shortly.

Cheers,

• markku

Some people showed interest in bundling more than one scheme from pqm4 together which means that we would need to namespace everything.

Since we have this in https://github.com/PQClean/PQClean/ anyway it should be straightforward to just keep it.

Any strong opinions?

I made a (now closed) issue(#6 ) on this earlier but the newly added qTesla128 also has some issues. Now the following two parts have issues:

• qTesla128
• Frodo640

Most errors amount to for-loops with internal variable declarations, but one issue in qTesla128 shows the following:

fixed_llrint.c: In function ‘llrint_fixed’:
fixed_llrint.c:77:24: error: ‘__int32_t’ undeclared (first use in this function)
           if ((i0 & ~((__int32_t)1 << 31)) == 0)

Which is an unfamiliar issue to me. I replaced it with int32_t and that seems to hold up. I verified both the adjusted qTesla128 and Frodo640 code using test.py.
I have, however, no permission to push my changes to the branch I created locally. What would be the best way to provide my code? (My aim was to push it to a branch and create a pull request)

Proof of successful tests:

Consider the following MWE:

#include <stdio.h>
#include "aes.h"
#include "api.h"
#include "hal.h"

int crypto_kem_keypair(unsigned char *pk, unsigned char *sk)
{
    (void)pk;
    (void)sk;

    uint8_t key[20] = {0};
    aes128ctx ctx;
    char buf[128];

    sprintf(buf, "key: %p, key+1: %p, key+2: %p", key, key+1, key+2);
    hal_send_str(buf);

    aes128_keyexp(&ctx, key);
    hal_send_str("This works fine.");

    aes128_keyexp(&ctx, key+1);
    hal_send_str("But this is not printed anymore.");

    aes128_keyexp(&ctx, key+2);
    hal_send_str("This would also not have been okay.");


    return 0;
}

int crypto_kem_enc(unsigned char *ct, unsigned char *ss, const unsigned char *pk)
{
    (void)ct;
    (void)ss;
    (void)pk;
    return 0;
}

int crypto_kem_dec(unsigned char *ss, const unsigned char *ct, const unsigned char *sk)
{
    (void)ss;
    (void)ct;
    (void)sk;
    return 0;
}

Calling the M4-assembly AES key expansion with a key that is not word-aligned results in a fault. This is because it uses the ldm and stm instructions, which require the pointer to be word-aligned.

According to StackOverflow the only proper solution is to copy the value to a local variable that will always be word-aligned.

We should consider changing the assembly implementation such that it can handle unaligned pointers or hide this copying in mupq/common/aes.c.

This behavior was observed when dealing with NTRU Prime. (More specifically: ntrulpr761 and ntrulpr857).

if possible - otherwise document why not.

First to confirm that flashign works, and to get an idea of the speed at which a test runs, I ran sudo python3 test.py kyber768
Which outputs:

Flashing bin/crypto_kem_kyber768_ref_test.bin..
Flashed, now running tests...
  .. found output marker..
Testing if tests were successful..
passed.
Flashing bin/crypto_kem_kyber768_m4_test.bin..
Flashed, now running tests...
timed out while waiting for the markers
Flashing bin/crypto_kem_kyber768_m4_test.bin..
Flashed, now running tests...
  .. found output marker..
Testing if tests were successful..
passed.

Having an idea about the speed, I decided to run sudo python3 testvectors.py kyber768
The first time it ran for over 10 minutes and then I decided it had probably hung and interrupted it:

This script flashes the test vector binaries onto the board, and then
 writes the resulting output to the testvectors directory. It then
 checks if these are internally consistent and match the test vectors
 when running the reference code locally.
Flashing bin/crypto_kem_kyber768_m4_testvectors.bin..
Flashed, now computing test vectors..
^CTraceback (most recent call last):
  File "testvectors.py", line 54, in <module>
    x = dev.read()
  File "/home/nevernown/.local/lib/python3.5/site-packages/serial/serialposix.py", line 483, in read
    ready, _, _ = select.select([self.fd, self.pipe_abort_read_r], [], [], timeout.time_left())
KeyboardInterrupt

Sure enough the second run almost immediately got results, which makes my suspicion grow that it indeed hung:

This script flashes the test vector binaries onto the board, and then
 writes the resulting output to the testvectors directory. It then
 checks if these are internally consistent and match the test vectors
 when running the reference code locally.
Flashing bin/crypto_kem_kyber768_m4_testvectors.bin..
Flashed, now computing test vectors..
  .. found output marker..
  .. wrote test vectors!
Flashing bin/crypto_kem_kyber768_ref_testvectors.bin..
Flashed, now computing test vectors..
  .. found output marker..

But this run stops after finding the second output marker (It's been stuck at the above output for about 6 minutes now).

My question is twofold: 1. Did it really hang? 2. How can I have more verbose output on what is going on?

The current ReadMe file states “The benchmarking scripts used in pqm4 require Python >= 3.6.”
However, the mupq.py file has the line
subprocess.check_output(args, *, stdin=None, stderr=None, shell=False, cwd=None, encoding=None, errors=None, universal_newlines=None, timeout=None, text=None)
The “text” option was only added in Python 3.7 (“New in version 3.7: text was added as a more readable alias for universal_newlines.”).
A solution is either requiring Python >= 3.7 or using the universal_newlines option instead.

Hello,

Is there an implementation for _mm_aesenclast_si128 instruction? The instruction is part of AES(Advanced Encryption Standard) instruction set.

Lior

This will break mupq+pqm4 and should be ported.
PQClean/PQClean#175

if possible - otherwise document why not.

I'm not sure if this is intended, but this struct hides some fields:

I found this cause I copy-pasted into my Rust code, and got the following error:

error[E0063]: missing fields `ahb_frequency`, `pllr`, `power_save` in initializer of `libopencm3_sys::rcc_clock_scale`

Feel free to close this immediately as a "wontfix" if you don't care about these things.

if possible - otherwise document why not.

if possible - otherwise document why not.

if possible - otherwise document why not.

The verify function in verify.c in the NewHope implementation compares two arrays for equality in constant time and should return (r = 0) if the byte arrays are equal and return (r = 1) otherwise. On executing a decapsulation with a faulty ciphertext, it should return r = 1, however I think it is returning r = 0xFF. Due to this, the cmov function subsequently executed during decapsulation in kem.c does not perform correct swapping between the bytes arrays x and r. I think it can be fixed by replacing line 25 in verify.c (i.e)

r = (-(int64_t)r) >> 63

with

r = (-r) >> 63; or r = ((uint64_t)(-(int64_t)r)) >> 63;

I do believe that the most recent implementation of NewHope does not use this verify function though the verify function is defined in verify.c, but this function has been utilized in previous implementations of NewHope in the pqm4 library.

A recent PR in PQClean (PQClean/PQClean#198) adds

void aes128_ctx_release(aes128ctx *r);
void aes192_ctx_release(aes192ctx *r);
void aes256_ctx_release(aes256ctx *r);

For mupq/pqm4 this should be an empty function.

if possible - otherwise document why not.

if possible - otherwise document why not.

When I type the "make" command, some errors are shown as follows:
Makefile:13: recipe for target 'frodo640.o' failed
make[1]: *** [frodo640.o] Error 1
make[1]: Leaving directory '/home/abc/Documents/pqm4/crypto_kem/frodo640-cshake/opt'
Makefile:84: recipe for target 'crypto_kem/frodo640-cshake/opt' failed
make: *** [crypto_kem/frodo640-cshake/opt] Error 2
What should I do to solve them?

if possible - otherwise document why not.

if possible - otherwise document why not.

if possible - otherwise document why not.

if possible - otherwise document why not.

if possible - otherwise document why not.

I've noticed that the CCAKEM variant of Round5 that PQM4 implemented is probably not compatible with CCA KEM contained in the Round5 specification (or the one in r5embed).

Apparently PQM4 enabled Fujisaki-Okamoto for the "epheremeral KEM" parameter sets rather than using the actual CCA parameter sets (i.e. "PKE" parameter sets). I recall suggesting stripping away the DEM from the PKE parameter sets -- as is done in r5embed -- but this suggestion was apparently not followed. On code level the correct CCA parameters are selected by using R5ND_3PKE_5d insted of R5ND_3KEM_5d etc. In the Round5 specification "PKE" is a essentially a synonym for CCA.

The main difference between CPA and CCA parameter sets at given security level is in failure probability; it is now higher than it should be for CCA. The CPA KEM parameters have little bit shorter message and key lengths than the actual CCA KEM variants.

I'm deeply sorry to not have checked before if the variant used in PQM4 was sensible; I was given opportunity to check the pull request. However we did ask the PQM4 to adopt at least some variants of Round5 as they were proposed to NIST.

Work has been (slowly) progressing on the spec and we will be rolling out official CCA KEM out soonish. Preliminary plans are also to drop the _0d ring variants -- and there are some other modifications as well. So I'm fine if you choose to wait until the CCA KEM thing is officially proposed to NIST as none of this was ever compliant with the proposal anyway. Of course the SNEIK stuff is currently just a placeholder in case NIST decides to standardize a lightweight XOF after all (the SNEIK algorithm itself is out of the competition).

If the implementation you're adding is such a host-side-only reference implementation, place a file called .m4ignore in the subdirectory containing the implementation. In that case the Makefile is not required to contain the libpqm4 target.

I am currently adjusting a project using __uint128_t in the reference version, and the functionality mentioned would be beneficial. The compiler gets angry when compiling the ref for the m4. However, the make script seems to still want the libpqm4.a target.

As in our recent paper, it would be nice to have some profiling information on how much time is spent in hashing and randombytes.
This should also give an intuition how the schemes sample randomness.

We implemented this by adding/subtracting the current cycle count to a global variable when entering/leaving the respective function. This should be done only for profiling, but not in the benchmarks since it can have a huge performance impact. It would be nice to port that to PQM4.

In case we want to use systick for this, then we will run into the problem that if the overflow occurs within one of the profiled functions the cycle counts are useless. In our paper experiments, we just detected this case and ran it several times until we had no overflow there - this won't work for SPHINCS.

Schemes like Kindi use malloc/calloc extensively.
While this still works on the M4, the stack usage benchmarks do no longer represent the entire memory consumption of the implementation.
The cleanest solution would be to refactor those implementations not to use malloc etc.
Any other suggestions?

if possible - otherwise document why not.

When running sudo python3 test.py the following messages repeat.

Flashing bin/crypto_kem_kindi256342_ref_test.bin..
Flashed, now running tests...
timed out while waiting for the markers

Running st-flash write bin/crypto_kem_newhope1024cca_ref_test.bin 0x8000000 shows that:

st-flash: error while loading shared libraries: libstlink.so.1: cannot open shared object file: No such file or directory

Which in my case could be fixed using sudo ldconfig after which both the manual flash and test.py run as expected.

The problem here is that test.py should not give a go to the test, since nothing got flashed to the board and as such no output will be generated.

if possible - otherwise document why not.