Skip to content

Conversation

arckoor
Copy link

@arckoor arckoor commented Oct 10, 2025

Uses botan-rs (which wrapps the FFI of botan) to provide another crypto backend.

Some notes:

  • as an FFI wrapper, botan-rs can emit a lof of errors (mainly related to passing the wrong stuff through the interface), which is why there's a lot of ?s in the code. In practice almost none of these will ever happen, but ? feels cleaner to methan unwrap(). The only place that needs to unwrap is compute_digest.
  • this currently uses my forks of botan(-rs) (hence the draft), because I needed to add the ability to load a PKCS1 RSA public key. I'm reasonably sure I can get this PR'd into botan, but I'd like to make sure this PR can have success before I go adding new features to something as old as RSA.

@dsykes16
Copy link
Contributor

dsykes16 commented Oct 11, 2025

Disclosure: I'm not a maintainer, so my opinion doesn't reflect on this project.

That said, I don't see any mention of botan having undergone a security audit. It's also a C++ library, so comes with all the cross-compilation issues as aws-lc-rs (which has been audited and even offers FIPS-compliance). rust-crypto is native rust and many (all?) module have undergone security audits, admittedly some of them with findings indicating vulnerability to timing attacks.

What features/advantages does this bring that either rust-crypto or aws-lc-rs don't already provide? (e.g. faster, smaller compiled size, wasm compatibility, etc.)

EDIT:
While modesty is certainly a virtue, the Botan project would likely benefit from mentioning on their README that they've been audited/recommended by the BSI since 2017 -- https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Kryptografie/Kryptobibliothek-Botan/kryptobibliothek-botan_node.html

Seems there's a fork that's the German equivalent of "FIPS-validated versions"? -- https://github.com/Rohde-Schwarz/botan/

So to answer my own question: Das ist gut für die Deutschen.

@arckoor
Copy link
Author

arckoor commented Oct 11, 2025

Yeah, I probably should have mentioned that the BSI is rather fond of Botan, my bad.
My personal reason for wanting to add this is that I already use botan-rs elsewhere, and it'd be nice to not have to compile multiple different cryptographic libraries.

I haven't worked with rust-crypto so I can't offer a perspective there, but in comparison to aws-lc-rs (and OpenSSL) Botan is a much smaller library in terms of LOC, which IMO is a good thing for a cryptographic library. As for the functionality that Botan can offer to this library, there probably aren't that many advantages over the other two, unless of course someone (like the BSI) mandates you use a certain cryptographic backend.

Regarding the Rohde-Schwarz fork - yes it exists, but I'm not sure which approach would be good to go with here. boran-rs uses the features pkg-config (find a botan lib somewhere on the system and use that), as well as vendored (checkout the git submodule, and build botan from source).
With the pkg-config approach you should be able to get it to use a BSI approved version (that would have been compiled with --module-policy=bsi).
It'd be nice to somehow be able to pass these feature flags through jsonwebtoken to the botan-rs crate, but I'm not sure how that could be done.

If this isn't a welcome change I'd be happy to maintain the backend for myself, but it doesn't seem like there currently is a way to specify a custom crypto provider. Something analogous to rustlss CryptoProvider would be a nice to have then (e.g. like this).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants