search

build-trust / ockam

Orchestrate end-to-end encryption, cryptographic identities, mutual authentication, and authorization policies between distributed applications – at massive scale.
https://ockam.io
Apache License 2.0
4.47k stars 562 forks source link

Default crypto library is `aws-lc` #8608

Open davide-baldo opened 1 week ago

davide-baldo commented 1 week ago

The current default crypto library is aes-gcm since it has a broader compatibility without any additional dependencies, but it's also slower and different from release builds which are built using aws-lc. The default features in command should switch to aws-lc, and we should print a warning when compiling on a non-supported platform (linux/mac amd64/aarch64), advising the user of the possibility of using rust-crypto or adding the extra dependencies. Also, the CI will be using the default features rather than manually specifying them in multiple locations.

SanjoDeundiak commented 1 week ago

Ideal case: we use aws-lc by default and automatically switch to `rust-crypto if it's available. Not sure that's possible

davide-baldo commented 1 week ago

Do you mean switching to rust-crypto automatically when aws-lc dependencies are not available?

SanjoDeundiak commented 1 week ago

Yes

davide-baldo commented 1 week ago

I don't think it would be ideal, having fixed dependencies is a plus for me. Introducing extra complexity and brittleness to better handle uncommon builds (non linux/macos, non amd64/aarch64) is not a worth tradeoff in my view. In platforms where aws-lc is not fully supported, the user would still have the option of introducing the extra dependencies to build the bindings, and retaining the performance benefits of aws-lc. If we automatically ""downgrade"" the dependency, the user might never know this was an option, or even worse, it may happen to us after a CI upgrade and we might not even notice it.