Open glfejer opened 4 years ago
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.
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
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"
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?
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
)
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...
@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?
The suitespec is hardcoded currently (not actually exposed as a config option), so I'd need to recompile enftun
.
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
Similar to issue 133 in the ecdaa repository https://github.com/xaptum/ecdaa/issues/133 , I had to change includes from <amcl/...> to <amcl/include/...>
Ctest failed 3 tests:
and