Is alternative crypto backend considered?

[pemensik]

I have attempted to create RPM package of this library. One issue has arisen with tsig and validate features using ring library. That library does not compile on some less common architectures like ppc64le and s390x, there is a bug on that: https://bugzilla.redhat.com/show_bug.cgi?id=1869980

It would help if crypto features could be fulfilled by some alternatives. Were they considered already?

[partim]

I had considered alternative backends for the sign module but not for tsig and validate (because ring had everything I needed). But I agree, those two should also be generic over the crypto backend.

How urgent is support for those alternative platforms for you? I would prefer not to delay the 0.8 release further with additional features but obviously, this is a breaking change, so would then require 0.9.

[pemensik]

There is no hurry, waiting until version 0.9 is completely fine to me

[pinkforest]

aws-lc-rs is API compat to ring. Also happy to contribute switching - or providing alternative - to pure rust backend that also has several intrinistics and asm inlines where needed in given supported platforms.

[partim]

API compatibility is less of an issue – we need to build a means to select the crypto backend, anyway.

DNSSEC signing is on our list for later this year. This will include tackling this issue.

[pinkforest]

When you do choose to do so - Please consider doing it via cfg(crate_name_backend = "..") as overrides

There exists now compiler support for validating manifested custom cfg's if MSRV >= 1.77: https://blog.rust-lang.org/2024/05/06/check-cfg.html

We did it for curve25519_dalek backends as overrides over auto-selection at: dalek-cryptography/curve25519-dalek#414 + it's build.rs we also support runtime auto-selection for AVX2 without extra work with --cfg / target defs unless one is overriding auto-selected / detected backend.