build & test issues compiling under raspbian about xtt HOT 9 OPEN

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.

from xtt.

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

from xtt.

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"

from xtt.

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?

from xtt.

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)

from xtt.

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...

from xtt.

@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?

from xtt.

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

from xtt.

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

from xtt.