- Added support for using libsodium for encryption rather than OpenSSL
- Removed AES-GCM tests with keys shorter than 256; libsodium only supports 256
- Added a build with libsodium to the CI matrix
Signed-off-by: Andrew Simpson <andy@aiusepsi.co.uk>
steven@ edited and rebased:
- integrated with new USE_CRYPTO/USE_CRYPTO25519 options in CMake/meson
- separated using libsodium for ed25519/curve25519 and AES/SHA256.
- ensured libsodium simple crypto tests run on all builders instead of
a single isolated builder.
- prevented building with -DUSE_CRYPTO=libsodium for non-x86 hardware,
as libsodium's AES implementation depends on AES-NI. it is still
possible to configure with -DUSE_CRYPTO25519=libsodium on arbitrary
hardware targets.
Fixes#88.
Signed-off-by: Steven Noonan <steven@valvesoftware.com>
We're using AES-GCM now.
Also:
- Tests now check the return value of CCrypto::PerformKeyExchange
- Fix some MSVC compiler warnings in tests
- Delete some more dead code
The basic change is that the base class will no longer store the raw key bytes in a buffer. Instead, we have virtual functions to get and set the raw bytes, with the storage being specific to the key type and crypto provider.
The main purpose of these changes is to make it easier to get 25519 working in OpenSSL and bcrypt.
NOTE: This broke libsodium support. We could fix it. But I'm not sure we want to support libsodium or not. If we support it, we should support it for all crypto needs, including per-packet encryption. And that means accepting the 12-byte IV and 16-byte tag. If that's what TLS does, there is some potential advantage to doing exactly what TLS does. At the same time, I don't add 12 bytes to every packet lightly.
Reorganize 25519 files, made a placeholder for OpenSSL with a bunch of FIXMEs. (Working on issue #46.)
Also, deleted RSA key support, since we don't need it for thiis project.
Also add a EVP_CIPHER_CTX_safe structure to manage allocating and cleaning up
EVP_CIPHER_CTX struct. IN older versions of OpenSSL you could just declare an
EVP_CIPHER_CTX struct on the stack. Now you have to go through a generic
allocation mechanism!? SO we're going to be doing a heap allocation for every
single packet. That is....terrible. We should try to find a way around this,
even if it's gross, because doing a heap allocation per packet is not acceptible.
Fletcher Dunn
Andrew Simpson
Steven Noonan