build & test issues compiling under raspbian

[glfejer]

Similar to issue 133 in the ecdaa repository xaptum/ecdaa#133 , I had to change includes from
<amcl/...>
to
<amcl/include/...>

Ctest failed 3 tests:

4: Test command: /home/pi/git/xtt/build/testBin/integration_test "3"
4: Test timeout computed to be: 1500
4: Suite Spec: 3
4: Passes all of client step 1
4: Condition 'server->rc == XTT_RETURN_WANT_WRITE' failed
4: 	in file: '/home/pi/git/xtt/test/integration_test.c'
4: 	in function: 'server_step_one'
4: 	at line: 79
4: exiting
4/8 Test #4: integration_test_3 ...............***Failed    0.03 sec
test 5
    Start 5: integration_test_4

5: Test command: /home/pi/git/xtt/build/testBin/integration_test "4"
5: Test timeout computed to be: 1500
5: Suite Spec: 4
5: Passes all of client step 1
5: Condition 'server->rc == XTT_RETURN_WANT_WRITE' failed
5: 	in file: '/home/pi/git/xtt/test/integration_test.c'
5: 	in function: 'server_step_one'
5: 	at line: 79
5: exiting
5/8 Test #5: integration_test_4 ...............***Failed    0.03 sec

and

    Start 8: cpp_test

8: Test command: /home/pi/git/xtt/build/testBin/cpp_test
8: Test timeout computed to be: 1500
8: ==4187==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
8/8 Test #8: cpp_test .........................***Failed    0.03 sec

[drbild]

The AMCL issues will be resolved by fixing the AMCL install, as per the issue in ecdaa.

@zanebeckwith Should have a better idea about the tests failing.

[zanebeckwith]

Hmm, I can't recreate the failing tests when running on my 64bit Ubuntu laptop. Can you describe your build setup more?

Also, what's the platform you're on? It's interesting that the two failing integration_test instances are the ones that use AES256GCM (the integration_test is repeated 4 times, to use the four different "suite_specs", which define the particular choices of cryptographic algorithms). That means, if you didn't see integration_test_1 or integration_test_2 fail, that the CHACHA20POLY1305 tests succeeded

[zanebeckwith]

Ah, actually, I think I found the issue: https://doc.libsodium.org/secret-key_cryptography/aead/aes-256-gcm

Libsodium (which provided the implementation of the encryption primitives for xtt) simply doesn't support AES256GCM on platforms that don't have hardware accelerations for AES. While the ARM chips in the RasPi may or may not have support for aesni and pclmul (I don't know whether libsodium requires exactly aesni or can use ARM's variant, or what), but they definitely don't have SSE3, which is Intel-specific

The step where the integration_test is failing is the first place where the encryption is actually used, so it's probably the libsodium function returning an error because the requested crypto primitive can't be used

This means I need to add a build flag to disable compilation of the AES suite_specs. Because libsodium provides a helper function to check availability of the AES acceleration, we can have a compile-time check "if you're trying to build AES suite_specs, but you don't have AES hardware acceleration, fail the build"

[drbild]

Interesting. I haven't seen these issues on the router card or the ARM gateways that I've compiled for, but I also haven't run the test suites. Does this imply that the AES ciphersuite would fail on those devices?

[zanebeckwith]

Does this imply that the AES ciphersuite would fail on those devices

That's my assumption. I would love to check that

Again, compiling in the AES stuff doesn't fail the build, and no errors will be seen until you actually try to use the AES stuff. So, if you're just using CHACHA, it probably never arises

It looks like enftun uses X25519_LRSW_ECDSAP256_CHACHA20POLY1305_SHA512 by default (cf. line 124 in enftun/src/xtt.c)

[zanebeckwith]

Damn, I would love to have (maybe QEMU?) cross-platform tests of these crypto libraries running in CI, to try to catch crap like this. Someday...

[zanebeckwith]

@drbild do you have a router card that's already set up to be able to run the XTT handshake, to which you also have console access, where you could switch the config option to use an AES suite_spec?

[drbild]

The suitespec is hardcoded currently (not actually exposed as a config option), so I'd need to recompile enftun.

[zanebeckwith]

Ah, I see.

Ok, I'll add the build flag to allow disabling AES, when I get a few spare cycles (shouldn't take long, but probably won't be today).

I'll also try to boot a router card, change the suite_spec, and confirm that it does fail when attempting AES