FIPS "OpenSSL only" mode #50
Comments
|
Not sure how viable it is given that I'm looking to eventually move away from OpenSSL to RustCrypto for faster builds and to avoid copying memory around, but that's very far away still. If you can get dynamically liked OpenSSL as a feature flag, I'm happy to merge it for the time being! |
|
I figured that was the eventual goal, and I am definitely in favor of it as a random user (having gone through build hell and back to get everything compiling on all platforms VS Code targets 😅) but sadly it seems for naught. 30m-ish in it seems like I may be able to do this with minimal surgical changes, but we'll see. Should have a PR in today or tomorrow pending unexpected hurdles. |
Fixes warp-tech#50 This introduces an on-by-default `rs-crypto` flag, which enables the existing Rust-based crypto libraries (including aes and ED25519). However, these implementations can be removed by disabling the flag. If it's disabled, then openssl (when turned on) will stand in for them, in a less performant way. Note that while OpenSSL 3.x does have some ED25519 support, I have not done the work to make that compatible as well--partly because ED25519 is not yet an approved algorithm for my company to use, and partly to retain compatibility with OpenSSL 1.x
Fixes warp-tech#50 This introduces an on-by-default `rs-crypto` flag, which enables the existing Rust-based crypto libraries (including aes and ED25519). However, these implementations can be removed by disabling the flag. If it's disabled, then openssl (when turned on) will stand in for them, in a less performant way. Note that while OpenSSL 3.x does have some ED25519 support, I have not done the work to make that compatible as well--partly because ED25519 is not yet an approved algorithm for my company to use, and partly to retain compatibility with OpenSSL 1.x
|
Would |
|
As far as I am aware, native-tls doesn't provide the primitives needed to implement SSH |
One cloud on the horizon for our usage of this library is the likelihood of needing to be FIPS certifiable. Long story short, this essentially means having all cryptography done by a dynamically linked OpenSSL library--which in turn is FIPS certified. In this case, we would use OpenSSL for the cryptography currently done by crates like
aesandpbkdf2.I will (attempt to) implement this in our fork of the library, but I was wondering if it's something there'd be interest in merging upstream as a feature flag. Understanding that dependency on OpenSSL is not greatly desirable and that this would increase the complexity of the library for something a minority of consumers will ever need 😛
The text was updated successfully, but these errors were encountered: